Syncing recurring events with exceptions drops exceptions

[mhoff]

I think this problem is related to https://forums.bitfire.at/topic/192/provide-workaround-for-incomplete-android-exdate-support/2.

Coarse description

Recurring events with EXDATEs are not correctly synced to my Android device.
Effect is, that all occurrences are shown, regardless the exceptional state.

Workaround I found: Marking a single occurrence as “CANCELED” results in the correct sync of other deleted occurrences.
The “CANCELED”-State can thereafter easily be removed and everything is fine. Even further deletions (of occurrences of the same event) are now synced correctly. I suppose the additional VEVENT block changes the sync behavior in some way.

Log

Step 1: 1.calendar.txt (Part of DAVDroids’ Log):

Syncing recurring event with one EXDATE.

[…]
[trace] BEGIN:VEVENT
[trace] CREATED:20151125T182649Z
[trace] LAST-MODIFIED:20151125T182840Z
[trace] DTSTAMP:20151125T182840Z
[trace] UID:ee95ba33-35b8-463b-b1fa-4a0c0dbee13e
[trace] SUMMARY:Test-Event
[trace] RRULE:FREQ=DAILY;UNTIL=20151127T190000Z
[trace] EXDATE:20151125T190000Z
[trace] DTSTART;TZID=Europe/Berlin:20151123T200000
[trace] DTEND;TZID=Europe/Berlin:20151123T210000
[trace] TRANSP:OPAQUE
[trace] X-MOZ-GENERATION:3
[trace] SEQUENCE:2
[trace] END:VEVENT
[…]

Export after sync: 1.ics

No EXDATE.

[…]
BEGIN:VEVENT
DTSTAMP:20151125T183015Z
UID:ee95ba33-35b8-463b-b1fa-4a0c0dbee13e
SUMMARY:Test-Event
ORGANIZER:mailto:test
DTSTART;TZID=Europe/Berlin:20151123T200000
DURATION:PT1H
RRULE:FREQ=DAILY;UNTIL=20151127T190000Z
END:VEVENT
[…]

Step 2: 2.calendar.txt:

Syncing an other occurrence marked as “CANCELED” (of the same recurring event!).

[…]
[trace] BEGIN:VEVENT
[trace] CREATED:20151125T182649Z
[trace] LAST-MODIFIED:20151125T183026Z
[trace] DTSTAMP:20151125T183026Z
[trace] UID:ee95ba33-35b8-463b-b1fa-4a0c0dbee13e
[trace] SUMMARY:Test-Event
[trace] RRULE:FREQ=DAILY;UNTIL=20151127T190000Z
[trace] EXDATE:20151125T190000Z
[trace] DTSTART;TZID=Europe/Berlin:20151123T200000
[trace] DTEND;TZID=Europe/Berlin:20151123T210000
[trace] TRANSP:OPAQUE
[trace] X-MOZ-GENERATION:4
[trace] SEQUENCE:2
[trace] END:VEVENT
[trace] BEGIN:VEVENT
[trace] CREATED:20151125T182903Z
[trace] LAST-MODIFIED:20151125T183026Z
[trace] DTSTAMP:20151125T183026Z
[trace] UID:ee95ba33-35b8-463b-b1fa-4a0c0dbee13e
[trace] SUMMARY:Test-Event
[trace] STATUS:CANCELLED
[trace] RECURRENCE-ID;TZID=Europe/Berlin:20151124T200000
[trace] DTSTART;TZID=Europe/Berlin:20151124T200000
[trace] DTEND;TZID=Europe/Berlin:20151124T210000
[trace] TRANSP:OPAQUE
[trace] SEQUENCE:3
[trace] X-MOZ-GENERATION:4
[trace] END:VEVENT
[…]

Export after sync: 2.ics

EXDATE is now there (-> occurrence hidden). CANCELED occurrence is also hidden.
(BTW: My CANCELED occurrence is not in this .ics file?!)

[…]
BEGIN:VEVENT
DTSTAMP:20151125T183100Z
UID:ee95ba33-35b8-463b-b1fa-4a0c0dbee13e
SUMMARY:Test-Event
ORGANIZER:mailto:test
DTSTART;TZID=Europe/Berlin:20151123T200000
DURATION:PT1H
RRULE:FREQ=DAILY;UNTIL=20151127T190000Z
EXDATE:20151125T190000Z
END:VEVENT
[…]

See 3.ics and 3.calendar.filtered.txt for turning it from CANCELED to CONFIRMED.

[rfc2822]

Android has a bug that causes EXDATE to be null when reading it from the Calendar Provider (even if an EXDATE has been set).

But I can confirm that EXDATEs are only processed when an explicit exception is present.

[rfc2822]

Has been fixed with ical4android/46d23fb4ff276f4efb317069b7c072d5c29ba4d2.

[bt6l]

@rfc2822 said:

Has been fixed with ical4android/46d23fb4ff276f4efb317069b7c072d5c29ba4d2.

I just registered to let you know, that’s great to hear!

I use f-droid, which currently distributes DAVdroid 0.9.1.2. Can you tell if the quoted fix is already integrated in there? I assume not.
Can you at all comment on the dependencies in the f-droid version?

Thanks,

[rfc2822]

Hello,

I just registered to let you know, that’s great to hear!

I use f-droid, which currently distributes DAVdroid 0.9.1.2. Can you tell if the quoted fix is already integrated in there? I assume not.

The commit has been made 19 days ago, while 0.9.1.2 has been released 22 days ago, so … no.

Can you at all comment on the dependencies in the f-droid version?

I don’t understand that. What do you mean?

[bt6l]

@rfc2822 said:

Can you at all comment on the dependencies in the f-droid version?

I don’t understand that. What do you mean?

Sure, I was not precise. So I meant, can you tell from a DAVdroid version if the packaged ical4android lib contains the addressed fix? I think, if an arbitrary person distributes DAVdroid via f-droid, it could also be shipped with an older version of ical4android, right?

BTW, do you provide an apk?

Thanks,

[rfc2822]

Sure, I was not precise. So I meant, can you tell from a DAVdroid version if the packaged ical4android lib contains the addressed fix? I think, if an arbitrary person distributes DAVdroid via f-droid, it could also be shipped with an older version of ical4android, right?

No, the used commit IDs of the submodules are stored in the DAVdroid repository. This way, correct library versions will always be used.

BTW, do you provide an apk?

Only in the commercial stores.