Add payment processor to details on list of recurring contributions

[mattwire]

Overview

When admin staff look at the list of recurring contributions and a contact has more than one it can be quite important to know the payment processor. Eg. "The one I paid by Stripe" or "The direct debit".

Currently you have to view the detail of each one to find out which it was.

Before

Have to view the recur to find out what type of payment processor it is.

After

Shown in the list. This is even more useful when viewing a membership which shows contributions/recurring contributions at the bottom - so you can see at a glance how the membership is being paid.

Technical Details

Comments

@wmortada @artfulrobot @bhahumanists I feel you might be interested?

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[wmortada]

That sounds like a helpful improvement. I've tested it on dmaster and it works for me.

[mattwire]

@Erioldoesdesign A UI improvement for you to review :-)

[Erioldoesdesign]

@mattwire thanks for tagging me :) excited to be helping! This is mostly a list of questions and observations (don't let people know that this is pretty much what design is in general!)

Looks/sounds like a much-needed improvement for information 'parsing' from the human perspective.

I imagine these views are configurable by civi users? as in the ability to add/remove columns? (this might be a huge assumption as I'm not yet proficient in how much admins can configure inside civi views)

General table design looks good, accessible enough though I would darken some of the grey lines/light grey text to pass AAA WCAG. #A7A7A7 on white doesn't pass AA.

Regarding the payment processor column, are we assuming all admin users with access to this information understand each of the potential payment processors? Is there merit in (i) icons or information/links out to info about Stripe/Paypal etc. etc. or are we making an assumption that users would just open up a search engine and find info or already have all info needed about said 'payment processor' so they don't need to do any knowledge gathering.

[wmortada]

@Erioldoesdesign some helpful feedback! I think you raise some valid points here, but they feel outside of the scope of this particular change so are probably best raised as separate issues in GitLab.

I imagine these views are configurable by civi users? as in the ability to add/remove columns?

Unfortunately not, but agree this would be helpful. I imagine this would be a significant change to implement though as it affects all of the CiviCRM UI.

General table design looks good, accessible enough though I would darken some of the grey lines/light grey text to pass AAA WCAG. #A7A7A7 on white doesn't pass AA.

Good point but outside the scope of this change as it affects most of the CiviCRM UI and would need to be applied consistently across the board.

Regarding the payment processor column, are we assuming all admin users with access to this information understand each of the potential payment processors?

I think most users probably would know the payment processors that relate to their particular installation. In my experience most staff that are looking at this particular screen would be using it on a daily basis and would have detailed knowledge of the payment processors.

Your suggestions could certainly be helpful to some users so may be worth raising as a suggestion (again as a separate issue).

[BettyDolfing]

test this please

[jaapjansma]

• General standards
  • Explain (r-explain)
    • PASS : The goal/problem/solution have been adequately explained in the PR.
  • User impact (r-user)
    • PASS: The change would be intuitive.
  • Documentation (r-doc)
    • PASS: The changes do not require documentation.
    • COMMENT: The documentation needs a new screenshot. See Updated documentation for PR 17179 civicrm-user-guide#449
  • Run it (r-run)
    • PASS: We tested it in dmaster and in the test environment with this PR. We added a new recurring contribution through the contribution page and we checked the contribution recurring on the contact summary.
• Developer standards
  • Technical impact (r-tech)
    • PASS: The change preserves compatibility with existing callers/code/downstream.
  • Code quality (r-code)
    • PASS: The functionality, purpose, and style of the code seems clear+sensible.
  • Maintainability (r-maint)
    • PASS: The change is trivial enough that it does not require tests.
  • Test results (r-test)
    • PASS: The test results are all-clear.

@eileenmcnaughton or @colemanw can one of you merge this PR? We have also updated the screenshot in the docs.
We do think the failing test is unrelated.

[eileenmcnaughton]

@jaapjansma thanks for updating the screenshot while reviewing - very helpful

[artfulrobot]

@mattwire this is an excellent improvement, thanks. (next up: add it as a adv search criteria?!)

[eileenmcnaughton]

Hmm - it might be better to expose in the new search builder - ideally we want to stop adding things to advanced search...