No Data Loss Proposal

This is take 2 on ConflictResolution.

---

Preamble

PJE, Morgen, Grant and I met yesterday with Philippe, Brian Kirsch, Jeffrey, Katie and Sheila in attendance to continue working through the intricacies of managing sharing and edit/update conflicts.

The original proposal discussed during the last on-site can be found here:

Since then, we have drastically simplified the design and attempted to reframe the entire proposal as a 'No data loss' proposal, rather than a 'Conflict Resolution UI'. The reasons are many and varied and there are others better equipped to explain them than I.

Below is a 2nd stab at a UI / workflow proposal to deal with what we are now calling 'pending changes' aka changes people make to items whilst unaware of changes made by others. Such 'pending changes'

What's important to keep in mind is that changes made by 'other people' are always considered 'pending' and never automatically overwrite changes made by you. In other words, every Chandler is 'sovereign' of their own repository.

Please review the wiki proposal. As usual, there are some changes from what was agreed upon in yesterday's meeting, the most important of which is: When an item has been deleted and a conflict is detected, the item is *NOT taken out of the Trash. Instead, the Trash collection displays an error icon.*

Assumptions

• We can't know specifically which user edits conflicted with which user edits, e.g.
  • User A deletes item
  • User B changes Title on that item
  • User A removes addresses from item
  • User B adds an addressee to the To: field on that item
• We don't keep track of who made a particular change and when.

Design requirements

• Users should be given all of the information they need to know about a conflict before being asked to resolve them one way or another.

Scenarios

Conflicts we care about in the Preview timeframe:

• Direct attribute conflicts: e.g. 2 or more users edit the Notes field
• Indirect conflicts: Stamping conflicts: e.g. User 1 removes addresses from an item and User 2 edits the To: field on the same item
  • Remove/Delete conflicts: e.g. User 1 remove/deletes an item from a collection and User 2 edits that item. (This of course would NOT be a conflict if User 1 removed an item from a collection, but Users 1 and 2 were sharing the item in question in a 2nd collection.)
  • Time zone conflicts: e.g. User 1 changes the date/time of a meeting. User 2 changes the time zone.
  • Recurrence conflicts: e.g. User 1 changes the recurrence rule on an item, thereby 'deleting' an instance in the event series that User 2 edits.

Strange Delete and Remove Scenarios

Person who deletes detects the conflict

1. User A deletes an item from a shared collection, meanwhile...
2. User B edits the Title of the item and syncs with the server.
3. User A empties their Trash. Chandler syncs with the server and detects a conflict on the deleted item.
4. Item remains in the Trash
   • Trash collection displays an error icon.
   • User B's changes show up as pending changes.
   • If User A accept's User B's changes, then item is taken out of the Trash and put back into the shared collection(s).
   • If User A discards User B's changes, then item remains in the Trash and User A's delete is synced back up to the server.
   • User A then has to empty the trash again to really get rid of the item.

Person who made changes to a deleted item detects the conflict

1. User A deletes an item from a shared collection, meanwhile...
2. User B edits the Title of the item.
3. User A empties their Trash and the item disappears. At some later point, Chandler syncs with the server. No conflicts are detected and the item is deleted from the Trash.
4. User B syncs and detects a conflict.
5. User A's deletion is presented to User B as a pending change.
6. If User B accepts User A's deletion, then the item is moved to the Trash.
7. If User B discards User A's deletion, then the item is synced to the server with User B's changes.
8. When User syncs next, the item will be 'resurrected' in the shared collection(s).
   • Side effect: Resurrecting items will resurrect them in all collections, not just in the shared collection in question. Not sure if this is the right behavior, tracking this issue here: https://bugzilla.osafoundation.org/show_bug.cgi?id=8257

Strange Recurrence Scenarios

Sharing and Conflicts: Please see NoDataLossProposal

• We will be able to detect conflicts on individual occurrences
• Conflicts on master events should display alert icons next to all affected occurrences in the Dashboard: Bug 8616
• Conflicts on "This and Future" modifications will most likely result in duplicate events.

Funkiness as a result of Chandler Server UI handling Recurrence differently

• Question What are some potential issues?

Open Issues

• What do we do with UI for weird recurrence rule changes that effectively delete instances somebody else edited?
  • We will be able to detect conflicts on global changes to the series and on changes to individual instances in the series. Does this mean that if there are conflicting global changes, every instance will display the Warning/Conflict icon?
  • What is going to happen when there are conflicts resulting from 'This and Future Changes' and changes to the RRULE itself? We won't be able to detect that there are conflicts, but we won't delete any recurrence instances that would otherwise have been 'rendered' moot and deleted by the change?
• Can we distinguish delete from remove?

Styleguide

Pending changes dialog

• There are x pending changes: Medium font size and black #000000
• Field name X-Small font size and 50% grey #808080
• Nos. and Field value Small font size and black #000000
• Changes will be applied... Small font size and black #000000
• Alternating stripes to separate pending changes

Workflow Two

1. Chandler detects conflicts on an item
2. Chandler displays conflict icon in the Communication status and moves item to the top of the NOW section without changing the item's 'Real' or 'Color' triage status.
3. Chandler displays a message at the top of the item's detail view
4. User selects item
5. User clicks on 'View changes' in the detail view message area
6. Pending changes dialog pops-up (non-modal) with the following information
   • No. of pending changes
   • List of pending changes includes: Name of field that was changed and the value of that field
   • Other changes include: Item deleted, Item removed from 'collection name', Addresses removed, Addresses added, Removed from Task list, Added to Task list, Removed from Calendar, Added to Calendar
7. User has following options on each individual pending change
   • Apply change
   • Discard change

• • OR, user can:
    • 'Decide later' if they haven't Applied or Discarded any changes
    • 'Finish later' if they've started to Apply and/or Discard changes, but haven't gotten rid of all of them
    • Click 'Done' if all pending changes have been resolved.

• • OR, user can copy and paste select changes from dialog into the detail view and then discard all changes.

• • User cannot send out Updates or sync edit they have made on attributes with pending changes back to the server until all pending changes have been either Applied or Discarded
  • Once changes have been applied or discarded, new 'definitive' version of the item is automatically sent out as an update.
  • At some later point, the item is 'fully' synced to the server.

Note 'Decide later' button changes to 'Finish later' and then finally 'Done'

---

Deferred Proposals

Workflow One

1. Chandler detects conflicts on an item
2. Chandler displays conflict icon in the Communication status and moves item to the top of the NOW section without changing the item's 'Real' or 'Color' triage status.
3. Chandler displays a message at the top of the item's detail view
4. User selects item
5. User clicks on 'View changes' in the detail view message area

1. Pending changes dialog pops-up (non-modal) with the following information
   • No. of pending changes
   • List of pending changes includes: Name of field that was changed and the value of that field
   • Other changes include: Item deleted, Item removed from 'collection name', Addresses removed, Addresses added, Removed from Task list, Added to Task list, Removed from Calendar, Added to Calendar
2. User has following options:
   • Apply changes
   • Discard changes
   • Decide later on changes
   • Copy and paste select changes from dialog into the detail view and then discard all changes
   • User cannot send out Updates or sync edit they have made on attributes with pending changes back to the server until all pending changes have been either Applied or Discarded
   • Once changes have been applied or discarded, new 'definitive' version of the item is automatically sent out as an update.
   • At some later point, the item is 'fully' synced to the server.
   • The following text is inserted into the top of the email body for updates: 'User xxx' resolved '#' pending changes on 'Item title':