1. Home
  2. DAVx⁵
  3. Process exceptions of recurring events

Process exceptions of recurring events

  • A

    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.

    0
  • A

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

    0
  • A

    Same for me with mail.de and iCal.

    0
  • rfc2822
    developer

    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.

    0
  • rfc2822
    developer

    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.

    0
  • A

    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!

    0
  • rfc2822
    developer

    (Good-quality) pull requests are welcome ☺

    0
  • A

    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

    0
  • A

    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.

    0
  • A

    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?

    0
  • rfc2822
    developer

    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.

    0
  • A

    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.

    0
  • A

    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.

    0
  • rfc2822
    developer

    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.
    0
  • rfc2822
    developer

    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.
    0
  • A

    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!

    0
  • rfc2822
    developer

    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

    0
  • rfc2822
    developer

    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.).

    0
  • rfc2822
    developer

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

    0
  • A

    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.)

    0
enhancement 204 bug 136
Log in to reply
 

Similar topics