Lists are merged by appending non-duplicate elements. You may get “duplicates” where two elements are intended to be identical, but differ by some small detail.
Merging single value fields is more interesting. In the case of privacy, you will want an object to be marked as private if either object is private. However in most cases the resultant value will depend on which object is merged into the other.
It sounds like this behavior could turn Privacy into a creeping infection in Sync’d trees. You’d have to go into every Tree instance and set each data element to Public … even 1 being missed would keep reverting all the sync’d trees back to Private.
Could become quite tedious.
This conversation is all well and good, but let’s face it, the only way forward is make GRAMPS into a full multi-user environment. This would mean adding user access rights to all levels of the application.
That’s likely.
So the Gramps Web has become the testbed for the issues involved. Making core friendlier for syncing, adding the undo transaction log with user tracking, and establishing prcedents for merge priorities will all help move that direction. And establish where the core needs major overhauls to support collaborative work.
We may even discover it isn’t a viable evolutionary path. That might tell us a radical rewrite is required.
But whichever is true will become more apparent through this process. The friction points and frustrations will create the storyline.
This is one of our long-term goals. The plan has been to allow multiple users to access a Gramps database on a server.
Do we need to re-assess this now that we have Gramps Web?
What functionality would you like to see?