Hi Folks, I was just about to write all this in bug 6978 (an ever increasing number of occurrences show up when viewing the in the In/Out collections), but I realized I had a few design issues to raise, so I'm taking this to the list.
There are a variety of things that need to change to make recurrence work with mail. We've decided that for preview, mail actions applied to recurring events should always apply to the whole series. This work lives at the intersection of mail, UI, and recurrence, so it's not clear to me who should do what, regardless of who implements what, I'll try to articulate the different tasks I see right now. 1. Adding or removing a communication stamp, adding or removing an addressee, or hitting send from a recurring event should only be allowed to apply to the whole series. Should the all/future/this dialog pop up in any of these circumstances, to warn the user the action applies to everything, when in other cases users have more choices? 2. In alpha5 I've taking on changing the table so when it's displaying a recurring event, it will display modifications and at least one now/later/done occurrence if such an occurrence makes sense, regardless of what masters or occurrences are in the collection. Doing this should make bug 6978 go away. We could stop there, but I think it might be useful (and almost certainly easier for people who are used to other mail clients to wrap their heads around) if we only have one row per communication in the In/Out views. That would mean those views would behave a little differently from other table views, which would require more work. Does this seem like a useful feature to pursue? Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
