wip - add paid_amount & balance_amount to apiv4

[eileenmcnaughton]

Overview

add paid_amount & balance_amount to apiv4

This makes these two fields available as tokens and as fields for apiv4

Before

now you don't see it

After

now you do

Technical Details

I've added into this PR conversion for the invoice template to use the new fields as simplifying to use consistent tokens has always been the goal - however, unless we want to force an message template update on people we can always continue to assign the variables. That is an enthusiasm question as we do have a reasonable find & replace routine for straight template swaps

Comments

@mattwire

[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).

[mattwire]

@eileenmcnaughton I think for ease of review/clarity we'd be better having two PRs. One for the API4 functionality and one for the invoice template changes.

Also, I'm not sure how API4 calculated fields work - I'm assuming that paid_amount and balance_amount won't be returned by default and won't be calculated by default? Ping @colemanw - just thinking about performance on large Contribution::get calls.

Have not tested yet but this will be a really useful feature going forward.

[eileenmcnaughton]

My understanding is that it 'might' if people use addSelect('*) which is not that common in api v4 (and pretty clearly discouraged) so it might not be a show stopper but we can see what @colemanw says.

I'll focus on the other template changes first & come back to this after I've got those merged

[eileenmcnaughton]

I'll close this out for now and come back to it later - I think the select side does have a mitigation but I don't think I need an open PR to look into that when I'm ready to

[mattwire]

@eileenmcnaughton What's the blocker here? I don't understand your comment "the select side does have a mitigation"

[eileenmcnaughton]

Yeah - I think the performance thing is non-blocking - I just don't want to prioritise getting this mergeable at the moment

[eileenmcnaughton]

Ah this clarifies the performance thing #23819 (comment) - so it's definitely not a blocker - once I've worked through the rest of the template changes I will re-visit this as the last change in the template series

[eileenmcnaughton]

#24118 now open