Closed omarabuhussein closed 3 years ago
Hey, not to complicate things but just wondering how this might interact with other payment processors such as if we were to use Stripe for recurring credit card payments? @omarabuhussein
Could/do we limit the scope only to our payment processor perhaps?
@jamienovick this is already the case in this PR, I also have tests to ensure that.
I just updated the title and the PR description to make that more clear.
Overview
I here prevent any update to the recurring contribution 'next_sched_contribution_date' field from outside Membershipextras (Basically preventing CiviCRM core and the webform_civicrm module from altering its value) since it will be used for autorenewal, and thus we need to be able to control its value with external interference. Hence that this only affect offline payment processors (any payment processor that extends the Payment_Manual class).
Before
Creating payment plan from the admin form or from a webform will set the
next_sched_contribution_date
valueAfter
Creating payment plan from admin form or from webform will set the
next_sched_contribution_date
to blankHence that this is temporary, and I will later implement new code to set its value but form within Membershipextras, since the value that we see in the "Before" section gif is coming from CiviCRM core which we don't control.
Technical details
I unset the value by removing the value of this field inside the Recurring Contribution Pre hook, this means that any API or DAO that try to change the value of this field will not work (which is how CiviCRM core and webform_civicrm module alter its value), Which allow us to control its value within Membershipextras using Direct SQL queries.