I took over this small-sounding bug from Reid:

https://bugzilla.osafoundation.org/show_bug.cgi?id=7764
Add From: field to Detail View

The reporter didn't realize that "From:" (with the account-picker popup) turned into "Send as", and that the rest of the implementation of the byline mechanism hasn't been implemented yet. While investigating what "the rest of the implementation" might be, I ended up also taking these related bugs:

https://bugzilla.osafoundation.org/show_bug.cgi?id=7430
Decouple from/to from email

https://bugzilla.osafoundation.org/show_bug.cgi?id=7424
Implement "sent by/edited by" and "send via" widgets

https://bugzilla.osafoundation.org/show_bug.cgi?id=7765
Addressing fields should preserve non-email addresses

https://bugzilla.osafoundation.org/show_bug.cgi?id=7701
Left-align byline with Title and Location fields

https://bugzilla.osafoundation.org/show_bug.cgi?id=7620
Byline shouldn't be editable

In IRC, Brian suggested he'd like to hear more about my strategy for fixing this stuff, so here goes:

First, bug 7430: "Decouple from/to from email". There are separate issues here: First, "from".... the design calls for a Communications stamp "From" field that's distinct from both the "From" and "Reply-To" headers on the message. I'm intending to rename the EmailStamp.fromAddress attribute to sendAsAddress; the mail service layer will use this attribute to make the From: header on the outgoing message. Once I've verified that nothing broke, I'll add a new attribute, fromAddresses, that's a list of addresses for the "From" field, and I'll add another X-Chandler-From header to pass it between Chandlers in the message.

As for decoupling "to", I think that just indicates that we may need to be flexible as we translate the addressing fields between layers (either between mail-service message and the the EmailStamp addressing fields, or between the EmailStamp fields and the UI), because we (re-)use one item for all communications in a conversation: an item you send may be updated by an email you later receive. (I need to study the spec more here...)

Bug 7765 ("Addressing fields should preserve non-email addresses") turns out to be more complex than it looks. Currently, our model for an email address is an email address (eg, stuff, followed by "@", followed by some definition of "a domain name" like foo.com), and optionally a "full name". We sometimes try to parse these things from a single string, and if we get rid of the requirement for a well-formatted email address, we won't be as able to tell what's "email address" and what's "full name". The strategy I want to start with is: change EmailAddress's parsing code to treat a string with no "@" as a valid email address with no "full name" (this way, when we format it, it'll come out as it went in, and round-tripping will work).

Bug 7764 ("Add From: field to detail view") will be easy once the underlying fromAddress/sendAsAddress attribute confusion is worked out.

Bug 7424 ("Implement 'sent by/edited by' and 'send via' widgets") really means "finish the byline work" - most of the cases are already implemented, but need work around visibility or labeling changes.

Bug 7701 ("Left-align byline..") and bug 7620 ("Byline shouldn't be editable") are small detail-view-blocks cleanups.

...Bryan

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Reply via email to