Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Giving Alerts don't pass the FinancialTransactionId to an associated Connection Request #5570

Closed
1 task done
kkiserGH opened this issue Sep 1, 2023 · 2 comments
Closed
1 task done
Labels
Fixed in v16.1 Type: Bug Confirmed bugs or reports that are very likely to be bugs.

Comments

@kkiserGH
Copy link

kkiserGH commented Sep 1, 2023

Please go through all the tasks below

  • Check this box only after you have successfully completed both the above tasks

Please provide a brief description of the problem. Please do not forget to attach the relevant screenshots from your side.

Hi!

Thanks for implementing the giving alerts functionality! We are excited to start using this feature to help us better care for and connect with our congregation!

I ran into an issue where I can't get the 'FinancialTransactionId' value passed to a connection request triggered from a giving alert.

Expected Behavior

I expected that a connection request, with an attribute of 'FinancialTransactionId', created from a properly configured giving alert would have its attribute populated for the 'TransactionId' associated with the giving alert.

Actual Behavior

The 'FinancialTransactionId' attribute on the connection request was not populated even though there is a 'TransactionId' associated with the giving alert.

Steps to Reproduce

Steps

I configured giving alerts to create connection requests.

image

Per the connection request tooltips in the giving alert configuration page, "If matched, will create a new connection request with the authorized person as the requestor and setting the attribute with the key 'FinancialTransactionId' if it exists."

image

The connection type I created was defined with a connection request attribute having a key of 'FinancialTransactionId'.

image

When the giving automation job ran, I can tell the giving alert created the connection request but it didn't populate the 'FinancialTransactionId' attribute.

image
image

Note that the type of the attribute I added for the connection request was integer. I also tried it with a text type but the value still did not appear.

I tried this on our own system as well as recreated a simple version on https://rocksolidchurchdemo.com/ which is where these screen shots are from.

Code Inspection

I believe the issue is in \Rock\Tasks\ProcessTransactionAlertActions.cs. In the Execute method, the connection request configuration is examined and a connection request conditionally created in lines 88 - 121. Specifically in lines 113 - 117, a call is made to

request.SetAttributeValue( "FinancialTransactionId", alert.TransactionId.Value.ToString() );

But I can't see where SaveAttributeValue(s)() is called once the attribute has been set. To test if this was the issue, I modified a copy of the ProcessTransactionAlertActions.cs file and ran this on our system. I changed lines 113 - 119 from:

if ( alert.TransactionId.HasValue ) { request.LoadAttributes(); request.SetAttributeValue( "FinancialTransactionId", alert.TransactionId.Value.ToString() ); } connectionRequestService.Add( request );

to:

connectionRequestService.Add( request ); if ( alert.TransactionId.HasValue ) { request.LoadAttributes(); request.SetAttributeValue( "FinancialTransactionId", alert.TransactionId.Value.ToString() ); request.SaveAttributeValue("FinancialTransactionId", rockContext); }

I am NOT suggesting this should be the final fix but rather offering this change, which worked after testing, as an indication that the 'FinancialTransactionId' attribute is not being saved.

Not supported with Workflows?

On a related note, the giving alert can be configured to trigger a workflow instead of a connection request and the workflow tooltip has similar text that the 'TransactionId' will be passed to the workflow if a 'FinancialTransactionId' attribute exists.

image

I did not test whether this occurs or not as that is not my current use case. But in inspecting the code in lines 78 - 86, I did not see where the 'TransactionId' was being set to a workflow attribute of 'FinancialTransactionId'. But I do see that the GUID of the 'FinancialTransactionAlert' was being passed. This should allow the workflow to get at the 'TransactionId' property. If this is what was intended then perhaps the tooltip can be updated and/or a note put in the documentation to this affect?

Thanks!!!

Rock Version

13.6 (ours) and 15.1 (rocksolidchurchdemo.com)

Client Culture Setting

en-US

@kkiserGH
Copy link
Author

kkiserGH commented Sep 1, 2023

Mea culpa. In my testing of my modified code, I see that the attribute value DID get created. But it has an EntityId of 0 so it doesn't show up on the connection request detail page. When I manually update the EntityId column of the attribute value entry, it DOES show up on the connection request detail page.

image

So my code change failed. Hopefully you see the issue (or can show me where I am off!) and implement a better solution than I attempted to do.

For now, I am going to try the workflow trigger from the giving alert and see if I can get the 'TransactionId' from the FinancialTransactionAlert GUID passed to the workflow. If this works then I will create the connection request from the workflow.

Thanks!

@sparkdevnetwork-service sparkdevnetwork-service added the Status: In Dev Queue This issue is being worked on, and has someone assigned. label Sep 18, 2023
@sparkdevnetwork-service sparkdevnetwork-service added the Type: Bug Confirmed bugs or reports that are very likely to be bugs. label Oct 17, 2023
@PraveenMathew92 PraveenMathew92 added Fixed in v16.1 and removed Status: In Dev Queue This issue is being worked on, and has someone assigned. labels Oct 24, 2023
@PraveenMathew92
Copy link
Contributor

Thank you @kkiserGH for going through the code and providing the suggestions. It helped me come up with the final fix for the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fixed in v16.1 Type: Bug Confirmed bugs or reports that are very likely to be bugs.
Projects
None yet
Development

No branches or pull requests

3 participants