Process exceptions of recurring events

AutoImport-michaelweghorn

I am using DAVdroid 0.5.7-alpha on Cyanogenmod 10.2.1.

When I change only one occurence of a repeating event in Thunderbird, the changes are not synchronized correctly to my smartphone’s calendar.

Steps I take:

create a repeating event in the CalDAV calendar using Icedove 17.0.10/Iceowl 1.9b1 (the Debian versions of Thunderbird/Lightning) with two occurences and give the event the title “TestEvent”
synchronize calendar using DAVdroid
change the title of the second occurence to “NewTitle” in Icedove/Iceowl
synchronize calendar using DAVdroid
result: the change is not synchronized and the title which is displayed on my Android calendar remains “TestEvent” for both occurences of the event

(In another instance of Icedove/Iceowl, the title of the second occurence is synchronized correctly and changes to “NewTitle”).

logcat output of first DAVdroid synchronization (after creating the repeating event):

I/davdroid.SyncManager(12369): Fetching 1 new remote resource(s)
D/davdroid.WebDavResource(12369): Received HTTP/1.1 200 OK
D/davdroid.WebDavResource(12369): BEGIN:VCALENDAR
D/davdroid.WebDavResource(12369): PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
D/davdroid.WebDavResource(12369): VERSION:2.0
D/davdroid.WebDavResource(12369): BEGIN:VTIMEZONE
D/davdroid.WebDavResource(12369): TZID:Europe/Berlin
D/davdroid.WebDavResource(12369): X-LIC-LOCATION:Europe/Berlin
D/davdroid.WebDavResource(12369): BEGIN:DAYLIGHT
D/davdroid.WebDavResource(12369): TZOFFSETFROM:+0100
D/davdroid.WebDavResource(12369): TZOFFSETTO:+0200
D/davdroid.WebDavResource(12369): TZNAME:CEST
D/davdroid.WebDavResource(12369): DTSTART:19700329T020000
D/davdroid.WebDavResource(12369): RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
D/davdroid.WebDavResource(12369): END:DAYLIGHT
D/davdroid.WebDavResource(12369): BEGIN:STANDARD
D/davdroid.WebDavResource(12369): TZOFFSETFROM:+0200
D/davdroid.WebDavResource(12369): TZOFFSETTO:+0100
D/davdroid.WebDavResource(12369): TZNAME:CET
D/davdroid.WebDavResource(12369): DTSTART:19701025T030000
D/davdroid.WebDavResource(12369): RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
D/davdroid.WebDavResource(12369): END:STANDARD
D/davdroid.WebDavResource(12369): END:VTIMEZONE
D/davdroid.WebDavResource(12369): BEGIN:VEVENT
D/davdroid.WebDavResource(12369): CREATED:20140207T211000Z
D/davdroid.WebDavResource(12369): LAST-MODIFIED:20140207T211027Z
D/davdroid.WebDavResource(12369): DTSTAMP:20140207T211027Z
D/davdroid.WebDavResource(12369): UID:f8973465-a13b-4ea8-be97-a7a52c0d4c09
D/davdroid.WebDavResource(12369): SUMMARY:TestEvent
D/davdroid.WebDavResource(12369): RRULE:FREQ=DAILY;COUNT=2
D/davdroid.WebDavResource(12369): DTSTART;TZID=Europe/Berlin:20140218T100000
D/davdroid.WebDavResource(12369): DTEND;TZID=Europe/Berlin:20140218T110000
D/davdroid.WebDavResource(12369): END:VEVENT
D/davdroid.WebDavResource(12369): END:VCALENDAR
D/davdroid.Event(12369): Assuming time zone Europe/Berlin for Europe/Berlin
D/davdroid.Event(12369): Assuming time zone Europe/Berlin for Europe/Berlin
D/davdroid.SyncManager(12369): Adding f8973465-a13b-4ea8-be97-a7a52c0d4c09.ics
D/davdroid.LocalCollection(12369): Committing 1 operations
I/davdroid.SyncManager(12369): Fetching 0 updated remote resource(s)
I/davdroid.SyncManager(12369): Removing non-dirty resources that are not present remotely anymore
D/davdroid.LocalCollection(12369): Committing 1 operations
I/davdroid.SyncManager(12369): Sync complete, fetching new CTag
D/davdroid.LocalCollection(12369): Committing 1 operations

