Fix editing and saving a template contribution via form

[mattwire]

Overview

https://lab.civicrm.org/dev/financial/-/issues/6

When you click on "View Template" for a recurring contribution and then try to edit that template you get a crash because:

1. receive_date is a required field.
2. Contribution status is not set.

Before

Cannot save an edited template contribution via UI.

After

Can save an edited template contribution via UI.

Technical Details

Fixes for https://lab.civicrm.org/dev/financial/-/issues/6

Comments

@jaapjansma I don't think you were using the UI to edit the templates?

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

[jaapjansma]

test this please

[jaapjansma]

@mattwire I am doing PR reviews with @kainuk and @BettyDolfing and we don't understand how we can reproduce this on dmaster.demo.civicrm.org and on the test site of this PR. Can you provide a step by step instructions on how to test this and which payment processor we should use on dmaster.demo.civicrm.org?

We have used the dummy payment processor however that payment processor does not allow the editing of recurring contribution templates.

As I have worked on this issue with you I do know how to test this locally.

[BettyDolfing]

test this please

[mattwire]

@jaapjansma You have to test with a processor that supports "Edit Recurring contribution" like this:

public function supportsEditRecurringContribution() {
    return TRUE;
  }

If you are testing locally you could add that to CRM_Core_Payment_Dummy and then create a new recurring contribution through the UI "Submit Credit Card Contribution". Otherwise you will have to use one of the processors that support edit recurring contribution on dmaster.demo but you need account details etc I think.

[jaapjansma]

We have found a way on how to reproduce this on the test environment.

Create a payment processor type

1. Go to the API explorer (v3) (via Support --> Developer --> Api Explorer V3)
2. Select as Entity PaymentProcessorType and as action create
3. Fill in the following fields and set them identical:

     'name' => "Manual",
      'title' => "Manual",
      'class_name' => "Payment_Manual",
      'billing_mode' => 1,
      'is_active' => 1,
      'user_name_label' => "User Name",
      'is_recur' => 1,

In the above the class_name needs to be set to Payment_Manual and billing_mode needs to be set to 1. And is_recur also to 1. You also need to set a user_name_label otherwise it wont work.

Create a Payment Processor

1. Go to Administer --> CiviContribute --> Payment Processors
2. Click on Add Payment Processor
3. Select Manual as Payment processor type set the Payment Processor field to something and the username field.
4. Click on Save

Contribution page for signing up for recurring donations

Now you need to create a contribution page where a donor can sign up for a recurring contribution with the Manual payment processor

Next step is to use this contribution page to sign up for recurring donation with the manual payment processor.

Now you can use this recurring contribution to test whether this works.

[jaapjansma]

We (@BettyDolfing and @kainuk and I) have tested this issue and we see things which are not right.

First of all saving a template contribution gives an error that the contribution status is required. See screenshot below

Next we also saw that in the editing template contribution screens the custom field section contains NULL and not all custom fields are editable. See screenshot below:

@mattwire can you have another look at this and try to fix the issues.

[jaapjansma]

@mattwire can you have a look at this PR? The tests are failing not sure if it is related or not.

[mattwire]

See #22993 for partial fix for test failures.

[BettyDolfing]

Test this please

[jaapjansma]

We tested this again and we noticed that when editing an contribution recur template the fields under additional details are not loaded and the loading spinner keeps running. See screenshot below (with the error message).

We also checked whether we could edit and save the contribution recur template and we could do that.

@mattwire can you have another look into the additional details section?

[colemanw]

I've marked this PR as a draft until @mattwire has a chance to respond.

[adixon]

@mattwire thanks for this! I'm baffled that the contribution template feature was incorporated without the ability for administrators (or clients) to modify it, that seems like a solution that is worse that the problem it solves, at least from how my clients use it.

@jaapjansma can you describe what the purpose of a template is if you can't edit it with this form? What am I missing? Are there other ways to modify a recurring contribution now?

@mattwire Your code looks right, and I'll try dropping into a few of my installs that are currently broken.

[adixon]

I can confirm that your patch allowed me to update a recurring contribution amount, whereas without it, I go the errors you noted.

I can also confirm the same behaviour that @jaapjansma reports - i.e. contribution custom fieldsets that are not open by default don't open (i.e. ajax is broken). On the other hand, I don't see how it's related to your patch, I think it might be a separate issue.

@KarinG has posted an issue for this here: https://lab.civicrm.org/dev/financial/-/issues/194

[mattwire]

I have marked this as merge-ready. In my opinion and based on @adixon testing I think it should be merged. I don't think the ajax issue on custom fields is related to this PR and could be solved separately. I have also been using this patch without problems on all client sites for a long time.

[eileenmcnaughton]

Merging based on @adixon review and confirmation from @mattwire that he has tested non-template editing.

As discussed above the additional details should probably not appear but is not in scope for this PR

[KarinG]

I just got back to my desk -> and I still can not edit the recurring contribution amount. The patch is applied here. The errors on save are gone but I still have no way to actually edit the amount.

[jaapjansma]

@adixon

@jaapjansma can you describe what the purpose of a template is if you can't edit it with this form? What am I missing? Are there other ways to modify a recurring contribution now?

Exactly it shouid be possible to edit a template contribution. Great to see that this PR got merged!

@KarinG I see you are using line items. Use the line item editor extension to edit the amount.

[KarinG]

Yes this client uses a simple priceset so that donors on the native CiviCRM Contribution form can can pick a radio button ($5, $10, $15, $20, $50) to select their monthly donation.

To summarize ->

There is no way to simply edit the amount on for the recurring contribution anymore, am I right?

One has to use the Edit Template, right?

If you happen to have a native CiviCRM Contribution form that uses a priceset you must now install lineitem editor extension to be able to update the amount you want to process monthly, is that right?

I installed the latest publicly available version of lineitem editor extension via that UI and edited the Template via the UI and that did not go well-> [this is with this PR applied so I'm now getting passed the Save Form errors]:

Next
What will happen on next transaction - I did this last night and this donor is scheduled to transact today ->

iATS will of course use the amount on the recurring series -> which is $15 and CiviCRM will create a new contribution with $20 - am I right? So perhaps we'll process $15 and then record it as $20?

Oh wait, it's already morning in Halifax. So let me run the schedule job and yes...

That's indeed what happend. Receive $15, Record $20 and we would now be TaxReceipting an additional $5 that was never received.

[adixon]

I think the issue of the mismatch of schedule amount and template amount (when using the line item editor) is a new issue, similar to #21473 (which purports to solve that issue but likely only handles it for non-line item changes).