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

[Rilele]

I was very confused why my events kept disappearing. That was not what I was intended. I think there should be a different solution. Or maybe a setting to toggle this behavior.

[rfc2822]

Just as a reference where the code is:

• https://github.com/bitfireAT/synctools/blob/5fc6688ff6d56b80e964e1d1cc04d6cbad66c10a/lib/src/main/kotlin/at/bitfire/synctools/mapping/calendar/AndroidEventProcessor.kt#L137-L141
• asExDate below

And btw: As you can imagine, I would highly appreciate a toggle as proposed by @Rilele!

Most people won't probably know what a "Rewrite cancelled exceptions of a recurring event to EXDATE" setting actually does (and if they do, they won't remember until they set up the account the next time). So I think it then comes down to the default value of such a toggle.

[rfc2822]

Also, for a better understanding, may I ask for the use case? Are these events group-scheduled? Why do you want the cancelled exceptions to be kept?

[akki42]

And btw: As you can imagine, I would highly appreciate a toggle as proposed by @Rilele!

Most people won't probably know what a "Rewrite cancelled exceptions of a recurring event to EXDATE" setting actually does (and if they do, they won't remember until they set up the account the next time). So I think it then comes down to the default value of such a toggle.

True! Yet I believe other settings (or their use case) are not immediately self-explanatory, either (e.g. contact group method). Perhaps you could provide some hint like:
This setting is related to the event deletion or cancellation method used by the calendar app. If you are unsure, use EXDATE when using the Google or Samsung calendar app, for example, and STATUS when using the Fossify or Etar calendar app, for example.
(Those apps are just examples, obviously. I don't know about aCalendar, for example...)

[akki42]

Also, for a better understanding, may I ask for the use case? Are these events group-scheduled? Why do you want the cancelled exceptions to be kept?

@Rilele already mentioned:

So my use-case is a note for my future self, that the event was actually canceled and isn't just missing.

I second this - and find it especially important when multiple users have (write) access to a calendar...

I also use (or would like to use) these events to save (or provide to other attendees) some information regarding the cancelled instances, e.g. reason for cancellation.
(Also, sometimes some other information regarding that specific (cancelled) instance might become relevant later, e.g. the originally planned attendees or location.)

[rfc2822]

Maybe a good default would be to convert to EXDATE when there are no attendees and keep the cancelled exception when there are attendees?

[alexandersitko]

Hi,
Any updates on this issue?
The current behaviour is just very unintuitive, as almost every non-Android app shows canceled regular appointments, even the basic Calendar App on iOS does.
My use-case is to make sure I actually did not forget to include appointments in my calendar and differentiate between "real" canceled events and events that did not take place because of public holidays (I delete those).
Thanks a lot!