logcat output of second synchronization (after changing title of the second occurence to “NewTitle”):

I/davdroid.SyncManager(12369): Fetching 0 new remote resource(s)
I/davdroid.SyncManager(12369): Fetching 1 updated remote resource(s)
D/davdroid.WebDavResource(12369): Received HTTP/1.1 200 OK
D/davdroid.WebDavResource(12369): BEGIN:VCALENDAR
D/davdroid.WebDavResource(12369): PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
D/davdroid.WebDavResource(12369): VERSION:2.0
D/davdroid.WebDavResource(12369): BEGIN:VTIMEZONE
D/davdroid.WebDavResource(12369): TZID:Europe/Berlin
D/davdroid.WebDavResource(12369): X-LIC-LOCATION:Europe/Berlin
D/davdroid.WebDavResource(12369): BEGIN:DAYLIGHT
D/davdroid.WebDavResource(12369): TZOFFSETFROM:+0100
D/davdroid.WebDavResource(12369): TZOFFSETTO:+0200
D/davdroid.WebDavResource(12369): TZNAME:CEST
D/davdroid.WebDavResource(12369): DTSTART:19700329T020000
D/davdroid.WebDavResource(12369): RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
D/davdroid.WebDavResource(12369): END:DAYLIGHT
D/davdroid.WebDavResource(12369): BEGIN:STANDARD
D/davdroid.WebDavResource(12369): TZOFFSETFROM:+0200
D/davdroid.WebDavResource(12369): TZOFFSETTO:+0100
D/davdroid.WebDavResource(12369): TZNAME:CET
D/davdroid.WebDavResource(12369): DTSTART:19701025T030000
D/davdroid.WebDavResource(12369): RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
D/davdroid.WebDavResource(12369): END:STANDARD
D/davdroid.WebDavResource(12369): END:VTIMEZONE
D/davdroid.WebDavResource(12369): BEGIN:VEVENT
D/davdroid.WebDavResource(12369): CREATED:20140207T211000Z
D/davdroid.WebDavResource(12369): LAST-MODIFIED:20140207T211159Z
D/davdroid.WebDavResource(12369): DTSTAMP:20140207T211159Z
D/davdroid.WebDavResource(12369): UID:f8973465-a13b-4ea8-be97-a7a52c0d4c09
D/davdroid.WebDavResource(12369): SUMMARY:TestEvent
D/davdroid.WebDavResource(12369): RRULE:FREQ=DAILY;COUNT=2
D/davdroid.WebDavResource(12369): DTSTART;TZID=Europe/Berlin:20140218T100000
D/davdroid.WebDavResource(12369): DTEND;TZID=Europe/Berlin:20140218T110000
D/davdroid.WebDavResource(12369): X-MOZ-GENERATION:1
D/davdroid.WebDavResource(12369): END:VEVENT
D/davdroid.WebDavResource(12369): BEGIN:VEVENT
D/davdroid.WebDavResource(12369): CREATED:20140207T211150Z
D/davdroid.WebDavResource(12369): LAST-MODIFIED:20140207T211159Z
D/davdroid.WebDavResource(12369): DTSTAMP:20140207T211159Z
D/davdroid.WebDavResource(12369): UID:f8973465-a13b-4ea8-be97-a7a52c0d4c09
D/davdroid.WebDavResource(12369): SUMMARY:NewTitle
D/davdroid.WebDavResource(12369): RECURRENCE-ID;TZID=Europe/Berlin:20140219T100000
D/davdroid.WebDavResource(12369): DTSTART;TZID=Europe/Berlin:2…
D/davdroid.Event(12369): Assuming time zone Europe/Berlin for Europe/Berlin
D/davdroid.Event(12369): Assuming time zone Europe/Berlin for Europe/Berlin
I/davdroid.SyncManager(12369): Updating f8973465-a13b-4ea8-be97-a7a52c0d4c09.ics
D/davdroid.LocalCollection(12369): Committing 3 operations
I/davdroid.SyncManager(12369): Removing non-dirty resources that are not present remotely anymore
D/davdroid.LocalCollection(12369): Committing 1 operations
I/davdroid.SyncManager(12369): Sync complete, fetching new CTag
D/davdroid.LocalCollection(12369): Committing 1 operations

