Good day!
I’m not sure if this is the right place for this, but I figured I’d try. It looks to me that DAVdroid is overwriting the UID on calendar events upon sync. Is this the intended behaviour? It seems to me that this would cause problems when several ICS files that all reference the same UID are imported into the calendar over time. DAVdroid seems to be changing the UID and one would be unable to connect later ICS files referencing the original UID to the calendar event in question.
It seems to me that perhaps DAVdroid should only be generating and setting a UID on the calendar event if there isn’t one already.
Please feel free to tell me I’ve got this wrong.
Thanks!
Hello,
@Zanzibar DAVdroid should not overwrite the UID, and in our tests, it does not.
It seems to me that this would cause problems when several ICS files that all reference the same UID are imported into the calendar over time.
One event must only have one UID.
Please describe your information verbosely and provide steps to reproduce (including information about the server), debug info, verbose logs etc..
Thanks for the response.
Here’s a summary of my setup, with further details below:
I’m importing ICS files received via email. I have two ICS files that I’m currently testing, one that creates the appointment (it contains a UID that doesn’t exist in the calendar), and one that updates the appointment (it contains the same UID as the previous ICS file). I import the first one successfully, but when the second one is imported, the UID of the event created when the first one was imported has changed.
It only occurs to me now that it’s possible Nextcloud is changing the UID. I poked through the source of DAVdroid and found LocalEvent.updateFileNameAndUID() - this led me to post here.
So, more details. Everybody loves details:
Nextcloud version: 11.0.1
DAVdroid version: 1.4.0.1-gplay
Android version: 7.1.1 (LineageOS 14.1 nightly)
DAVdroid debug info: http://paste.fedoraproject.org/551194/76849148/ (I’ve censored the private bits, I trust they aren’t important here).
I’ve pasted a couple of Java snippets. The first (http://paste.fedoraproject.org/551214/14865794/) is code that creates a calendar event with a UID. The second (http://paste.fedoraproject.org/551215/48657948/) should be run after DAVdroid syncs (only a few seconds in my case). Your test app will need the appropriate permission, of course:
<uses-permission android:name="android.permission.WRITE_CALENDAR"/>
Thanks again!
You’re right. The only case when LocalEvent.updateFileNameAndUID() is called is when DAVdroid looks for new local events (SyncManager.prepareDirty()), so that it can generate an UID and a file name before uploading them.
At the moment, DAVdroid doesn’t expect new local events with Events.UID_2445, so it generates an UID (Events.UID_2445) and file name (Events._SYNC_ID) and overwrites these fields. This only happens when an event is created locally.
So, to reflect the possibility that events are already created with an UID_2445, this field should be checked and only set when there’s no value yet.
Great!
As a bounty, I claim a schnitzel dinner at Figlmüller next time I’m in the neighbourhood. I kid, of course. 
Any idea when you plan to push out the next version with a fix? I suppose I could attempt to fix and build it myself…
Should be fixed with davdroid/47639c45. I have sent an APK for testing, please tell us whether it works.
