The related issue about the not working invitations is this: nextcloud/server#26668

I am not really into the calendar app's source code, but AFAIK most of the app is a CalDAV client running in the web-browser. This means that it might need some support from the Nextcloud DAV backend in order to identify the shared calendars (ok, you can also look at the ...shared_by... string in their URI).

In the draft pull-request nextcloud/server#36756 there is also a commit which implements the SharingSupport interface in the backend. One effect is that there are new fields {DAV:}share-resource-uri and {DAV:}share-access which might be helpful when trying to identify shard calendars (other than by looking at their URI and searching for "shared_by").

One effect is that there are new fields {DAV:}share-resource-uri and {DAV:}share-access which might be helpful when trying to identify shard calendars (other than by looking at their URI and searching for "shared_by").

That's not what we do. There's a shares property for DAV collections using the property exposed by the current sharing backend.

Using Sabre's new fields from nextcloud/server#36756 would be used exactly the same (apart for eventual future invitee status).

Using Sabre's new fields from nextcloud/server#36756 would be used exactly the same (apart for eventual future invitee status).

So then this bug could easily be fixed as the calendar app already knows which calendars are shared and which not?

Absolutely.

It happened again that someone was misled by Invitation sent when in fact nothing was done by the backend.

I suggest we try to reflect the RSVP/invitation status as accurate as possible according to https://icalendar.org/CalDAV-Scheduling-RFC-6638/3-2-9-schedule-status-values.html. E.g. show when an invitation should have been sent (from the user's perspective) but wasn't. Even catch this and show a little warning toast when the user saves their changes.