[Design] In Out collection logic proposal refinements

[Brian Kirsch]

Hello,
This discussion comes from bug 6857: In and Out collections should  
compute their contents based on the sender or recipient of an email,  
not the isOutbound attribute.

http://bugzilla.osafoundation.org/show_bug.cgi?id=6857


------------------------------------------------------------------------ 
-----------------------------------------
Hi Mimi and everyone else watching this bug.

I have started implementing this functionality and come across a  
number of design issues which need
to be resolved in order to continue developing the right code level  
architectual changes.

The current Chandler 'In' / 'Out' collection calculations as well as  
determining when a message is sendable, replyable, and forwardable  
are very basic.

Right now for example if a message is not outbound (A Flag on the  
Message Item) it appears in the 'In' collection.

If it is outbound it appears in the 'Out' collection.

If a message is outbound (in the the 'Out' collection) and has not  
already been sent it is sendable.

If a message is in the 'In' collection then it is replyable /  
forwardable.


First for clarity sake, when I say the 'me addresses' I am talking  
about any address configured in the Account Preferences dialog. So if  
I have an IMAP Account with an Email Address, a POP account with an  
Email Address, and an SMTP with an Email Address, then I have three  
'me addresses' to compare against. I will also preserve any old 'me  
addresses' which were entered in the Account Preferences and then  
changed at a later date and use them as well in the 'me addresses'  
comparison.

I would like to refine the exact definition of the In / Out /  
Dashboard logic to the following:

In Collection
-----------------
1. Contains all mail received via the Mail Service.
2. Contains any mail item where one or more of the 'me addresses'  
appears in the to or cc address.

Out Collection
-----------------
1. Contains all mail items composed in your instance of Chandler.  
What this means is it must contain
one of the 'me addresses' as the from or no address if the mail  
accounts have not been set up. This covers the case where a user  
composes a mail message before entering in his or her mail account  
information. A user can never enter an address in the from field that  
is not in the 'me addresses' list.
2. Contains any mail item where one or more of the 'me addresses'  
appears in the from or reply address.


Dashboard Collection
-------------------
1. Contains mail composed in your Chandler. Is this the correct  
behavior?
     Do we add all mail in the 'Out' Collection or just those you  
personally composed?
2. Contains all mail received via the Chandler Mail Service.

The sending replying rules would remain the same but be applied  
against the new 'In' and 'Out' collection behavior.

The rules are:
1. All mail in the 'Out' collection which has not already been sent  
is sendable.
2. Al mail is the 'In' collection is replyable and forwardable.

I also came across an interesting bug. No matter which Tab I have  
selected in the Toolbar (All, Mail, Task, Calendar), if I have the  
'In' or 'Out' collection selected in the sidebar and hit the New  
button an item of that stamping is created in the collection. This  
obviously not the right behavior.

I would assume going forward that this action would be disabled. The  
'In' and 'Out' collections are Read only and calculated by the coder.  
Thus a user should not be able to drag any item in to the collection  
or create new items in the collection manually.

So what should happen if a user hits 'New' in one of these collection  
or tries to drag an item in to the collection? What should the app  
do? Display a alert warning? Ignore the request?

I will also post this to the design list so others may voice their  
input.

-Brian