Re: iTIP Calendar event requests

[Peter Bloomfield <PeterBloomfield bellsouth net>]

Hi Albrecht:

On 03/14/2017 04:49:32 PM Tue, Albrecht Dreß wrote:
> Hi Peter:
>
> Am 13.03.17 18:41 schrieb(en) Peter Bloomfield:
> > Balsa can send a reply to an iTIP calendar event request with possible replies of "Accept", "Accept tentatively", or 
> > "Decline". It offers this possibility only the first time you read the request (actually, if it is marked as "Unread").
>
> Also a rough edge...  It might be better to add a custom header to the message store (e.g. "X-Balsa-iTIP-Reply: 
> (Accept|Tentativ|Decline)") indicating the last operation when present.  We could then always offer the three 
> buttons (maybe make the one of the last choice insensitive?), and display this information if present, so the user 
> would have a chance to change his/her mind later.

Agreed--having a way to show the user the previous choice, if any, and the opportunity to change it would be 
good. Perhaps radio buttons?

> > Balsa finds an identity to set the sender of the reply, by matching one of your identities to one of the 
> > attendees in the event request. But I sometimes receive a request that was sent to an email alias for which I 
> > haven't set up an identity, and in that case Balsa doesn't know how to send the reply, and does not show the 
> > three reply buttons. That confused me, as it looks the same as if the message had previously been read--the 
> > display is the same in each case.
>
> Yes, that's confusing!
>
> > Alternatively, we could add an identity combo-box like the "From:" selector on the compose window. It might 
> > be shown only when no match is found, with text to explain why it's there. Or it might be always shown, initialized to 
> > the correct identity if one is found.
>
> I vote for always showing the identity and the buttons.  Not sure how much work remembering the last choice 
> (see above) would be, but I think this would be really helpful.

Remembering the choice within the session would be fairly easy, but saving it when the mailbox is closed is 
tougher. We've never implemented any way of adding information to a message in the message store, except in a 
very limited way: all the backends support flagging a message as recent, unread, or deleted, but not adding 
new headers. I guess it could be done by copying the message with the extra header to the mailbox, then 
deleting the existing message--all *very* carefully! Perhaps in reverse order, to avoid having messages with 
the same message-id even temporarily in the same mailbox.

But that seems like a lot of work!

Best,

Peter