Upgrade StorageTag conflicts in group libraries
I use tags in group libraries extensively to note the status of different items being processed by the group members. Occasionally, a member will sync a library that is massively out of sync with the online version. This is fine for metadata changes--the member simply chooses to prefer the remote version. However, for tags and collections, the sync system simply adds the items to the union of the tag/collection sets in the local and remote libraries. This is awful for our workflow because many tags have been added or removed in the mean time, and now the tracking of item statuses is completely out of sync with the rest of our (non-Zotero) data. Would it be possible to adjust the sync process so that tag/collection conflicts have a choice for resolution (local/remote/union) like other item changes? Not sure if this has changed in the 5.0 beta or not. At present, with non-negligible frequency, I need to spend several hours trying to clean up the status tags in my project libraries.
Technical explanation:
In 4.0, tags and collections are first-class objects, with associated items. So if there are both local and remote tag and/or collection changes between syncs, that's a conflict, and since conflict resolution for this would be complicated, Zotero errs on the side of more data and keeps both sides, reverting the deletions.
In 5.0, tags and collections are properties of items, so if you add a tag to an item and someone else deletes a tag from another item at the same time, nothing is in conflict. If you add a tag to an item and someone else deletes a tag from the same item, that would potentially be a conflict, but 5.0 handles that too by caching a copy of the last downloaded/uploaded version of an item and comparing that to the item's current state to determine what changed locally vs. remotely, allowing it to automatically merge the local tag addition and the remote tag deletion.
Once Zotero has those cached remote versions (which it won't immediately after upgrading but will after changes are made, and we may be able to fetch them in the background), pretty much the only conflicts in 5.0 should be for the same field being modified on both sides and for files being modified on both sides.