can be reprocused:

Futher informations: http://wiki.kolab.org/KEP:12
use the '/vendor/kolab/color' RFC 5464 folder annotation

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

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.

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.

However, we'll have a problem in any case:

• kolabretrievecollectionstask.cpp has to set a couple of ENITIYDISPLAY attributes in any case
• without setKeepLocalChanges this will overwrite any changes the user has made to the folder names/icons
• we can set setKeepLocalChanges on a per collection level meanwhile, and we could only set it therefore on folders where a default was provided for ENTITYDISPLAY,

but the problem would remain the same for that subset of folders.

So in summary, the current synchronization only allows us to either always overwrite local changes, or to provide a default value that is then ignored if a local attribute exists.
Since name and color is written to the server, I guess we can setKeepLocalChanges (for entitydisplay) only in the places where we set default values, and in case we get something from the server, we can clear it again. That way everything should be in-sync.

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

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.

What I did:

• set color in roundcubemail (rcm) for one calendar
• sync with kontact see the color i set in rcm *yeah*
• change the color in kontact
• see the annotation updated (tested by syncing again with server and look at the color annotation, how it is transmitted from the server)
• press F5 in rcm no color is updated :(
• go to settings->folders->calendar, change nothing
• go back to the calendar view
• the folder color is updated *yeah*

@machniak: is it only a caching issue, and it would be updated in some minutes, or is the entry only read once?

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

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

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.