Announcement

Collapse
No announcement yet.

OX caldav: accept exception on recurrent events?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OX caldav: accept exception on recurrent events?

    Hi all!

    Looking at Thunderbird integration with OX via caldav, I seem to have hit a road-blocker: exception updates seems to be ignored?
    I've tried to find the RFC explaining properly what's supposed to be sent, but I didn't find anything, so I don't know who is the culprit.
    I'm using:
    • Thunderbird 78.6.0
    • open-xchange 7.10.4-rev14 (I've seen no related fix in the changelogs for rev15 & rev16)
    I've attached a few files (due to the limit of 5 files, some will be attached to the next message):
    • RecurrentEventCreation.ics.txt: The original invitation, for a recurrent event (every day, 12:30 to 13:30 from January 18th to 22nd)
    • RecurrentEventUpdate.ics.txt: An update (exception to the recurrent event), changing the event
    • RecurrentEventCreation.pcap-extract.txt: Extract of the HTTP stream of Thunderbird creating the recurrent event (PUT, REPORT (sync-collection), REPORT (calendar-multiget))
    • RecurrentEventFailedUpdate.pcap-extract.txt: Extract of the HTTP stream of Thunderbird trying to update the event (PUT only)
    • RecurrentEventPullAfterFailedUpdate.pcap-extract.txt: Extract of the HTTP stream of Thunderbird pulling the resulting event (REPORT (calendar-multiget))
    • RecurrentEventPullAfterUpdateViaOX.extract.txt: Extract of the HTTP stream of Thunderbird pulling the event after update accepted via OX (part of a REPORT (calendar-multiget))
    • Thunderbird_PUT_VS_Event_after_update_via_OX.diff. txt: Diff between the event that Thunderbird tried to PUT (reordered and without the VTIMEZONE) and the event exported from OX after an update via the web interface (without the VTIMEZONE)
    Some remarks on what I'm seeing:
    • After the PUT on the update, the event obtained back has 2 VEVENT, as expected, but the exception is not flagged as an exception (X-MICROSOFT-CDO-INSTTYPE is 1 instead of 3) and the DTSTART/DTEND of the event are set to the original time, not the modified one.
    • When using the OX web application directly, it's possible to accept the update (event after Thunderbird's PUT botched it)
    • The object pulled after the update via OX looks quite similar to the object pushed by Thunderbird (with some re-ordering of the fields): same RECURRENCE-ID/DTEND/DTSTART/X-MICROSOFT-CDO-APPT-SEQUENCE/X-MICROSOFT-CDO-INSTTYPE
    Could it be possible that an update via CalDAV is somehow restricted to some fields and something forbids/resets the changes on DTEND/DTSTART/X-MICROSOFT-CDO-INSTTYPE?

    Thanks in advance,
    Vincent
    Attached Files

  • #2
    Sorry for the double post. Here are some attachments that I couldn't add to the first post (limit of 5...)
    Attached Files

    Comment

    Working...
    X