A attachment is marked as:

• is must be a TextMessagePart
• and if mIconType != NoIcon
• and via mNode you get the contentType

We could be chasing the wrong problem:
If the mail that this was tested with was internally already marked as read, then addFlags may have set flagsChanged to false, which would keep the changes empty, which would keep us out of the branch that sends the FETCH response, which makes the whole argument moot.

This is what we get in the debugger in the error state when trying to mark a mail as read:

kontact-1644948879 (0x7f0cb8012b60) 7421 UID STORE 86696 NOREV (+FLAGS (\SEEN)) 
kontact-1644948879 (0x7f0cb8012b60) 7421 OK DATETIME "23-Jun-2016 11:36:58 +0000" STORE completed

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

perhaps linking to https://docs.kolab.org/developer-guide/packaging/obs-for-kolab/howto-get-started.html

can reproduce:
*create new event

• open find resource dialog
• hit enter / or press the button without selecting anything

Can reproduce:
*create timeserices that removes complete working time for 10days (6-20 o'clock) (7 is enough) (as jane)

• try to create a event with jane as attentee (as john)
• the automatic schedualr suggest correct only time outside the working time

*selecteting only search in working houers do not change anything

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

@machniak nope - here we are talking about kube and the display of mails

Is this related to T1139 ?

The example comes from the "OpenPGP encrypted one signed and one unsigned attachment"

Sandro, please add your thoughts and comments on the issue.

The information provided here suggests that the communication to the akonadi server remains functional (we can see the ASAP communication for the mark as read operation),
but for some reason the UI doesn't update.

Actually this seems to be a misinterpretation of the RFC https://tools.ietf.org/html/rfc5545#section-3.8.5.3

Issue confirmed, applies to invitation and local event.

Can't reproduce in most recent version.

Both should be fixed by now.

We sometimes missed sync intervals, and failed to synchronize collections that are only referenced, but not enabled.

It seems impossible to

https://phabricator.kde.org/T1825