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
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
