-
-
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
Fix Contribution.create to not attempt to set contacts on activity update #19202
Conversation
(Standard links)
|
…date In udpate cases the original allocations were more correct
3df7ea6
to
6fd7535
Compare
test this please |
@demeritcowboy is this one you could review? |
Note test cover in related PR (now stale but I will rebase once this is merged) |
I'm having trouble seeing where this comes up and reproducing it? "pending activity is attached to more than one contact" - what does that mean? Multiple targets for a contribution? |
@demeritcowboy yes sorry - that would be the case in an on-behalf of contribution. When you donate on behalf the source is the individual and the target is the organization (I think it's that way around). A pending contribution is created & a scheduled activity & then completeOrder is called. Currently the Contribution.create BAO messes with the activity and then the completeOrder function fixes it again - see https://github.com/civicrm/civicrm-core/pull/19200/files#diff-4c9d0b1abe07057a4eea2b47bc627eecb95face8ed8d86c1c005312a52cca811L4353 (I'll rebase that PR now too in case it's easier to look at that than this) |
I'm experiencing what I believe is a variant on this. It happened when I upgraded a site to 5.32 (from 5.31). I have a CiviRule that sets a thank-you date on a contribution, which updates the contribution via API. On 5.31 this works; on 5.32, I get a SQL error because it's trying to create an
|
@MegaphoneJon does this patch fix it for you in that scenario? |
@eileenmcnaughton I've been trying and failing to replicate this problem in a dev environment, but I've reviewed the code and feel comfortable deploying this in production. Because of the intermittent nature, I would need a day or two to collect sufficient data to report if it's working - but it looks good IMO. That said - |
// correctly created and we risk overwriting them with | ||
// 'best guess' params. | ||
$activityParams['source_contact_id'] = (int) ($params['source_contact_id'] ?? (CRM_Core_Session::getLoggedInContactID() ?: $contribution->contact_id)); | ||
$activityParams['target_contact_id'] = ($activityParams['source_contact_id'] === (int) $contribution->contact_id) ? [] : [$contribution->contact_id]; |
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.
Summarizing the logic here: $params['source_contact_id']
seems to be a new thing that means "the on-behalf-of individual", so the first part is "if we came from on-behalf-of, use the individual contributor as the activity source contact, otherwise do what we did before". Then the second part seems to be "if we have just set the activity source to the same thing as the contribution contact, then blank out the existing activity target (because otherwise it will duplicate source), otherwise overwrite with the contribution contact", so it's saying that the contribution contact is the correct one to use for the activity target, regardless of what was on the activity before or whether it's on-behalf-of or other. That might be right, it's just trying to convince myself it's true in the generic case.
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.
Ok I misread the part above. So this block is only for new activities. So then my question would be is changing a contribution contact by calling api contribution.create an officially supported operation, and if so, what should happen with the activity's contacts. Before it would update the activity to match, now the activity target is still the old contact.
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.
@demeritcowboy I don't think changing an activity via contribution create is supported.
The flow we need to work for repeattransactions is to be able to create a new contribution with the same activity contacts as the template activity. Since the contribution.create is taking responsibility for creating the activity I think it needs to do so with the correct activity contacts
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.
Ok I don't have anything else then.
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.
Thanks @demeritcowboy I'll see how @MegaphoneJon goes with this patch over the next few days
@MegaphoneJon was there a stack trace with that error - is it hitting these lines or a different set of lines? |
My client is reporting that this patch fixed their issue. @demeritcowboy I have a backtrace, but to my surprise I found instances of this that predated my 5.32 update, so on the one hand it seems unrelated - on the other, it just as clear must be related.
|
Maybe it's the logic just above that line, or a permissions thing, e.g. when someone without delete permission goes to update, if the DELETE above that line silently fails, then it would lead to a duplicate when it tries to insert. Except I can't seem to make that happen. But that would explain the pre-5.32 fails then. |
@demeritcowboy @MegaphoneJon do we have an opinion on whether this should be merged? |
No objection here. |
No objection here either. |
@seamuslee001 @colemanw could one of you merge based on the (ahem soft) +1s above |
I don't know how to replicate the original set of circumstances, which is why it's "soft" - but it definitely fixes a bug I'm seeing, and my review of the code suggests that it shouldn't have negative side effects. I'm definitely in favor of merging it. |
:-) |
@MegaphoneJon in fact the original bug is more of a cleanup - ie there is extra code in completeOrder that should not be needed |
merging as per reviews from @demeritcowboy @MegaphoneJon |
Thanks @demeritcowboy @seamuslee001 @MegaphoneJon - I've rebased #19200 which adds the test where this was encountered |
Overview
This fixes a bug whereby updating the status of a contribution where the related activity exists and has attached contacts results in the contacts being overwritten. This is relevant to the case where a pending activity is attached to more than one contact
Note this is in PR #19200 and covered in that test but I pulled it out for readability.
#19200
Before
The values passed to Activity->save() contain target & source contacts regardless of whether it is an update or a new activity. The ids used are less likely to be accurate during the update than in the original create as the create is likely to be in a form context
After
Original values are not overwritten
Technical Details
Comments