answered
2019-12-18 11:39:42 +0200
Ok, I've found the regression. In a nutshell, the ICS data may be faulty and the importer in 3.2.1 became more strict.
Let's look at the ICS data :
BEGIN:VEVENT
UID:9e3e9495-7fca-46b1-9ae4-207f3a1a9148
EXDATE;VALUE=DATE:20190724
RDATE;VALUE=DATE:20190724
DTSTART;VALUE=DATE:20190724
DTEND;VALUE=DATE:20190725
END:VEVENT
It is defining an event that can recurs (it has an rdate defined), but with an exception for July 24th (meaning that there is _no_ occurrence that day). Now, the ICS data also contains information for an exception, defined with a recurrence id like RECURRENCE-ID;VALUE=DATE:20190724
. Such an exception cannot be created since there is a test like if !recursOn(recurrenceId) fails
in mKCal code. The difference is now, the result of this test is not ignored anymore. @Sebix, you may check that the exceptions are not handled properly on your Jolla1 @ 3.2.0 to validate this hypothesis.
I see two ways to correct this:
- ignore the error as before if an exception cannot be created.
- remove the faulty exdate from the list of exception dates if an occurrence is provided at this specific date, so mKCal is happy.
I need to check also the RFC for that matter, if we can have a recurrence id that is matching an exdate or not. But clearly the current code and the one from 3.2.0 does not allow it (even if before the error was silently ignored).
I've compiled a version of the Buteo CalDAV plugin available in 3.2.1 with the behaviour of ignoring dissociation errors like before as a quick fix, see buteo-sync-plugin-caldav-0.1.56-1.armv7hl.rpm.gz. This corresponds to the code available in this git branch : https://git.sailfishos.org/dcaliste/buteo-sync-plugin-caldav/tree/fix
I've just proposed a patch in SailfishOS implementing the second possibility: removing the offending exdate and adding the exception. I've compiled this particular commit on top of version 0.1.56 from 3.2.1, see buteo-sync-plugin-caldav-0.1.56-1.armv7hl.rpm.gz. This should display the exception on device, while the previous quick fix is not (and any previous version is not neither). But it may have the drawback that modifying the recurring event on device may confuse the server after up-sync, because the faulty exdate value will not be added on up-sync. This depends on the server, I've no idea.
I experience this as well. CardDAV is working well but CalDAV seems broken. :I
megalith ( 2019-12-15 01:03:13 +0200 )editSorry for this, I'll look for it next week. Try to see what changes make an exception impossible to create.
Damien Caliste ( 2019-12-15 12:16:46 +0200 )edit@damien: Thanks. I tried to work around by removing the calendar event (all occurrences) from the server, but that did not make a difference. What do you mean by "Try to see what changes make an exception impossible to create."?
Sebix ( 2019-12-15 12:22:58 +0200 )editThat's the reported error. Cannot dissociate occurrence .So that's the lead. Sorry for the inconvenience.
Damien Caliste ( 2019-12-15 12:35:28 +0200 )editI could share the ics file in question with you on a private channel. The error appears for events with different recurrences like monthly and bi-weekly.
Sebix ( 2019-12-15 12:54:16 +0200 )edit