Mail tag synchronization error
Closed, WontfixPublic3 Story Points


Might be fixed already, but need to be tested.


Differential Revisions
D193: A changed Tag at the server may delete members.
Ticket Type

Event Timeline

mollekopf set the point value for this task to 3.Jun 27 2016, 11:38 AM
mollekopf raised the priority of this task from 40 to 60.
knauss moved this task from Backlog to Doing on the Sprint 201626 board.Jun 28 2016, 4:18 PM

Can be reproduced:
*add tag to mail in kontact

  • open in rcm

*see tag for mail
*remove tagfrom mail in rcm
*open kontact resync
*after that mail is still tagged

The problem is the TagSyncer:

It falls back to "merge" mode, because the remoteId for the tag is not anymore the same:

local tag (removeId, gid):

akonadi_kolab_resource_0(1047)/libakonadi TagSync::diffTags: "4" "7ad0a75d-6a45-4d2f-9df0-4adce4ce31f5"

remote tag (removeId, gid):

akonadi_kolab_resource_0(1047)/libakonadi TagSync::diffTags: "6" "7ad0a75d-6a45-4d2f-9df0-4adce4ce31f5"

here we have the correct ( we expect no members):

akonadi_kolab_resource_0(1047)/libakonadi TagSync::onTagItemsFetchDone: wanted members:

actual members (two):

akonadi_kolab_resource_0(1047)/libakonadi TagSync::onTagItemsFetchDone: members:
akonadi_kolab_resource_0(1047)/libakonadi TagSync::onTagItemsFetchDone: 4
akonadi_kolab_resource_0(1047)/libakonadi TagSync::onTagItemsFetchDone: 2

but there is this:

if (!merge) {
      Q_FOREACH (Item item, toRemove) {

and merge is true, if the remoteId are different.

knauss moved this task from Doing to Backlog on the Sprint 201626 board.Jun 28 2016, 5:12 PM
knauss moved this task from Backlog to Doing on the Sprint 201626 board.

IMO I think it is wrong to do the "merge" when having a new version at the server available is the wrong place.

We already have implement a TagMerger for the way, that we wanna upload a new tagversion and recocnize a updated tag object at the server (kdepim-runtime/resources/kolab/tagchangehelper.cpp). Okay the logic so far is to ignore the updates at server side, but it is the correct place to implement this.

with a dirty flag (that indica, that we have updates from kontact side) we can do this correctly.

But so far Christian and I suggest to just assume, that kontact is mostly uptodate and we can rely, that if a chagne is availalbe at the server we wantto display the change to user directly.

knauss moved this task from Doing to Review on the Sprint 201626 board.Jun 29 2016, 3:32 PM
knauss moved this task from Review to Done on the Sprint 201626 board.Jul 1 2016, 1:29 PM
mollekopf moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 14 2016, 11:07 AM
vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:12 AM
machniak closed this task as Wontfix.Jul 16 2019, 11:43 AM
machniak added a subscriber: machniak.

Kolab support for KDE PIM is discontinued. Create a ticket on