Hi Sheila, > In catching up on the design list, I wasn't sure where we ended up with > this thread. Is this work scheduled for Preview? I know there have been > quite a few high priority bugs and didn't know the reality of getting to > this.
Here's what's in (already committed, that is) for deletion/removal. Not recurring ============= For non-recurring events, a deletion is queued if there's a conflict. Recurring ========= 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. 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. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
