Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Handle 'STATUS' property of events #145

Open
6 of 7 tasks
akki42 opened this issue Feb 11, 2024 · 5 comments · May be fixed by #200
Open
6 of 7 tasks

[Enhancement] Handle 'STATUS' property of events #145

akki42 opened this issue Feb 11, 2024 · 5 comments · May be fixed by #200
Labels
feature request Issue is about a new feature in the app

Comments

@akki42
Copy link

akki42 commented Feb 11, 2024

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

@akki42 akki42 added feature request Issue is about a new feature in the app needs triage Issue is not yet ready for PR authors to take up labels Feb 11, 2024
@Aga-C Aga-C removed the needs triage Issue is not yet ready for PR authors to take up label Feb 11, 2024
@chesio
Copy link

chesio commented Feb 12, 2024

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
Copy link
Contributor

min7-i commented Feb 14, 2024

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

attendee status
event striked through

@akki42
Copy link
Author

akki42 commented Feb 15, 2024

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:
Fossify Calendar
  • Thunderbird:
    Thunderbird

  • Nextcloud:
    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
Copy link
Contributor

min7-i commented Feb 15, 2024

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

@myxor myxor linked a pull request Apr 3, 2024 that will close this issue
4 tasks
@myxor
Copy link
Contributor

myxor commented Apr 4, 2024

I implemented this feature in this PR: #200

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Issue is about a new feature in the app
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants