@rfc2822 Thanks for the fast response!
No, there are no real problems with it. I think SSO is a bit easier to configure, though, since you don’t need to enter your credentials another time if you already configured the Nextcloud app.
An idea to improve things could be to maybe make Nextcloud’s Login Flow a bit easier to discover from the DAVx5 app by adding an additional option below extended login when adding a new account directly?
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).
Hi dear people at DAVx5,
I’m also interested in a conflict handling as proposed above, i.e. creating a backup copy of conflicting CalDav and CardDav entries. Otherwise I will loose data for sure.
The [Roadmap](link url) already mentions a solution for CardDav.
Is there already a date in mind?
Will a similar method also be implemented for CalDav?