-
-
Notifications
You must be signed in to change notification settings - Fork 825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always use cancelSubscription form for cancelling recurring contributions #18196
Conversation
(Standard links)
|
6347fd1
to
7d4ef13
Compare
I'm just going through triaging for 'needs test' & ok without test. I guess the logic is PRs need a test unless we can't see how they could be tested or we know there is existing relevant cover. I think this could be tested. |
Reviewer's partial from civicrm#18196
7d4ef13
to
fbc4cd0
Compare
Test fail relates i believe |
Yep - there is another open PR related to these links which is where discussion is taking place #18787 - the tldr is that we also need to think about the situation where the appropriate links are different for someone dealing with their own recurring vs someone else's |
fbc4cd0
to
1f988b0
Compare
a3871e2
to
f284c77
Compare
|
f284c77
to
98ee7c9
Compare
This picks up on two of the issues that were blocking on civicrm#18787 and civicrm#18196 (but does not solve all of them). It 1) adds the basis for unit test cover and 2) separates the function for retrieving links for self-service from back office user. I think there is still some jumbling together of these concepts but as long as we are careful to extend the tests as we extend the logic... This fixes what I suspect is an oldish regression whereby the cancel link for paypal std users was wrong
This picks up on two of the issues that were blocking on civicrm#18787 and civicrm#18196 (but does not solve all of them). It 1) adds the basis for unit test cover and 2) separates the function for retrieving links for self-service from back office user. I think there is still some jumbling together of these concepts but as long as we are careful to extend the tests as we extend the logic... This fixes what I suspect is an oldish regression whereby the cancel link for paypal std users was wrong
This splits out a minor code cleanup from civicrm#18196 (which can probably build on the unit test work in 20210)
This picks up on two of the issues that were blocking on civicrm#18787 and civicrm#18196 (but does not solve all of them). It 1) adds the basis for unit test cover and 2) separates the function for retrieving links for self-service from back office user. I think there is still some jumbling together of these concepts but as long as we are careful to extend the tests as we extend the logic... This fixes what I suspect is an oldish regression whereby the cancel link for paypal std users was wrong
This picks up on two of the issues that were blocking on civicrm#18787 and civicrm#18196 (but does not solve all of them). It 1) adds the basis for unit test cover and 2) separates the function for retrieving links for self-service from back office user. I think there is still some jumbling together of these concepts but as long as we are careful to extend the tests as we extend the logic... This fixes what I suspect is an oldish regression whereby the cancel link for paypal std users was wrong
98ee7c9
to
92a01cf
Compare
This picks up on two of the issues that were blocking on civicrm#18787 and civicrm#18196 (but does not solve all of them). It 1) adds the basis for unit test cover and 2) separates the function for retrieving links for self-service from back office user. I think there is still some jumbling together of these concepts but as long as we are careful to extend the tests as we extend the logic... This fixes what I suspect is an oldish regression whereby the cancel link for paypal std users was wrong
92a01cf
to
325617f
Compare
325617f
to
023a6cb
Compare
We can build on this test: #21588 |
CRM/Contribute/Page/Tab.php
Outdated
'title' => ts('Cancel'), | ||
'url' => 'civicrm/contribute/unsubscribe', | ||
'qs' => "reset=1&crid=%%crid%%&cid=%%cid%%&context={$context}", | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the above change mean we load Cancel
link only for processors supporting cancelRecurring
?
But from the description -
After
Always display the cancellation form. Eg. for a recur with payment processor:
it seems the cancel link should always be visible and condition should be checked on the form, i.e, for Send cancellation request to processor
field? Is that correct?
With this PR applied, I see the Cancel link is not displayed for processors not having supportsCancelRecurring()
.
@mattwire can you pls clarify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jitendrapurohit You are right. I've have pushed a fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "Cancel" link should always display but the form should disable "send cancellation request to processor" if processor does not supportsRecurring()
023a6cb
to
bc1f2c5
Compare
663b65e
to
d310941
Compare
ca0fa1e
to
edcf036
Compare
Test this please |
@mattwire can you explain what this PR changes? We see the exact same behaviour in https://dmaster.demo.civicrm.org (which does not have this patch). See screenshot below: It looks like this PR is not solving anything (or does solve something which has been solved in the mean time). |
…ions This is civicrm#18196 without the bit I was uncomfortable with
…ions This is civicrm#18196 without the bit I was uncomfortable with
…orm if cancel is not supported by processor
edcf036
to
cf2d3c2
Compare
@mattwire pr template needs updating now - to explain what the point is of this change / why the PR still exists |
@eileenmcnaughton Yes, not sure that this bit is still required. |
Overview
Replaces #16717, follow up to #17146.
Includes #22784 and #21895.
There was existing code to handle cancellation if the processor does not support cancellation.
You may still want to record cancellation reason, see instructions to manually cancel with your provider and send a notification email to the contributor.
But if the processor reports that it does not
supportCancelRecurring
the form is never displayed and the built in entity enable/disable via javascript is used. This only really makes sense if there is no payment processor.Before
enable/disable javascript used if processor does not support cancelling recur (cancel link still available in list of recurs!).
After
Always display the cancellation form. Eg. for a recur with payment processor:
And without a payment processor:
Technical Details
Comments
This cleans up another inconsistency in the way civi handles things. @eileenmcnaughton This finishes off the cancellation stuff we were working on a few versions back.