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.

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.