[Chandler-dev] Dashboard domain model questions

[Bryan Stearns]

I've been over the dashboard spec again, and made this list of what I 
think are the requirements that affect the domain model. I don't have 
proposals for resolving these - I'm sending these to the list so that 
the services folk can start mulling them over.

Also, I made a quick list of tasks represented by requirements the spec 
here: 
<http://wiki.osafoundation.org/bin/view/Journal/DashboardTasks20060629>. 
It's not prioritized or organized or prioritized yet, and some of the 
notes have questions that I'm still working on answering.  I'll be going 
over it in more detail, and figuring out dependencies, but the biggest 
dependencies are the domain-model issues, so I wanted to get the first 
discussion going.

...Bryan

-- Domain Model Issues --

Sorting
- New indexes, or indexing changes, to represent complex sort orderings 
like sectioned-triage (which has different sorts for sections, at least 
one of which is spec'd to order differently forwards and backwards) and 
the who/date/comm/reminder columns (which depend on presence/absence of 
many kind-specific attributes)
- Do we need specific Calculated methods for index-dependent dynamic 
values? (Does Calculated need to move to Schema for this?)
- For later: how to model manually-set ordering in the table (when the 
user manually reprioritizes items by dragging them within a summary view)

Ticklers
  - Are they just a special type of (or the same as) existing Reminder 
objects?
  - How to represent ticklers relative to event start time (when start 
time changes)? Do we convert to an absolute date upon set? Timezone 
interactions?
  - How to represent ticklers relative to current time? Do we convert to 
an absolute date upon set?
  - How to model ticklers with no date set (eg, when user removes the 
date from the Date column of a non-event with a tickler)
  - How to model ticklers which persist after firing (do we need a 
"fired" boolean, to avoid re-finding fired ticklers?)
  - How to model ticklers vs recurrence?

How to represent triage status
  - How to represent pending-but-not-Purged triage status?
  - How to represent last time Triage changed (needed for sorting)
  - How to set automatically triage status to NOW when a tickler time 
arrives
  - How to set automatically triage status to NOW when a start datetime 
arrives (should all events have a hidden tickler for this?)

Sections (these are more CPIAish)
  - Where to persist open/closed state of sections in a general way
  - What's the architectural connection between columns and sectioning? 
(Right now, columns specify an attribute name, and the attribute name is 
used for indexing and sectioning)

General domain issues
  - Are we sticking with attribute redirection as it is? This impacts 
how the complex decisions about what to show in Who & Date work, and 
hence how sorting works. (Bug 2167)
  - How to represent (and what mechanisms will update) First-time 
Communication, Update, Created, Edited, Draft, Queued, Sent, Error (and 
in future, Forwarded, Replied To)
  - How to update LastModified (same as Edited?) time?
  - Need to represent Read/Unread state; by what mechanism should it 
change? (nb, "clicking on an unread row also marks the item as read")
  - Need to represent Needs Reply - is this just a boolean field that 
defaults to False, is settable by the user clicking on the comm cell, 
and is cleared on Send?
  - How to represent In versus Out versus Neither
  - Who/Date column labeling specifies displaying selected attribute of 
most-recently-selected item if more than one is selected. How should we 
model and persist selection order in table views?
  - How to model calendar events with no date set (eg, when user removes 
the date from the Date column of an event with no tickler): do we make 
startTime optional? There's also a future requirement to store 
'gobbledygook' in the start time field, though I don't know what this 
means for sorting, attribute-editor picking, etc.
  - For future, displaying items more than once in the summary would 
preclude assuming one collection member == one row; do we need a 
different model for this?