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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
