Yes, this has been implemented about a year ago.
supdevs1 shifang last edited by
I had a experience of my calendar conflict between my Android mobile and Nextcloud Calendar App. DAVx5 returns me HTTP code 500, after i manually disable some calendars (i have few calendars in my account), sync, re-enable some of them step by step. It can sync again, i believe DAVx5 handled my conflict.
Then i read the document from – https://www.davx5.com/manual/technical_information.html#conflict-handling , i realize that server data wins and replaced the Android data.
Could i suggest to sync the data as still Server data wins, but do not delete Mobile Android data, just move that bad data to a new event, eg. title as “Conflict data: XX_original_title_XX”?
TheOtherDoctor last edited by
@supdevs1-shifang Just to strongly support that proposal: CalDAV data being deleted on the mobile device is from my viewpoint to be strictly avoided. Having users lose calendar entries gives me hard times, where I have to defend the use of a self-hosted service instead of “just give up and hand it to google”. This is no fun.
I suspect these conflicts happen typically when coming together with any sync issues which delay upload of changed items - be it due to android settings or connection just being offline for a moment. I am also unsure to what extend a client app or the backend server contributes to this.
The more clients are accessing the same calendar, the higher the probability of conclicts. To me, DAVx5’s current way of handling this is a scalability limiter, and I am wondering how you can get this working in managed solutions.
On the server side I have hooked a versioning system to track every change to the databases easily, but as far as I understand, I have no chance to prevent the data loss on the DAVx5 client side by similar means currently.
If something like the proposed copy to a new conflict item is not realistic to have soon, I’d suggest to add a quick remedy first, by
a) saving discarded content in some local file on the device storage to allow for manual recovery.
b) unconditionally logging the event, and display it for example in the debug data page.
If any such thing is already present and I just did not find out how to use, please give a hint here (and update the manual).