Event disappears when editing one occurrence in a repeating event

RESOLVED INVALID

Status

RESOLVED INVALID
4 years ago
4 years ago

People

(Reporter: beckermarkus181, Unassigned)

Tracking

Lightning 3.3
x86_64
Windows 7

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8568490 [details]
error_console.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.3.18 (KHTML, like Gecko) Version/7.1.3 Safari/537.85.12

Steps to reproduce:

Thunderbird 31.4.0 release channel on Windows 7
Lightning 3.3.3

1. Create a repeating event in a shared CalDAV calendar
2. 'edit just this occurrence': Edit one occurrence of this repeating event. E.g., edit the start time
3. 'save and close'

If you need any more information, let me know.


Actual results:

This one occurrence of a repeating event disappears. The other occurrences are still visible. 


Expected results:

Event should have changed parameters and still be visible.
(Reporter)

Updated

4 years ago
OS: All → Windows 7
Hardware: All → x86_64

Comment 1

4 years ago
Can you please enable calendar.debug.lo, calendar.debug.log.verbose and javascript.options.showInConsole in the config editor, reproduce the issue and attach everything you have in the error log to this bug? You seemto have the cache enabled for this calendar. Does this also appear if you disable it?
Component: Calendar Views → Provider: CalDAV
Flags: needinfo?(beckermarkus181)
(Reporter)

Comment 2

4 years ago
Created attachment 8569102 [details]
Log whith caldav debug output enabled

Debug log is attached with the output of exercising all the steps as described above.

No error is thrown according to the log.
Flags: needinfo?(beckermarkus181)

Updated

4 years ago
Attachment #8569102 - Attachment mime type: text/x-log → text/plain

Comment 3

4 years ago
This looks mainly like a server issue. You can see in the log that with the modification request there is sent the orginal vevent and the exceptional vevent, while the server replies only with the (modified) original event, so no exception is retrieved back from the server.

What I'm not sure about is whether we should have included the EXDATE within the original event when sending the request to the server. But nevertheless, the server recognized an exception and swallowed it when serving the updated event.

Philipp, do you know whether not inserting the EXDATE from our end is correct?
Flags: needinfo?(philipp)
No, editing an occurrence of an event should not create an EXDATE, but instead send an extra VEVENT in the VCALENDAR that contains a RECURRENCE-ID. EXDATE is only used when deleting an occurrence from a recurring series.
Flags: needinfo?(philipp)

Comment 5

4 years ago
Based on the log, this is exactly what's happened. So this is no error in Lightning, but the exception is not correctly interpreted by the server.

You should probably file a bug with Open Xchange.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.