|wikimedia/fundraising/crm/civicrm : master||Fix dedupe screen to always set the checkbox to 'ticked' where data would otherwise be lost|
|wikimedia/fundraising/crm : master||Move logic for handling Yes-No fields during dedupe from wmf_civicrm to deduper.|
|Open||Eileenmcnaughton||T232636 Restore target smart data lost on legacy merge screen|
|Open||Eileenmcnaughton||T235450 Prevent target smart data from being lost on legacy merge screen|
I spent a while trying to replicate this & came to the conclusion that
- most instances seemed to be cases where the lower contact id had been merged into the higher contact id (indicating the contacts had been 'flipped')
- the checkboxes to carry across the data were not checked.
Generally I found this hard to replicate until I realised that I was sticking with merging the newest into the oldest (as the script and the deduper do) but the cases where data was lost generally were the reverse.
In general a lot more care needs to be taken on the old screen because it does not apply rules - for example the Deduper will handle the addresses according to the same rule used for the script, whereas the legacy screen requires the user to specify the way to handle the address - leading to the need for flipping & the ease of missing checking some boxes. While this can be prevented by users being 'careful' it seems better we think about UI ways to prevent mistakes or simply ignore user input & handle by script.
After a bit of code diving I came up with a fix that makes it checked by default if the contact about to be removed has data in any (non location) field and the contact being kept does not - this would apply to prospecting fields & also to fields like middle name or other custom fields
Some screenshots here
@mbeat @NNichols @RLewis does this seem OK as a fix. It is a small change in behaviour for users of the dedupe screen but one that should make it harder to accidentally loose data (at the expense of it being easier to accidentally keep rubbish data