[Cosmo-dev] recurrence and triage status
Jeffrey Harris
jeffrey at osafoundation.org
Mon Jul 23 18:30:22 PDT 2007
Hi Folks,
Today Morgen saw shared recurring events not doing the right thing with
triage status, and we figured out that triage status just shouldn't be
working very well when people move shared meetings from NOW to DONE quickly.
The problem stems from the fact that we serialize triage status on past
DONE events and future LATER events the same way on recurring events: as
Inherit, or no value.
We do this to avoid filling up the server with hundreds of outdated
records for old recurring events that have no distinguishing features
besides being in the past.
Here's how this goes wrong:
1. Persons A and B share a recurring meeting with an occurrence in the
future, on July 30, triaged LATER for A and B
2. July 30 arrives. A and B's occurrences both move to NOW.
3. Person A immediately marks the meeting as DONE, then syncs. It turns
out that this doesn't do anything, because the server used to have a
future LATER event, which is serialized the same way as the past, DONE
event.
4. Person B syncs. They haven't gotten around to marking the meeting as
DONE, but nothing's changed on the server, so B's Chandler doesn't know
the NOW triage status is out of date, it just sends up a record to the
server saying July 30th's meeting is triaged NOW.
5. Person A syncs. The July 30 meeting is triaged NOW again, although
no one meant for it to be that way.
I pulled my hair out for a while trying to figure out a way to fix this.
It would be easy to fix with a Morse Code schema change, but it really
seems late for that.
Here's my idea of how to avoid a schema change: The master record's
triage status field is currently meaningless, because triage status
depends on start time, and each occurrence in a recurring series has a
different start time.
We could fix step 3. above by storing the date of the most recent DONE
occurrence in the master's triage status field. Then it would be clear
(after a bit of calculation) whether a non-existent occurrence on the
server was actually an inbound change from NOW to DONE, or if the event
in question ought to be triaged NOW.
I think this is mostly a change that could be made in Chandler, but I
wanted to check in and see if changing the semantics like this would be
a huge hassle for Cosmo.
Sincerely,
Jeffrey
More information about the cosmo-dev
mailing list