Hi Mimi and Morgen, > The proposed solution is: > > 1. User A deletes or removes an entire event series from a share. > User B has local changes on one, some or all instances in that > series. > > 2. User B would accept the deletion/removal for all instances in the > series that they have *not* made local changes to.
I'm not sure what you mean here. Do we want any occurrences to go away? It seems better to me if all occurrences display a conflict, listing which occurrences had changed locally. > 3. The instances in the series that User B made local changes to > would become 'singletons' or isolated, single events. + *Q* What if > User B made a This and Future local change? Could we keep all of > those instances linked together in a recurring series? > > 4. Those remaining instances would display a 'Pending Changes' > warning informing User B that User A has deleted/removed the entire > series from the share. > > When User B applies User A's deletion, User B's locally changed > instances will also get deleted. ** * * *Q *However, when User B > discards User A's deletion, does the entire series get restored? or > just the instances User B changed locally? (I think the whole series > should get restored...) If we want the whole series to be restored, I think it would be best (at least, easiest) to not delete anything, and display a conflict on all occurrences. Then if the conflict is discarded on any occurrence, it'll go away for all occurrences. > *Grant and Jeffrey:* + Can we do something similar if User A makes a > This and Future deletion? How would that work? What happens today > with This and Future deletions if there are local changes? This-and-Future deletion is pretty different. Under the hood, we change the master's recurrence rule to end earlier, and delete any existing modifications. Probably this case should be special cased in a similar way to how we're handling deletion of the master, but unfortunately I think it's a fair bit of additional work. What we do now is preserve any modifications if they've been changed, even though they're not part of the recurrence rule any more. I suppose we could mark each orphaned occurrence as having a pending change to delete it, since it sounds like we're going to start supporting pending deletions. > + What about deletions of instances that result from changes to > Recurrence Rules? For example, User A turns a Daily event series to a > Weekly event series, thereby deleting a whole lot of instances, some > of which User B made local changes to. Can we keep User B's locally > changed instances around and mark them with the pending changes icon? In this case, we currently keep User B's old occurrences around, without marking anything as pending. Again, we could perhaps mark such orphaned occurrence as having a pending deletion. That actually seems pretty reasonable to me. > If User B discards User A's recurrence rule change, can we restore > the series to recur Daily? I was thinking discarding changes on a particular occurrence would just keep that specific off-rule occurrence around instead of deleting it (so you'd have to accept changes for potentially several individual modifications). That would be easy. But recreating the daily recurrence rule would be a big pain in the butt, I think. > *Other stuff Morgen and I settled on:* + User A's Chandler > automagically turns a modified instance back into an un-modified > instance, thereby removing that modified instances from the recurring > series and User B has made local changes to that modification, > thereby keeping it a modification, User B's local changes win and the > modified instances is put back on the server. (This works today.) > *Jeffrey*, when does this happen? If you change an occurrence's start time, move it back to its original start time, then click the triage button that occurrence will stop being a modification. Or, if you have a NOW modification, then mark it DONE, it'll eventually go away if it's not the most recent DONE occurrence. Is that what you were asking? Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
