On Mar 2, 2007, at 11:38 AM, Grant Baillie wrote:
On 2 Mar, 2007, at 11:34, Dan Steinicke wrote:
What happens to the byline on the received end? I did a couple
quick tests sending mail from Chandler to Chandler. I sent both a
plain email and a email stamped as an event. In both cases the
items had bylines on the sending end but no byline on the
receiving end. Is this correct?
Well, it's expected, but not correct: the lastModifiedBy attribute
hasn't been implemented yet.
--Grant
For lastModifiedBy, the sharing layer (specifically sharing/
translator.py) is assuming that it is a bi-ref to an EmailAddress
item. The current implementation serializes the
EmailAddress.emailAddress string when sending an item; when receiving
an item, it takes the incoming email address string, finds the
corresponding EmailAddress item (or creates it if needed) and assigns
that to the item's lastModifiedBy attribute.
If we want this to sometimes be an email address and sometimes be a
sharing account, we'll need some way to distinguish this when
deserializing. Presumably the existence of an @ sign in the string
means it's an email address, otherwise it's a sharing account. But
come to think of it, that doesn't work either: say the user has no
sharing account set up (because they are subscribed only via ticket)
-- and an incoming item's lastModifiedBy record is a non-email
address string. Under the hood, what do we assign to the item's
lastModifiedBy? We don't want to create a sharing account locally
for the other person, and we don't have an email address for them.
I'm hoping we can just consistently use an email address until we
have a Contacts implementation.
~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