The calendar is hosted on fruux.com.

AutoImport-SecurityAddicted

Same issue for me, but I use Owncloud & Thunderbird.

AutoImport-cmrcx

Same for me with mail.de and iCal.

rfc2822

When changing the second occurence, Thunderbut puts two VEVENTS into the .ics:

### "main event"
BEGIN:VEVENT
CREATED:20140226T185934Z
LAST-MODIFIED:20140226T190059Z
DTSTAMP:20140226T190059Z
UID:f99c1435-0f36-418e-a001-b72d402490d1
SUMMARY:test
RRULE:FREQ=WEEKLY;COUNT=2;BYDAY=MO
DTSTART;TZID=Europe/Vienna:20140303T200000
DTEND;TZID=Europe/Vienna:20140303T230000
X-RADICALE-NAME:f99c1435-0f36-418e-a001-b72d402490d1.ics
X-MOZ-GENERATION:1
END:VEVENT
### second occurence
BEGIN:VEVENT
CREATED:20140226T190012Z
LAST-MODIFIED:20140226T190059Z
DTSTAMP:20140226T190059Z
UID:f99c1435-0f36-418e-a001-b72d402490d1
SUMMARY:test_edit
RECURRENCE-ID;TZID=Europe/Vienna:20140310T200000
DTSTART;TZID=Europe/Vienna:20140310T200000
DTEND;TZID=Europe/Vienna:20140310T230000
X-RADICALE-NAME:f99c1435-0f36-418e-a001-b72d402490d1.ics
X-MOZ-GENERATION:1
END:VEVENT

DAVdroid parses only the first event at the moment, so the title of the second occurence is ignored.

I’ll have a look whether/how to deal with this.

rfc2822

I think the correct way would be to process and insert the exceptions like normal events, but with the ORIGINAL_* fields set.

Tagging as enhancement issue.

AutoImport-marksand

Hi I think this is more than an enhancements: without this fix the phone just shows wrong data which is very confusing and misleading. Would greatly appreciate a fix for the otherwise great app. Thanks!

rfc2822

(Good-quality) pull requests are welcome

AutoImport-zozodx

Hello
It’s more like a bug for my usage
If someone want to spent time on it I’m ready to make a donation for this enhancement

zozo

AutoImport-kloppy

This bug is currently preventing me from using DAVdroid at all. I migrated from google to baikal and everything works with evolution or lightning. I have a lot of recurring events that are modified and thus my calendar shows just wrong events on the phone. I would also be willing to give an extra donation for a fix.

AutoImport-jelle-e

Right. Same problem with my Kolab server and DAVDroid 0.6.1 and Android 4.4.4 on Nexus5. Recurring events removed on my Android calendar are not federated to the server. Instead, I get the recurring event back in my Android calendar after sync.

On the main page of DAVDroid I read: “server <-> client sync, server always wins”. Does that have anything to do with this problem?

rfc2822

Right. Same problem with my Kolab server and DAVDroid 0.6.1 and Android 4.4.4 on Nexus5. Recurring events removed on my Android calendar are not federated to the server. Instead, I get the recurring event back in my Android calendar after sync.

Yes. Exceptions for recurring events are simply not implemented at the moment.

On the main page of DAVDroid I read: “server <-> client sync, server always wins”. Does that have anything to do with this problem?

No.

AutoImport-wrosenauer

Unfortunate missing feature. I’ve first investigated caldav sync adapter which has exactly the same issue. But my work calendar is full of exceptions and so also davdroid is pretty much useless to me
I’d propose this is something for the FAQ.

AutoImport-StarPicard

Hey, there - same problem with my
Evolution <-> Owncloud <-> Davroid <-> Android

