Ensure that the oldest creation date is preserved when deduping
Normally when you go to merge 2 contacts CiviCRM will by default suggest to merging a higher cid into a lower cid which will mean that the create date on the merged records will be correct. However if you flip it so your merging a lower cid into a higher cid for whatever reason, it is likely you may find that the create date is now wrong because there may have been activites or other items created on the lower cid before the higher cid came around.
thoughts @eileen
Activity
@seamuslee yes, you are correct it should be retained. Also - I would insist on a unit test...
I've been trying to clean up the merge code - it does an awful thing where it calls profileContact.create BAO call & does an awwwwfullll lot of work to format for that, & doesn't get it entirely right. I figure that if I can sort out the custom fields first the main contact fields will be easier - hence I started with this https://github.com/civicrm/civicrm-core/pull/14325 (which fixes an actual bug too)
added ~172 git:civicrm-core sig:bug triaged labels
mentioned in issue #1589 (closed)
Hi,
Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for quite some time, so we have closed it.
We would like you to help us to determine if this issue should be re-opened:
- If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
- If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?
If the answer to either question is yes, please feel free to comment or re-open the issue. Please also consider:
- Is it something that you could help implement, either by sending a patch or hiring someone who can?
- Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?
Thank you for your help and contributions to CiviCRM.
P.S. This is an automated message, see
infra/gitlabissue 20. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.
