Re: Registering deletes and removes as pending changes...

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