My conversation with Jeffrey about Recurrence and the Dashboard
spawned some other funny behavior things related to Calendar and
Dashboard:
(Let's discuss it at next week's Design Session?)
1. When a user changes the triage status of an item and then returned
that item back to the original triage status (ie. From LATER to NOW,
through DONE back to LATER), the instance doesn't always get 'pruned'
or re-incorporated back into the instance that represents all LATER
items in the LATER section. I believe that the pruning ONLY fails to
happen if the user first triages the item in the Calendar App area
and then continues to change triage status in the Dashboard view. Is
that correct Jeffrey? I think this is bug: 7903: https://
bugzilla.osafoundation.org/show_bug.cgi?id=7903
2. When users triage items in the Calendar App area, they aren't
automatically 'purged' or 'filed' in the Dashboard. As a result,
items may not show up where users expect them to if they triage in
the Calendar and then switch to the All app area. http://
bugzilla.osafoundation.org/show_bug.cgi?id=7899
3. Once an user 'explicitly' sets the 'unpurged Triage status' on an
event, all auto-triaging of the event based on the event's start and
end time stops. (Tickling the item in to NOW based on an alarm date
and/or the event's start-date/time counts as an explicit setting of
Triage status.) We actively want this behavior, but currently there
are no plans to re-institute auto-triaging if the user explicitly
realigns the Triage status of the event with the event's date/time.
http://bugzilla.osafoundation.org/show_bug.cgi?id=7901
4. New events that are created (anywhere: Dashboard view, Calendar
view, CLI toolbar text field) should show up in the NOW section of
the Dashboard, auto-triaged appropriated based on the event's date/
time. This is really more of a clarification than a bug :o)
5. All the rules for auto-triaging an event based on its date/time
ALSO apply to any alarms that have been set on the item. e.g.
+ If an event has an alarm on it from the past, then the event should
be in NOW, even if the date/time of the event is in the FUTURE
+ Nothing should be placed into DONE because of the alarm date
4 and 5 are clarified in the Dashboard spec as well: http://
svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Dashboard-0.7.html
On Jan 25, 2007, at 6:45 PM, Jeffrey Harris wrote:
Hi Folks,
As of r12941, recurrence and triage status have new behavior.
Dashboard
=========
In the dashboard, one item should show up per modification, and there
should always be at least one DONE and one LATER modification
(assuming
there are any occurrences in the future or the past).
The first occurrence always shows up in the dashboard, too, but that's
because I misunderstood Mimi's requirements, so that will be going
away
soon.
To cut down on the number of redundant items in your dashboard, the
recurrence model should "prune" the list of modifications, so, for
instance, you don't end up with 20 occurrences of the weekly
meeting all
in your done section.
Examples
========
This new behavior can be explored by looking at a recurring event
(that
starts in the distant past) in the dashboard.
Select a DONE occurrence. If you change its status to NOW and hit
Triage, the old DONE will become NOW and a new DONE will appear.
You can change the original DONE event's status from NOW back to DONE
and hit triage, and the new DONE event that appeared before will
disappear.
Calendar
========
When viewing recurring events in the calendar, all occurrences in the
past (except the very first one) should default to a triage status of
DONE or LATER, depending on whether they're in the past or future.
You can click through recurrence states on occurrences without popping
up a recurrence prompt, triage status changes always apply to the
selected occurrence.
Known issues with this nexus of features are in bugs 7891, 7902, 7903
and 7904, feel free to find more.
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
