Hi Mimi,
> ---++++Edit and Update Scenario > A creates an invitation to send to BCDE > > * B is a Chandler user sharing the invitation with A > * C is a Chandler user, not sharing > * D is a Scooby user > * E is an email user [snip] > ---+++C the Chandler User, Not-sharing > * C can see the invitation in their Chandler, in the collection they > share with A as soon as A has created the item and a sync happens. The > invitation is auto-triaged in C's Dashboard to Later, because it is an > invitation for an event scheduled in the future. Hmm. If C isn't sharing, I think the stuff about sharing with A is erroneous here. > * When A sends the invitation, C receives the invitation in their > email client; AND > * C receives the invitation item pops into the NOW section of C's > Dashboard > * C can reply to the email in their email client; OR > * C edits the item > * C updates the item > > * A receives the update in their email client as a separate email in > the same thread; AND > * A receives the update to the original invitation item in their > Chandler / Dashboard NOW section > * B receives the update in their email client as a separate email in > the same thread; AND > * B receives the update to the original invitation item in their > Chandler / Dashboard NOW section > * C receives the update in their email client as a separate email in > the same thread > * D receives the update in their email client as a separate email in > the same thread; D can click on a URL ticket to view / edit the item on > Scooby > * E receives the update in their email client as a separate email in > the same thread Does Chandler somehow know that D is a Scooby user but E never uses Scooby? I've been assuming we'd just send them both a Scooby URL, is that a reasonably assumption? [snip] > ---+++E the Email client User > > * E receives the invitation in their email client > * E can reply to the email in their client > > * A receives the reply in their email client as a separate email in > the same thread; AND > * A receives the reply to the original invitation item in their > Chandler / Dashboard NOW section as a separate email in the same thread > * B receives the reply in their email client as a separate email in > the same thread; AND > * B receives the reply to the original invitation item in their > Chandler / Dashboard NOW section as a separate email in the same thread > * C receives the reply in their email client as a separate email in > the same thread; AND > * C receives the reply to the original invitation item in their > Chandler / Dashboard NOW section as a separate email in the same thread > * D receives the reply in their email client as a separate email in > the same thread Are you hoping everyone who responds will remember to use reply-to-all? Many users (myself lamentably included) occasionally forget to use reply-to-all when they intend to. If we end up sending different tickets (and thus different messages) to different users, reply-to-all isn't even an option, there will likely be multiple emails sent, with different addressees. That's really an argument against per-user tickets, in my mind. We could put multiple recipients in the reply-to field, so at least the first response from a non-Chandler user would probably go to all the original recipients (assuming their mail client handles multiple reply-to addressees, I have no idea how common that is, Thunderbird supports it). Unfortunately ad-hoc reply-to fields aren't sticky, so if E replied to all, some other email user might just reply to E instead of sending it to everyone else. I think no one uses this feature because it's likely to confuse more than help. Perhaps this isn't worth worrying about, but I thought I'd point out that we shouldn't assume email responses will reliably propagate to the right people. The same is true for email by itself, and obviously the world goes on. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
