not more valid

is was fixed in the meanwhile.

We also need to investigate how it can happen that a folder is available, but containing a bunch of items with either no or the wrong payload parts (so the itemretriever ends up going to the server for every single item.

This is happening as part of a large sync:

First we need to figure out why we have so many rowsAboutToBeRemoved signals, if we indeed require that many, MessageList::Core::Model::index likely needs to be improved.

To fix this problem we need a non-blocking fetchjob that triggers the on-demand sync, but doesn't manually retrieve each individual message.
That way we can avoid blocking the session, and messages that could not be retrieved immediately will be added to the ETM via monitor signals.

• Upload a task with due date
• sync with server
• sync with other kdepim (or rm akonadi dir / akonadi start)
• see if due date is synced correctly from server

Added a test inviation:

• add a invitation with a resource
• let this invitation processed by wallace
• make sure that the resource is still a resouce and not a "normal" attendee

Can't reproduce - NEEDSINFO

Can't be reproced any more so it is fixed.

Also valid if you search for the removed caledar by name directly:

If we have two recurrence-ids at the same date one with THISANDFUTURE and the other one without. kontact one takes one into account.