Recurring events: instances with STATUS:CANCELLED synced as EXDATE

[akki42]

Hi all,

First of all: many thanks for the continuing work in DAVx5!

Second: I have read your FAQ on the limitations with recurring events. As I am reporting on a Nextcloud - Thunderbird - [Android / DAVx5 / Calendar app] mismatch, there might be many "culprits". That being said, I still believe this might be a DAVx5 bug?! ;-)

DAVx5 App version

I'm using the latest available DAVx⁵ version: 4.4.3.2-gplay

Android version and device/firmware type

LineageOS 21-20241115-NIGHTLY-gts4lv (Android 14/AP2A.240905.003.F1) on Samsung Tab S5e

Android calendar app
multiple, e.g. Etar (LineageOS version) or Fossify Calendar

Nextcloud version

30.0.2  (Calendar app: v5.0.1)

Thunderbird version

128.4.2esr 

Steps to reproduce

• Create recurring event (either via Nextcloud calendar app, Thunderbird, or Android calendar app)
• Set STATUS property of one instance of said recurring event to CANCELLED, either via Nextcloud calendar app or Thunderbird
• Sync the calendar on your device.

Actual result

Android Calendar apps will not show the cancelled instances of the recurring event.
Fossify Calendar ICS export shows cancelled instances as EXDATE.

Expected result

Android Calendar apps should show cancelled instances, with special marking, e.g. strike-through, if supported by app (e.g. Etar or Fossify Calendar as of recently).
Calendar app export should show cancelled instances as separate VEVENTs as in Nextcloud and Thunderbird export.

Further info

• I have attached the Nextcloud, Thunderbird, and Fossify Calendar ics exports of a test calendar. (Had to add .txt extension to upload.)
• The single event with status CANCELLED included in the test calendar is synced and shown properly.

[rfc2822]

This is known behavior and a feature: https://github.com/bitfireAT/ical4android/blob/d01dba06fcc57717cfc55d0ce6423538be37da7b/lib/src/main/kotlin/at/bitfire/ical4android/AndroidEvent.kt#L521

Some clients generate an EXDATE in this case and so it was requested....

[akki42]

Thanks for the info!

Could you please provide some more background on which clients / use cases require this behaviour? (Searching for EXDATE, I did not find any issues / discussions in the ical4android repo...)

For background:
Handling the STATUS property in Android calendar apps (displaying the STATUS, e.g. by strike-through, as a first step; allowing to change STATUS as a second step) has been requested for years (e.g. Etar-Group/Etar-Calendar#201, SimpleMobileTools/Simple-Calendar#808 and FossifyOrg/Calendar#145 (comment)).
Now that Etar and Fossify Calendar have implemented this (Etar: display only so far; Fossify Calendar: display and change), I am quite disappointed to learn that - at least for recurring events - a "mismatch" will remain between those apps and the Nextcloud and Thunderbird calendars, respectively.

More than just a mismatch in (not) displaying existing CANCELLED instances on Android, this - I believe - also leads to a quite surprising behavior when changing STATUS to CANCELLED (for a single instance of a recurring event) in Fossify Calendar:
First, the amended instance is shown in Fossify Calendar with strike-through (as expected); however, after a short time [I suppose: after syncing] this CANCELLED instance suddenly "disappears" (in Fossify Calendar, and also in Nextcloud and Thunderbird - ics then includes an EXDATE).

This rather defeats the purpose / a consistent UI between calendars...

[rfc2822]

Could you please provide some more background on which clients / use cases require this behaviour? (Searching for EXDATE, I did not find any issues / discussions in the ical4android repo...)

Unfortunately I don't know it by heart anymore.

However if you "delete" (or "remove") an occurrence in a Calendar app (lets say Etar), I'd expect the event to be "deleted" and not "cancelled". So calendars should set the EXDATE in my opinion. However they set CANCELLED…

So basically I think this is

• a question of user expectations (whether EXDATE or CANCELLED should be used, but EXDATE is the more simple variant because it doesn't require a separate exception event with a RECURRENCE-ID, and everything that reduces complexity avoid potential problems),
• a question of whether calendar apps like Etar could implement EXDATE properly, in which case we wouldn't have to change CANCELLED to EXDATE.

[akki42]

Hi,
To be honest, I believe "deleting" and "cancelling" events / instances are (or rather: should be) two different use cases / behaviours; especially as the rfc specifically allows for events / instances to have the status CANCELLED.

For "deleting" an instance of a recurring event, everything appears to work smoothly. Deleting an instance in Etar or Fossify Calendar correctly generates an EXDATE.

Regarding "cancelling" an instance by Fossify Calendar (Etar does not yet support changing the STATUS), this also appears to work fine with a local calendar, see attached Local_Test.ics.txt (with instances on Nov. 19th deleted and on Nov. 21st cancelled).

However, with a synced calendar (via DAVx5 to Nextcloud),

1. "cancelling" via Nextcloud or Thunderbird correctly results in an exception event server-side (shown with strike-through in Nextcloud and Thunderbird) , but an EXDATE on the Android device (thus not shown in Android apps); see attached Nextcloud_export.ics and Fossify_export.ics;
2. "cancelling" an instance by Fossify Calendar results (after syncing) in an EXDATE both server-side and on the Android device (thus this instance is no longer shown at all in Nextcloud, Thunderbird or Android apps); see attached Nextcloud_export.ics and Fossify_export.ics; and
3. making any change (not necessarily on STATUS) to the recurring event or any instance thereof on Android (Etar or Fossify) will sync the EXDATEs ("wrongly generated" by 1. above) to the server, thus, any existing instances with status CANCELLED server-side are overwritten (and any information saved therein, e.g. a reason for cancellation, is lost); see attached
   Nextcloud_export_before.ics and Nextcloud_export_after.ics, where ("before") instance on Nov. 19th was cancelled via Nextcloud and ("after") instance on Nov. 21st was amended via Etar - and instance of Nov 19th has become EXDATE.

That does not look right to me...