This task has nothing to do with syncing tag colors, because tag color is a property of a tag and not trasmitted via KEP:12 (folder annotations). That's why a removed the blocking tasks.

@machniak: okay thnaks for these informations, we will see if this is enough for a good UX.

Yes, this is caching. The cache is updated when you log in or visit Settings > Folders.

I now have a version, that successfully read/write the '/vendor/kolab/color' annotation. But if I look at roundcubemail, the colors are not updated.

It was decided earlier, that this would have low priority. But recently the discussion has come up in different forums, and the priority on this needs to be raised again.

85ee6ab

85ee6ab

changing ENTITYDISPLAY behaviour will result in many uncertain things, so we decided to create a new akonadi attribute for the color and sync this.

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

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

not valid anymore

can't verify anymore.

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