Available from https://github.com/cmollekopf/docker.git

Available from https://github.com/cmollekopf/docker.git

A first version is available from: https://github.com/cmollekopf/docker-kdesrc-build.git

Can be reproduced using the docker images kontact:latest against kolab/kolabtestcontainer

The relevant patch has been reverted

I think ENTITYDISPLAY crept back in by accident when I removed the explicit setKeepLocalChanges call (I didn't realize the base implementation added that probably).
At least it looks like that from kdepim-runtime 4aabe17fb8747976f3669470f96c3f3b6862f7e4.

In T190#3159, @mollekopf wrote:

In T190#3158, @mollekopf wrote:

• A folder with an unknown annotation shouldn't fall-back to mail, it should be ignored instead.

The last point doesn't apply to getFolderTypeAnnotation. isHandledType should already correctly ignore unknown folder types, so I'm not sure why it's recognized as a mail folder.

getFolderTypeAnnotation should continue to return annotations.value(KOLAB_FOLDER_TYPE_ANNOTATION); (without shared or private), for backwards compatibility. But only if no
shared or private annotation is found.

In T190#3158, @mollekopf wrote:

....

getFolderTypeAnnotation should:

• ignore empty annotations
• private overrides shared annotations
• A folder with an unknown annotation shouldn't fall-back to mail, it should be ignored instead.

The emtpy annotation is a bug possibly in kolabd or so (whoever create the folder with that annotation)
That said, we can work around it by ignoring empty annotations.

Nevermind, the kolab-resource wasn't started due to linking problem in the binary.

Another case:

We also need to investigate how it can happen that a folder is available, but containing a bunch of items with either no or the wrong payload parts (so the itemretriever ends up going to the server for every single item.

This is happening as part of a large sync:

First we need to figure out why we have so many rowsAboutToBeRemoved signals, if we indeed require that many, MessageList::Core::Model::index likely needs to be improved.

To fix this problem we need a non-blocking fetchjob that triggers the on-demand sync, but doesn't manually retrieve each individual message.
That way we can avoid blocking the session, and messages that could not be retrieved immediately will be added to the ETM via monitor signals.