-
-
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
Alter dedupe code to call api rather than bao->save() #20036
Conversation
(Standard links)
|
Hi @eileenmcnaughton - I can certainly run it at least =] |
7ee520e
to
28a1369
Compare
This achieves 2 things 1) hooks are no longer bypassed 2) it leverages core handling for is_primary rather than this somewhat unreliable attempt
28a1369
to
de7b2b2
Compare
@JKingsnorth I've updated this code to have the actual change in it now |
@eileenmcnaughton this is on my list for tomorrow. We actually have some custom code that forces location entity hooks to trigger during the merge process, so I'm going to do a thorough test of before and after this, including how the hooks behave =] Sorry for the delay. |
Thanks @JKingsnorth |
I tested this by merging two contacts, with an address, email, phone and website each. The merge completed successfully, and overwrote the location entitles, as desired. Before the patch, these hooks were called on merge:
After the patch:
The address I tested also had a custom field attached, which came across OK too. So this all looks good to me! 2 problems I found which exist in core without this patch...
and more seriously... During merge I chose NOT to take a website across, but it came across to the contact anyway. Shall I raise a gitlab for that @eileenmcnaughton ? This only happened with the 'website' entity. |
@JKingsnorth yes - please log in gitlab @seamuslee001 can you merge based on ^^ |
Merging based on @JKingsnorth 's review |
Overview
Alter dedupe code to call api rather than bao->save()
This achieves 2 things
Before
After
api call.
Technical Details
I feel pretty sure we've had requests to not bypass hooks in the past but my current reason is that I can't figure out a way to handle a particular situation in an extension - this is where the contacts have the same email but one is on hold and I want to update the email to be on hold but not wind up with no primary emails (which is what is happening) and not make a change before the dedupe actually runs.
If we call the BAO::create (via the api) then we get the benefit of core is_primary handling
Comments
@JKingsnorth @pfigel are either of you up for review on some more deduper work