On 18 Jan 2019, at 16:02, Benny Kjær Nielsen wrote:
On 16 Jan 2019, at 15:05, Robert Brenstein wrote:
On 16 Jan 2019, at 10:12, Benny Kjær Nielsen wrote:
On 11 Jan 2019, at 17:25, Eric Sharakan wrote:
In cases where MM can detect servers that don't support persisting
IMAP keywords, it would sure be useful if that could be indicated
to the user in some form. I know for a fact our corporate IMAP
server doesn't support them, but for my other accounts I'm not
sure.
Agreed.
It's not obvious how/when to best do this, but I'll give it some
thought (which I haven't really ever done). For example, the user
might have added a tag to a message in one account and then later
moved it to an account without support for IMAP keywords. Also,
servers always support, e.g., `\Flagged` which means that any tag
bound to this does work even when other tags do not.
I would check whether a given server supports tags when a new IMAP
source is being added and keep that as a setting/property for that
account within MM, displaying user a warning when the account is
added. I’d also add a user setting whether to display further
warnings or not.
That's the simple solution, but as I tried to argue then it's not as
simple as that. Mailboxes within the same account can have different
policies. Servers/mailboxes may support different sets of IMAP
keywords. Messages might be moved from one account to another. I
really think it's best to somehow make each tag stand out for a single
message when there is a synchronization-limitation. And then somehow
make it easy for the user to see why it stands out.
(Anything is really better than the current silent handling/failure.)
Yes, I agree. What I meant is that users get a warning right away when
connecting a source, so they are aware from the beginning whether tags
for this source are local only or not. Since MM then knows whether a
given service supports tags or not, it can warn and act accordingly for
all those operational cases that you list (if user wishes to see further
warnings). I would not mind if you made it binary, at least to begin
with, that is identifying each service for each source account as
supporting tags fully or not, partial support not being considered
unless workabout is easy and useful. For example, my having CommuniGate
Pro Server which supports only 4 custom flags is as good as having no
support for tags.
Robert
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate