Extract code to set isEmailReceipt in Contribution.completeOrder #18039
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(Standard links)
|
|
@mattwire this removes another chunk & I suspect the addActivity above it can go too |
eileenmcnaughton
force-pushed
the
mail
branch
2 times, most recently
from
1e3f201
to
7cfe17f
Compare
|
@KarinG @artfulrobot @jitendrapurohit If any of you are able to confirm the logic here - on first glance it seems correct and a good cleanup |
|
Warning this may hurt your brains |
|
Jenkins re test this please |
|
test this please |
|
Might be a cleanup issue or a CI server issue ok 571 - api_v3_ContactTypeTest::testContactUpdateSubtypeInvalid with data set "APIv3" (3)
|
|
test this please |
eileenmcnaughton
force-pushed
the
mail
branch
2 times, most recently
from
ee022fa
to
cd875e8
Compare
|
@eileenmcnaughton Check your style |
This consolidates all the code in the completeOrder that determines whether or not to send an email receipt. Note that - testCompleteTransactionWithEmailReceiptInput tests that input is respected - for events the event::sendMail function will not send unless it's configured for the event - which explains our final default of TRUE (testCompleteTransactionWithParticipantRecord) - testCompleteTransaction covers the back-office case which also defaults to true - I figure the cost of reloading the value for contribution_recur is pretty cheap compared to the confusion of passing values around - testpayLater covers contribution_page with is_email_receipt
|
Jenkins is a grumpy bum |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This consolidates all the code in the completeOrder that determines whether or not to send an email receipt.
Looking at it here it seems deceptively simple but this calculation has always done my head in and I think it needs some pretty careful eyes on this to verify it.
I'm still evaluating the adequacy of test cover but I've described the tests I've found so far
Before
isEmailReceipt calculation 'distributed' in the main function
After
isEmailReceipt calculation extracted. Note that this does an extra lookup for recurring contributions but the (very small) performance cost seems acceptable given the readability issues and the fact we reduced the columns retrieved in the other look up
Technical Details
Note that
explains our final default of TRUE (testCompleteTransactionWithParticipantRecord)
Comments
I'm thinking about making this not-a-static-function - so it becomes $contribution->isSendEmailReceipt - the only issue would be if $this->contribution_page-id were empty due to no ->find(). Then only input would need to be passed in.