Allow contribution search by recurring payment processor ID / Transaction ID

[mattwire]

Overview

Allow to search by recurring contribution transaction ID / payment processor ID / processor ID

Before

Cannot search by recurring contribution transaction ID / payment processor ID / processor ID

After

Can search by recurring contribution transaction ID / payment processor ID / processor ID

Technical Details

Just exposes three extra fields for searching.

[seamuslee001]

@mattwire can i confirm that even tho the Payment Processor was added to the $form array as a text field it was never exposed through the template is that correct?

[mattwire]

@seamuslee001 Both transaction ID and processor ID were exposed on the form but not on the template. Note that processor_id and payment_processor_id are not actually the same thing. If it makes sense we could also expose processor_id on the search template?

[seamuslee001]

@mattwire i guess what i was going for was is there a possibility that smart groups perhaps could have been built on the field before hand because i note you are changing the processor_id from a text to a select field

[kirk-jackson]

I'm going to review this now.

[mattwire]

@kirk-jackson I remember you having some comments on this, but they're not here?

[kirk-jackson]

Hi @mattwire, sorry for the delay. I think this is a very useful improvement, but it's missing a couple of things. Specifically, when values are supplied for any of these fields:

• the values need to be displayed in the search results summary (aka the 'QILL').
• the Recurring Contributions search criteria pane needs to be kept open, otherwise the values will disappear on subsequent searches.

Furthermore, I think that there may be confusion about what the Processor ID and Transaction ID are for. To make it clear, I propose a couple of improvements:

• Add help balloons for the Processor ID and Transaction ID fields.
• Move the Processor ID field up so that it's directly below the Payment Processor field, as the two are related. (The Processor ID is supplied by the Payment Processor.)

I have attached a patch file to implement the above changes: civicrm-pr12818-patch.txt. What do you think?

[eileenmcnaughton]

I took a look at the code - once @kirk-jackson is happy I think we should merge this

[kirk-jackson]

• Explain (r-explain)
  • PASS : The goal/problem/solution have been adequately explained in the PR.
• Test results (r-test)
  • PASS: The test results are all-clear.
• Code quality (r-code)
  • PASS: The functionality, purpose, and style of the code seems clear+sensible.
• Documentation (r-doc)
  • PASS: The changes do not require documentation.
• Maintainability (r-maint)
  • PASS: The change is trivial enough that it does not require tests.
• Run it (r-run)
  • PASS: With sample recurring contribution records in the database, searches using a range of values in each of the three new search fields gave the expected results.
• User impact (r-user)
  • PASS: The change would be intuitive for a majority of users who work with this feature.
• Technical impact (r-tech)
  • PASS: The change preserves compatibility with existing callers/code/downstream.

Happy for this to be merged @eileenmcnaughton, @mattwire.

[seamuslee001]

Merging as per @kirk-jackson 's review

[eileenmcnaughton]

thanks @kirk-jackson @mattwire