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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 4 2016
Jul 1 2016
Jun 30 2016
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
Jun 29 2016
IMO I think it is wrong to do the "merge" when having a new version at the server available is the wrong place.
Jun 28 2016
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
This is a wontfix
Jun 27 2016
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
Jun 22 2016
It shouldn't be possible that mLastChecks contains something too recent since it's initialized from currentDateTime()....
That was after changing the interval and restarting akonadi
Resuming timer timer: Starting timer: QDateTime("Wed Jun 22 16:10:51 2016") 300000 IntervalCheck, collectionExpired: 24 Resuming timer timer: