[Enhancement] Handle 'STATUS' property of events

[akki42]

Checklist

• I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one feature request.
• I have read and understood the contribution guidelines.
• I optionally donated to support the Fossify mission.

Feature description

Please handle the STATUS property of events; see RFC5545.
(Allowed values are 'CONFIRMED', 'TENTATIVE' and 'CANCELLED'.)

First, 'CANCELLED' events should be shown differently, e.g. with strike-through font (similar to Thunderbird, Nextcloud calendar or etar (Etar-Group/Etar-Calendar#278)).

Second, it would be great if the status could also be (un-)set from FossifyOrg Calendar.
(Please see similar requests for etar (Etar-Group/Etar-Calendar#800) and SMT (SimpleMobileTools/Simple-Calendar#808 and SimpleMobileTools/Simple-Calendar#1108).

Why do you want this feature?

Consistent usage across platforms / apps.

Additional information

No response

[chesio]

Copying my comment from SMT issue here:

It would be great to have this feature eventually added to Fossify Calendar, but what I consider a necessity is to preserve this status when it is set by other apps that support it.

An example of what I mean:

1. I create an event with status "Tentative" in Thunderbird.
2. The event gets synced to my Nextcloud server - there I can see the status as tentative using Calendar app.
3. The event gets synced to my phone - in Fossify Calendar I cannot see the status, but I can edit the event.
4. I edit the event time on my phone and save it.
5. The event gets synced to Nextcloud (and Thunderbird) - the tentative status is gone, instead both apps show the status as confirmed.

[min7-i]

If I understood your request correctly, most of those features should already be supported. I did a few tests with a calendar synced via DAVx5. As those were just some tests I cannot say how reliably this works in daily use.

Features that worked in my tests
If an event has at least one attendee in addition to yourself the app shows a small circle on the bottom-right side of the profile bubble for each attendee:

• green with a checkmark (confirmed)
• yellow with a questionmark (tentative)
• red with an x (cancelled)

It seems to take at least one synchronization with your calendar before the status icons appear. Additionally, if one attendee has not replied to the invitation yet, the app will show no status (circle) for that attendee.

You can change your own status by tapping on "my status" in the list of attendees. When you set it to cancelled the event's title is striked through in most views (I didn't check all of them). The changed status was also correctly updated on the server.

screenshots showing status icons and striked through event

[akki42]

Thank you, @min7-i , for looking into this and pointing out the attendance feature.

I believe this is similar to (but not identical with) the requested feature and can be used as a work-around in many use cases.
(BTW: I believe it is sufficient to add yourself to the event as an attendee and save and close the event; opening it again, the "my status" (not sure about the translation) field appears - so no need for a different / dummy attendee...)

Personally, I wouldn't be completely satisfied with this just yet, especially because of the different handling on other platforms / in other apps:
This attendance status makes use of the PARTSTAT parameter of the ATTENDEE property (see RFC 5545 #3.8.4.1), whereas the request was to use the STATUS property (see RFC 5545 #3.8.1.11).
This leads to events "cancelled" via Thunderbird / Nextcloud (and shown with strike-through there) not being marked (shown without strike-through) in Fossify Calendar - and vice versa, see screenshots:

• Fossify Calendar:

• Thunderbird:
  

• Nextcloud:
  

Furthermore, when cancelling an event via Thunderbird / Nextcloud, i.e. via the STATUS property, an event update will be sent out to all participants (and shown in their calendars accordingly, if supported). Setting the PARTSTAT parameter of the ATTENDEE property will only be reflected in the user's own calendar, however.

And finally, as @chesio, has pointed out, Fossify Calendar (re-)sets the STATUS property to STATUS:CONFIRMED whenever an event is edited (totally unrelated to STATUS or ATTENDEE), thus overriding anything set via Thunderbird / Nextcloud etc.

For those reason, I would very much appreciate Fossify Calendar (also) supporting the STATUS property.
Again: thank you!

[min7-i]

Thanks a lot for taking the time to elaborate on this, @akki42. I see the differences now.

[myxor]

I implemented this feature in this PR: #200

[akki42]

Thank you for the update - much appreciated.

Unfortunately, there is quite a surprising (to me) behaviour when syncing with Nextcloud via DAVx5 regarding CANCELLED instances of recurring events:
As just pointed out in bitfireAT/davx5-ose#1132 (comment), ical4android / DAVx5 "converts" cancelled instances to EXDATE instead of generating a RECURRENCE-ID exception.
Thus, such CANCELLED instances are not (and cannot be) shown in Fossify Calendar with strike-through, as expected. Furthermore, if you change the STATUS of such an instance to CANCELLED in Fossify Calendar, this instance will "disappear" (both in Fossify Calendar and server side).

[chesio]

Hi @akki42,

I would suggest to open new issue for this problem (and eventually reference this one from the new issue). The more details you can provide, the better.

[akki42]

Hi @chesio,
So far, I don't believe this to be a bug / issue of Fossify Calendar, but rather of the synchronization by DAVx5 / ical4android.
That's why I opened the discussion at the DAVx5 repo.
But I would urge all interest parties to join that discussion, e.g. by providing use cases for STATUS:CANCELLED vs. "deletion" of an event / instance.