Bug 285632

Version:           unspecified (using KDE 4.7.2) 
OS:                Linux

Sometimes items in Akonadi end up without a remote ID.

One way in which I manage to create this semi-regularly is: Create new event. Realize it's been saved in the wrong calendar, or at least suspect it's been saved to the wrong calendar, re-open for editing immediately (while the item is still not saved to the server) and change (or not change) the folder, save.

Typically this will then bring up the conflict dialog, in which I select the latest version, but ultimately that is then never saved to the server.

Result: An item in the local akonadi database does not have a remote id. This does not halt other items, which get synchronized normally, but you'll end up with some items that do not have remote ids.

It is likely possible to create the same situation in different ways.

While it would be good to handle the initial scenario better, the biggest issue is that Akonadi cannot recover from this scenario, as even an edit won't save the item back to the server, since it cannot be found on the server.

So Akonadi needs a recovery path for situations where there is no remote id for an object.

Reproducible: Sometimes

Steps to Reproduce:
Try the above, or just delete the remote ID in the Akonadi database.


Expected Results:  
Akonadi should have recognized that it has items without remote id, and tried to write them to the server again.