ContentItem sharing (Was Re: [Chandler-dev] What attributes get shared over EIM)

[Bryan Stearns]

Comments inline below...

Grant Baillie wrote:
> [cosmo-dev@ CC:ed, Reply-To: set to chandler-dev@]
>
> So, I've been looking through the Chandler domain model to see what 
> remains to be done w.r.t. EIM for Preview. Here's the laundry list of 
> stuff that's related to ContentItem/Note and Stamps: I'll send out a 
> separate email for the rest of the domain model (mainly, collections), 
> since those are more dump-and-reload than sharing (morsecode) specific.
>
> Feel free to chip in with stuff you think I've missed or 
> misunderstood, or to answer/ask questions.
>
> I added some little codes to track what I thought the Cosmo impact of 
> the changes would be:
>
> [√] == would need parallel change from Cosmo
> [X] == no change needed from Cosmo (but needed for dump/reload porpoises)
> [?] == unsure if this requires changes (i.e. part of morsecode)
>
> - Morgen sent out an earlier email about triage in ItemRecord
>
> - Unsupported fields in ItemRecord:
>
> [X] error (a string)
> [?] read
> [?] needsReply
> [√] lastModification: An enumeration to say whether the last change was
> queued, edited, sent, updated. I should probably
> add the 5th state, created, too.
> modifiedFlags: This is a "bitfield" of the values in lastModification.
>
>
> - In the ItemRecord code
> # TODO: see why many items don't have createdOn
> [X] I'll look at this
>
> - ItemRecord (importing triage):
> [X] # TODO: do something with auto
I've got changes for this in the triage-recurrence branch; I hope to 
merge these into the trunk today or tomorrow.
>
> - In the NoteRecord code: there are TODOs in the import & export methods:
> ...
> [?] # TODO: REMOVE HACK: (Cosmo sends None for empty bodies)
>
> I'm not sure what this is about ...
>
> - NoteRecord currently has:
> # Note.reminders? (Translator not implemented yet)
> reminderTime = eim.field(eim.DecimalType(digits=20, decimal_places=0))
>
> [√] My understanding here is that Bug 7915 (and iCalendar 
> interoperability)
> imply that we should have a separate ReminderRecord (or, AlarmRecord, if
> we're going with iCalendar-like syntax). What do people think of that?
>
> - EventRecord:
> [√] icalParameters and icalProperties should probably move to NoteRecord,
> since VTODOs (and VJOURNAL, if anyone ever supports that :) can have
> them.
>
> - EventRecord:
> [√] # TODO: EventRecord fields need work, for example: rfc3339 date 
> strings
>
> - EventRecord:
> (when exporting event modifications)
> [?] # TODO: yield a TaskModificationRecord if appropriate
>
> - EventRecord needs support for autoTriage when that's checked in
> [?]
> (possibly this has been taken care of in the Chandler triage_recurrence
> branch).
Most of the autotriage mechanism is done in the triage-recurrence 
branch; I haven't added the calls to actually do autotriaging when an 
updated item is received; I'm planning on doing it soon, though I dunno 
whether it'll be before the merge.
>
> - {Event,Task}ModificationRecord:
> [√] Do we need to think about supporting a 'modifies' field à la
> iCalendar RANGE (IIRC)? It's possible Chandler will support
> THISANDFUTURE more robustly (Currently, we just make a new
> recurring series in this case, which is probably what Cosmo
> does, too). Maybe this could just be a future addition to the
> schema?
>
> - MailMessageRecord:
> [?] I believe there are more fields needed besides subject/to/cc/bcc; I'm
> not sure if we need the complete rfc2822Message LOB (at least for
> dump/reload). Probably this is more Mr Kirsch's area, but I can take
> a look if need be. Also, Brian, were you working on the non-MailStamp
> parts of dump/reload (e.g. account info, mainly)?
Not quite what you asked, but I have a separate change (not in the 
branch, not checked in), that adds an "originators" attribute to 
MailStamp, displayed/edited with the other email addresses in the detail 
view as "From"; the existing fromAddress attribute is manipulated by the 
byline Send As mechanism.

There's more required that I haven't done yet (displaying the send-as 
address value until the user puts a custom value in the originators/From 
field; copying valid addresses from originators to CC on reply, putting 
the originators list in the body prefix for non-Chandler users, etc). 
This will get finished after the branch is merged.

I haven't looked at the mail spec or ongoing discussion in detail, but I 
don't know whether the byline spec requires anything more than what's 
there now.

...Bryan