Schedule Financial Transactions Defaulting to "Contribution" Instead of Transaction Type Determined by Transaction Entry Block Settings

Description

The Transaction Entry Block has a block setting to change Transaction Type of the transaction. When completing a transaction with the frequency of one-time, the transaction will include the Transaction Type chosen in the block setting. However, when changing the frequency to make the transaction a scheduled transaction, the transaction type is not being set on the transaction, which results in the transaction having a default value of "Contribution" even if the Transaction Type is set to "Event Registration".

This causes confusion because one-time transactions can have the correct Transaction Type, where scheduled transactions will have a different Transaction Type.

Steps to Reproduce

Edit Block Configuration for Transaction Entry Block
Go to Advanced Settings
Change Transaction Type to "Event Registration"

Give-Now-External-Website

)

Click Save
Change Frequency to "Weekly"

Give-Now-External-Website (1)

Complete a Transaction
View the Scheduled Transaction

Scheduled-Transaction-Rock-RMS

Expected behavior:

I would expect the TransactionTypeValueId property to be set on the FinancialScheduledTransaction.

Actual behavior:

The TransactionTypeValueId property is not set on the FinancialScheduledTransaction. We ran a quick SQL Query to determine if the value was being set:

SELECT
    [AuthorizedPersonAliasId]
    , [TransactionTypeValueId]
    , [FinancialGatewayId]
    , [GatewayScheduleId]
    , [TransactionCode]
    , [SourceTypeValueId]
    , [TransactionFrequencyValueId]
    , [StartDate]
    , [IsActive]
FROM
    [FinancialScheduledTransaction]
WHERE
    [Id] = 1

missing-transaction-type-value-id

We believe this property will be auto-filled with the "Contribution" Transaction Type value if the property is null, instead of being populated with the correct Transaction Type determined by the block settings.

Versions

Rock Version: Rock McKinley 14.0 (1.14.0.9)
Client Culture Setting: en-US

Hi @KCKurz. We're not able to reproduce this in v14.0, but from the date on your report we suspect you may have found this issue in an earlier (v13) version.

We believe this was fixed in https://github.com/SparkDevNetwork/Rock/commit/18a4e5b6dc66724a6e076e2abef12d7e1ec704cb which was included in Rock v14.0 as well as Rock v13.7. Can you confirm whether you are still experiencing this issue in v14.0 as specified in the issue report?

If we don't hear back from you in a week, we'll assume this was fixed and close the issue.

Hi Shaun, thanks for reaching out and please forgive my delayed reply.

We were on v13 when we discovered the issue, but our Rock partner, Triumph Tech, actually confirmed the bug and sent me the screenshots that they were able to reproduce in v.14.0. I have been testing v14.0 and v14.1 in our sandbox, there are many things preventing me from moving forward with our production site into v14.0/14.1 right now, so I won't know until that time comes. A couple of things break, and we will have to wait until at least April to upgrade so those things can be addressed, but there are some other bugs, that are fixed in 14.2 and 15.0 that are having a high impact in our sandbox, so - - it may be longer before we upgrade.

Once we do, I will certainly test and see, but for now, I wanted to provide you with this clarification that it was recreated in v14.0 at the time of my submission.

Please let me know your thoughts, thank you!

[image: LifeMission Logo.png] http://lifemission.church

Kelly Kurz

Systems & Software Manager

913-732-1250

@.***

[image: facebook.png] https://www.facebook.com/lifemissionks/ [image: twitter.png] https://twitter.com/lifemissionKS [image: instagram.png] https://www.instagram.com/lifemission.church/

On Fri, Feb 24, 2023 at 10:33 AM Shaun Cummings @.***> wrote:

Hi @KCKurz https://github.com/KCKurz. We're not able to reproduce this in v14.0, but from the date on your report we suspect you may have found this issue in an earlier (v13) version.

We believe this was fixed in 18a4e5b https://github.com/SparkDevNetwork/Rock/commit/18a4e5b6dc66724a6e076e2abef12d7e1ec704cb which was included in Rock v14.0. Can you confirm whether you are still experiencing this issue in v14.0 as specified in the issue report?

If we don't hear back from you in a week, we'll assume this was fixed and close the issue.

— Reply to this email directly, view it on GitHub https://github.com/SparkDevNetwork/Rock/issues/4987#issuecomment-1443969901, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYWLG3E7JIMSNDNQLGFJVYTWZDPHNANCNFSM5UDDCTAA . You are receiving this because you were mentioned.Message ID: @.***>

Hi Shaun, thanks for reaching out and please forgive my delayed reply.

No problem, Kelly. We appreciate your help finding and resolving issues in the Rock code.

In this case, I'm going to go ahead and mark this as fixed by the commit referenced above (https://github.com/SparkDevNetwork/Rock/commit/18a4e5b6dc66724a6e076e2abef12d7e1ec704cb). I was able to locate the internal tasking on this and that commit was definitely intended to resolve this issue. The developer should have tagged this issue as fixed in the commit message.

For the full context: It looks like you reported this issue on April 22, and it was reproduced on a pre-alpha build of Rock v14 in May, but subsequently resolved in the commit made on July 5th, which went into the next pre-alpha build (1.14.0.14) several months before v14 was released in October. This fix was also committed to the v13.7 hotfix branch, which was also released in October, so if you're not ready to upgrade to v14 yet, you can get the fix by updating to v13.7.

SparkDevNetwork / Rock