But the second, in my opinion relating, problem seems to be, that whenever I delete one instance of the recurring event, davdriod seems to create a second instance of this event with the exception.

What is the actual state of this bug, because its a big problem for me.
In the actual version I simply can’t use this really great app.

rfc2822

Hey, there - same problem with my
Evolution <-> Owncloud <-> Davroid <-> Android

Yes. Exceptions for recurring events are simply not implemented at the moment (when receiving them in an iCalendar).

But the second, in my opinion relating, problem seems to be, that whenever I delete one instance of the recurring event, davdriod seems to create a second instance of this event with the exception.

No. This second event with the exception is created by the Android Calendar Provider (see how DAVdroid interacts with the Calendar Provider).

What is the actual state of this bug, because its a big problem for me.
In the actual version I simply can’t use this really great app.

The status is that handling of exceptions is not implemented yet, neither when receiving iCalendars nor when collecting events from the Calendar Provider.

I guess that this work would be necessary:

CalDAV server → Calendar Provider: If an iCalendar contains a VEVENT with a recurring event and other VEVENTS with exceptions, these exception events should be added to the Calendars Provider as an exception (related to the recurring event).
Calendar Provider → CalDAV server: Exceptions for recurring events in the Calendar Provider should not be treated as normal events but associated to the recurring event; one iCalendar with recurring event + exceptions should be created instead of two separate iCalendars.

rfc2822

Results of today’s reading:

The recurring “master” event and all its exceptions share the same UID. The exceptions have a RECURRING-ID that shows which of the event instances is overriden by the exception.
All VEVENTs with the same UID (i.e. the master event + its exceptions) have to be in the same .ics file on CalDAV servers.

AutoImport-k21735

Hello,
I am also willing to make a donation for this enhancement (and for full support of the iCalendar RFC). As far as I am concerned this bug unfortunately makes DAVdroid completely unusable!

rfc2822

Can you try with 0.7.3 (will be in the stores soon, or download here: https://github.com/bitfireAT/davdroid/releases/download/v0.7.3/davdroid_0_7_3.apk)?
Please also read https://davdroid.bitfire.at/faq/entry/recurring-events

rfc2822

I am also willing to make a donation for this enhancement (and for full support of the iCalendar RFC).

BTW: While testing, I haven’t seen any working implementation with full support of the iCalendar RFC, even iCloud fails and crashes if you play around too much in the Web GUI (just try adding a recurring event, then moving around single instances, deleting them, switching between all-day and date-time, etc.).

rfc2822

Basic support has been implemented with 0.7.3. For mre specific issues, please create a new ticket with verbose information.

AutoImport-phmarek

well, what would you need?
I installed git HEAD yesterday (reading the release notes), and even removed the account and re-created it…
but exceptions are still not handled correctly.

(eg. a recurring event that has a few dates removed is still shown all the time.)

Process exceptions of recurring events

Similar topics

CalDAV: Sync colors after setup
DAVx⁵ • enhancement • • AutoImport-stefan-niedermann

Userspace driver for GIMP
GfxTablet • enhancement • • AutoImport-techtonik

If Im.PROTOCOL_CUSTOM is set but Im.CUSTOM_PROTOCOL is empty syncing fails
DAVx⁵ • bug solved • • spoorcc

Process exceptions of recurring events

Similar topics

CalDAV: Sync colors after setup DAVx⁵ • enhancement • • AutoImport-stefan-niedermann

Userspace driver for GIMP GfxTablet • enhancement • • AutoImport-techtonik

If Im.PROTOCOL_CUSTOM is set but Im.CUSTOM_PROTOCOL is empty syncing fails DAVx⁵ • bug solved • • spoorcc

CalDAV: Sync colors after setup
DAVx⁵ • enhancement • • AutoImport-stefan-niedermann

Userspace driver for GIMP
GfxTablet • enhancement • • AutoImport-techtonik

If Im.PROTOCOL_CUSTOM is set but Im.CUSTOM_PROTOCOL is empty syncing fails
DAVx⁵ • bug solved • • spoorcc