[Design] In Out collection logic proposal refinements

[Bryan Stearns]

HI Brian,

There are a lot of details to get right for in & outness, and this is a 
great summary. I thought I'd add a couple of things:

- It looks like a big performance problem to calculate in-ness and 
out-ness everywhere you've shown we need it. I think it makes sense to 
go back to representing in-ness and out-ness as separate booleans, on 
ContentItem; we can use schema.observers on the various attributes that 
affect them, and perhaps a mechanism like we use for updating 
displayDate to allow the various stamps on an item to contribute. Also, 
as we've said before, changes to configured 'me' addresses on email 
accounts will probably require a separate sweep of items to update email 
items.

- Those in and out booleans won't be shared: each Chandler will set them 
up (automatically) when a new item is received (via sharing or email). 
If I'm sharing with myself and both Chandlers are configured with the 
same email accounts, I'd see the same contents of In and Out.

- It would simplify handling of corner cases in the short term to at 
least make the 'In' and 'Out' collections read-only for Preview (so no 
'New Item', no dragging in); I know Mimi has longer-term goals for 
unified In and Out (beyond just mail) that would be easier to transition 
to if users didn't have ingrained In- and Out-manipulating behavior.

...Bryan


Brian Kirsch wrote:
> 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
> [...]
> 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