Page MenuHomePhorge

Colours not synchronised between web & desktop client
Closed, ResolvedPublic13 Story Points

Assigned To
Authored By
May 12 2015, 1:11 PM
Referenced Files
F5: profile-photo.jpg
Nov 3 2015, 6:00 PM


Enable Kontact to read the colour scheme in the same IMAP folder annotation as Roundcube.

  • Set calendar colors in webclient
  • Synchronize folder list
  • Observer calendar color in kontact (should be the same)


Ticket Type

Event Timeline

mollekopf raised the priority of this task from to 60.
mollekopf updated the task description. (Show Details)
mollekopf added a project: KDE PIM.
mollekopf changed Ticket Type from Task to Task.
mollekopf subscribed.

can be reprocused:

Futher informations:
use the '/vendor/kolab/color' RFC 5464 folder annotation

knauss edited a custom field.
knauss moved this task from Backlog to Doing on the Sprint Desktop 201520 board.

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.

mollekopf lowered the priority of this task from 60 to 40.Jun 17 2015, 1:53 PM
mollekopf added a project: Restricted Project.Jul 6 2015, 1:08 PM
petersen raised the priority of this task from 40 to High.Oct 28 2015, 1:45 PM
petersen subscribed.

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.

petersen added a project: Restricted Project.
knauss moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Nov 2 2015, 2:04 PM

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.

knauss moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Nov 4 2015, 2:58 PM

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.

knauss moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.