External calendar invitation replies fail when the organizer creates the event inside a writable shared calendar.
Important context:
This is not a request to enable external file sharing, public sharing, or user discovery across groups. In a multi-tenant/group-isolated setup, those options must remain restricted for security reasons. Users from one company/group must not be able to discover or share with users from another company/group.
However, calendar invitations to external attendees are a different use case. A user should be able to invite an external email address to a meeting without exposing internal users, groups, or tenants to each other.
Scenario:
- User A owns a calendar.
- User A shares this calendar with User B with write permissions.
- User B creates an event inside User A's shared calendar.
- User B invites an external attendee by email.
- The external attendee receives the invitation link.
- When the external attendee tries to accept or decline the invitation, the iTIP reply is not processed.
The failure happens because the event UID is searched only in calendars owned by the organizer principal.
In this case:
- The organizer is User B.
- The event object is physically stored in User A's calendar, because User B created it inside User A's writable shared calendar.
- The server does not find the event when processing the external attendee reply.
Observed log message:
"iTip message was not processed by the server, likely because we didn't understand it."
Expected behavior:
The external attendee reply should be processed successfully.
The server should find the event created by User B inside the writable shared calendar and update the attendee participation status.
This should work without requiring administrators to enable broad external sharing, public sharing, or user discovery across groups/tenants.
Local fix tested successfully:
CalDavBackend::getCalendarObjectByUID($principalUri, $uid, $calendarUri = null) currently searches for the event UID only in calendars owned by the organizer principal.
When the object is not found in calendars owned by the organizer, and $calendarUri is null, the backend should also search calendars available to that principal through getCalendarsForUser($principalUri), while skipping read-only shared calendars.
This allows the server to find the event object in a writable shared calendar and process the external invitation reply.
This fix preserves the security boundary:
- It does not require enabling global/external sharing.
- It does not expose users across groups or tenants.
- It only allows the calendar scheduling reply to locate an event that the organizer already has write access to.
Environment:
- Nextcloud: 32.0.8.2
- Calendar app: 6.2.4
- DAV app: 1.34.2
- Affected area: apps/dav/lib/CalDAV/CalDavBackend.php
External calendar invitation replies fail when the organizer creates the event inside a writable shared calendar.
Important context:
This is not a request to enable external file sharing, public sharing, or user discovery across groups. In a multi-tenant/group-isolated setup, those options must remain restricted for security reasons. Users from one company/group must not be able to discover or share with users from another company/group.
However, calendar invitations to external attendees are a different use case. A user should be able to invite an external email address to a meeting without exposing internal users, groups, or tenants to each other.
Scenario:
The failure happens because the event UID is searched only in calendars owned by the organizer principal.
In this case:
Observed log message:
"iTip message was not processed by the server, likely because we didn't understand it."
Expected behavior:
The external attendee reply should be processed successfully.
The server should find the event created by User B inside the writable shared calendar and update the attendee participation status.
This should work without requiring administrators to enable broad external sharing, public sharing, or user discovery across groups/tenants.
Local fix tested successfully:
CalDavBackend::getCalendarObjectByUID($principalUri, $uid, $calendarUri = null) currently searches for the event UID only in calendars owned by the organizer principal.
When the object is not found in calendars owned by the organizer, and $calendarUri is null, the backend should also search calendars available to that principal through getCalendarsForUser($principalUri), while skipping read-only shared calendars.
This allows the server to find the event object in a writable shared calendar and process the external invitation reply.
This fix preserves the security boundary:
Environment: