Transaction Matching not processing in scanned order

[bobrufenacht]

Description

After scanning checks, then proceeding to Transaction Matching, the checks are not shown in order when clicking Next. They go 1,3,5,7 etc. and then loop back through. As such, the Prev button on 3 will go back to 2, not to 1 which was the previous shown.

Actual Behavior

Check order is 1,3,5,7,etc. and then loops back to get 2,4,6,8, etc. Previous goes back to a check not entered or one unexpected.

Expected Behavior

I would expect the default to go in order if only one person matching. The code tries to do that.

Steps to Reproduce

• Go to Batches and create a new batch.
• Add transactions in the amount of $1, $2, $3, $4, $5 without adding a person (so matching is required)
• Click on Match Transactions
• $1 will show.
• Click Next and $3 will show.
• Click Next and $5 will show.

Issue Confirmation

• Perform a search on the Github Issues to see if your bug or enhancement is already reported.
• Try to reproduce the problem on a fresh install or on the demo site.

Rock Version

15.2

Client Culture Setting

en-US

[bobrufenacht]

The issue is in the navigateNext javascript function in the TransactionMatching.ascx file. If there are no unallocated funds, the javascript explicitly calls the successLocation (btn_Next_Click) without e.PreventDefault. So the Next button gets processed twice leading to the skipping of checks/transactions.

Issue can be fixed by removing the "else { window.location = successLocation; }" in lines 500-503.

[jasonhendee]

The issue is in the navigateNext javascript function in the TransactionMatching.ascx file. If there are no unallocated funds, the javascript explicitly calls the successLocation (btn_Next_Click) without e.PreventDefault. So the Next button gets processed twice leading to the skipping of checks/transactions.

Issue can be fixed by removing the "else { window.location = successLocation; }" in lines 500-503.

Thanks, @bobrufenacht! Looking into this today.

[jasonhendee]

@bobrufenacht thanks again for reporting this and providing a proposed fix. We finally got back around to giving this our attention today and confirmed that the line calling the event handler within the specified JavaScript else block is redundant and leads the the handler being called twice. We've left the else block and comment there for clarity, but removed the offending line.

Also, we discovered a related issue where a Transaction can become tied to a given Person and not released if the Person navigates away from the block. The above commit also fixes this edge case.