[Cosmo-dev] another issue with items in multiple collections

[Katie Capps Parlante]

To make sure I understand correctly...

- Item A is considered "modified" because it was added to collection 2

- When a remote/server modification is in conflict with a local 
deletion, the remote/server modification wins (so the item is added back 
to the collection)

- If the user removed it again (assuming no other changes happen) it 
would stay removed

I'm guessing that when thinking through the case of "having the server 
win", we were thinking of a scenario like this one: user A changes the 
title of an event in the same sync cycle as user B deleting the event.

This one feels confusing/unexpected because:
- The same user is making all of the changes
- Moving an event to another collection doesn't necessarily feel like a 
"change" to an item to the user

If I am understanding this correctly, I don't think this problem is a 
server problem or even a mismatch between server and desktop 
expectations -- its a desktop issue. We already knew about it in the 
abstract, but this case gives us a concrete scenario that might affect 
our thinking. The plan of record was to live with this behavior for 
Preview -- conflict management was an 11th hour feature that we know is 
imperfect (but more serviceable than not having any conflict management).

Proposal: continue with plan of record, relnote it for Preview. Revisit 
it after Preview along with other conflict management improvements.

Alternative proposals?

Cheers,
Katie

Morgen Sagen wrote:
> On 8/7/07, Randy Letness <randy at osafoundation.org> wrote:
>> I seem to be using this subject a lot.
>>
>> Bug 10212 describes the issue:
>> https://bugzilla.osafoundation.org/show_bug.cgi?id=10212
>>
>> To summarize:
>>
>> 1. create collection 1, add item A
>> 2. create collection 2, add item A
>> 3. publish collection 1
>> 4. publish collection 2
>> 5. remove item A from collection 1
>> 6. sync collection 1 --> item A re-appears
>>
>> This is occurring because the sync operation involves getting all the
>> updated records since the last sync (the publish in this case).  When
>> collection 2 was published, it included the recordset for item A so the
>> server assumes A has changed.  When collection 1 is synced, these
>> changes are sent back before the client sends the deletions and these
>> changes override the deletions and the recordset deletions never get
>> sent to the server.
>>
>> I think this is just Chandler's policy, that is server changes always
>> override local changes.
> 
> A remote update to a local removal is the only case in which a server
> change overrides a local change.  Any other conflict goes through
> Chandler's conflict resolution framework.  I did it this way because
> there isn't a UI affordance at the moment to indicate that a locally
> removed item has been changed on the server, and undoing the removal
> errs on the side of no-data-loss.  Post preview we could certainly
> revisit this.  Mimi, can you give some input as to what you would like
> the user experience to be for an item that has been locally removed
> but remotely modified?
> 
> ~morgen
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev