[Chandler-dev] Decoupling "from" from "send as" in email, and related issues

[Bryan Stearns]

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