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.

the problem so far is that ENITIYDISPLAY is in the keepLocalCollectionChanges list, because the user can change the display name, icon etc. of folders. Maybe we should not do that.

At the moment kontact stores the color inside a configuration file.
Use backgroundColor of ENITYDISPLAY to sync this to /shared/vendor/kolab/color METADATA.

roundcubemail fixes the shared annotation:

We deiscussed and cam to the conclusion:

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.

the current behaviour is if a /shared annotation this is used. For "Files" this means isEmpty() -> use default type -> mail type [see KolabHelpers::getFolderTypeAnnotation (kdepim-runtime)]:

can confirm now with demo account and via docker image cmollekopf/kolab:latest

Maybe a duplicate of https://issues.kolab.org/show_bug.cgi?id=4095.

This works for me with Kolab_Development packages as well as on Kolab Now. Except for mass assignments. Needs further investigation the target system.

Confirmed, the web client doesn't expect/support HTML contents in the description field.

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

Another case:

can be reprocused:

I can verify it, if ktimezoned is not running in the correct session. My testsetup uses setKDEenv, that rewrites many ENV variables; but kded4 is started before.

testcase in bugreport:

No special case with task sync.

well the bug is very likely an akonadi sync issue.

cannot verify that with demo.kolabenterprise.com.

not valid anymore

can't verify anymore.

I tested it with a demo.kolabenterprice.com account and can verify it.

possible solution: with the creation of an annotation we save the status in Akonadi::MessageStatus. So we can check the availability of an annotation without need to fetch the all relations.

• create a file folder and add one file to it
• open kmail and added to to subscription list
• look at akonadiconsole to see it being created
• don't see the folder at kmail

• The problem is that the relation needs to be fetched before we can test if item has an annotation, because we need the mimetype of the relations.

search xapian db:

zanshin uses mimetype KCalCore::Todo::todoMimeType and NoteUtils::noteMimeType so we should also switch to KCalCore::Event:eventMimeType for korganizer.

show saved xantian search strings for collection 37: