rewrite party_merge() [#1669708]

party_merge() was experimental to begin with and is now broken ;)

What we do here probably depends to some extend on what we want out of a deduplication system -- as in, do we want extra params to pass in here about things such as which data sets to take from which party, etc etc?

Comments

Comment #1

joachim commented 19 July 2012 at 07:04

Priority:

Normal

» Major

Also I think this is doomed:

  $second->merged = 1;
  $second->merged_party = $first->pid;

What about when you merge party A into party B, and then B into C?

Do we even need to keep this record anyway?

Comment #2

andrewbelcher commented 19 July 2012 at 08:12

Have we decided a technical process for merging? If not, I'll get the ball rolling with some suggestions:

De-duping

We have a page which performs a search looking for potential duplicates. We could do something really complicated based off the relation module (at BadCamp in Brighton there was a talk about how you could get scores based on a number of relations between two entities... this could be quite powerful for finding duplicates?). Whatever we do needs to be able to take into account attached entities and should probably have some kind of hook so that other modules can bring in their own matching criteria.

I think this manual approach of reviewing potential duplicates is a lot better than trying to make it automatic...

Merging Parties

Once a user decides they want to merge parties (possible more than 2?), a few things would need to happen. Single data sets (ie 'Individual Profiles') would need to be merged, multiple ones would need re-attaching to the party that's being preserved etc. I think it's important in this process that there is a preview of the merged data before it's actually performed. This preview would have the merged data, as well as the ability to see and use the other data available for that potential field. Fields with multiple cardinality can be appended etc?

On submission, the new data would be saved. I think there are 2 ways of doing this that would be sensible:

1) The merged party is saved against one of the existing parties and the old party is then marked as deleted (possibly with a new pid either on the party table or on a separate merged table so we can see a 'history'). All references to the old parties would need updating to reference the remaining party.

2) The same as above, except you create a new party for the merged data and then mark the old one as deleted. The advantage of this is that attached entities (such as profiles) could be left against the deleted parties in case they ever needed viewing...

What about when you merge party A into party B, and then B into C?

So from that, I like the idea of keeping track of how parties get merged.... In your scenario, we just need to make a decision whether A gets updated to point to C or if our 'ghosting' process will track it as many steps as required.

I definitely think we want the default to be for this to be a reviewed process rather than automatic, although the merging of the data for the review process could be applied without input if we need it to in the future...