See below... On Jul 10, 2007, at 11:48 AM, Jeffrey Harris wrote:
For recurring events, there are two sorts of deletion. If the rule changed (like an occurrence was deleted, the frequency changed, or the series' end-date changes), removing occurrences with local changes. In this case, we create a local "orphan", a normal not-recurring item separate from the original rule with a pending deletion.
Just to clarify, if the pending deletion is rejected, the recurrence rule change is *not* rejected as well, thereby restoring the orphaned occurrences back into the original recurring series.
Do the items still in the recurring series register some kind of conflict over the recurrence rule?
A different kind of deletion also happens that shouldn't really be visible to users (but there have been bugs with this that are now hopefully fixed).
Sometimes the only changes to an occurrences are to its triage status. When that occurrence's triage status changes to DONE, it stops showing in the table view because there are more recent DONE items. In a similar fashion, sharing stops syncing details about those items. Under the covers, the information about the item is deleted from the server. So when this kind of deletion happens on the server, we treat it as an inbound change that makes all attributes be inherited. This can cause conflicts on individual attributes, that's handled like a normal conflict.
I'm not sure I'm following. When these 'triage-status-based pruning deletions' happen, do the items register conflicts? My understanding was that we didn't want that to happen. But I honestly can't remember very well.
Thx for writing up this summary Jeffrey. Mimi _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
