We had a follow-up meeting today to finish going over: http://
wiki.osafoundation.org/bin/view/Journal/
DashboardSharingCommunicationsRecurrence
We got stuck on what Read/Unread status means in Chandler and in
particular, what does it mean when it comes to recurring events?
Below is my best stab at summarizing verbally how we should treat
Read/Unread status.
Unread:
+ Item you created in the CLI
+ Newly created item
+ Item changed by somebody else
That means, items are NOT marked as unread when...
+ An item is auto-triaged from LATER to NOW because an Alarm or Start
date/time rolls around
In the case of a recurring event series, when an user 'Reads' an item
or marks an item as 'Unread', we should mark all instances of the
recurring event that look just like it. (Ignoring differences in
Triage status and Date/time metadata.) This is true in both the
Dashboard and the Calendar.
The reason we want to make an exception for date/time metadata is
because we don't want users to have to mark Read/Unread status for
each individual instance in a recurring event series.
The reason we want to make an exception for Triage status is because
we don't want users to have to remark Read/Unread status for
recurring events just because the event series straddles multiple
triage status (some occurrences are happening in the future - LATER,
1 is happening right this instant - NOW and some have already
happened - DONE).
The fallout of this is that un-modified instances in the event series
might have Read/Unread statuses that are different from modified
instances.
Conveniently, this allows us to model Updates to individual instances
in a smart way, even though for Preview, we will not be able to
support Updates to individual instances in a recurring event series
or the This and Future subset of a recurring event series.
Instead, recipients of Updates will receive the entire event series
(under the hood), even if only a single instance was updated.
However, in the Dashboard, Update recipients will ONLY see the edited
instances at the top of their NOW section, marked as Unread. All
other instances of the recurring event will stay put in the Dashboard
and remain marked as Read.
So while, under the hood, we can't support edit/updates to individual
occurrences, at the UI level, we will be able to simulate it.
This of course assumes that the above proposal is doable in the
Preview timeframe...Jeffrey? ;o)
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
