[Bug]: iMIP local delivery fails silently (3.7 Could not find principal) in background jobs when "Restrict users to only share with users in their groups" is enabled

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Calendar invitation delivery (iMIP local delivery) structurally fails in any
background-job context when the sharing setting "Restrict users to only share
with users in their groups" (shareapi_only_share_with_group_members) is
enabled — and the failure is invisible above debug log level.

No calendar object is created (verified: no row in oc_calendarobjects, no
row in oc_schedulingobjects). handleIMip() returns true; the Mail app sets
imip_processed = 1, imip_error = 0 and never retries. The only trace is a
DEBUG line: "Message not delivered locally with status: 3.7;Could not find
principal". Disabling the group-restriction setting immediately fixes
delivery; re-enabling breaks it again. Clicking "Maybe" manually in Mail
always works (browser CalDAV PUT within a user session).

Root cause, verified by code reading on v33.0.2:

1. OCA\DAV\Connector\Sabre\Principal::findByUri()
   (apps/dav/lib/Connector/Sabre/Principal.php, ~lines 434–451) gates
   principal resolution on sharing settings. When
   shareWithGroupMembersOnly() is true, it calls
   $this->userSession->getUser() and returns null if there is no session
   user. In cron/background jobs there is never a session user, so
   resolution of ANY mailto: recipient fails unconditionally.

2. Sabre's Schedule plugin therefore sets
   scheduleStatus = "3.7;Could not find principal".

3. OCA\DAV\CalDAV\Schedule\Plugin::scheduleLocalDelivery()
   (apps/dav/lib/CalDAV/Schedule/Plugin.php, ~line 261) logs this only at
   DEBUG level ("Message not delivered locally with status: ...") and
   returns normally.

4. OC\Calendar\Manager::handleIMip() (lib/private/Calendar/Manager.php)
   does not inspect scheduleStatus after
   IHandleImipMessage::handleIMipMessage() and returns TRUE to callers,
   reporting success for a delivery that failed.

Practical impact: the new "Automatically create tentative appointments"
feature of the Mail app (nextcloud/mail#12144, server PR #56924) is
completely and silently broken on instances with group-restricted sharing.
The Mail app marks affected invitations as successfully processed and never
retries them (see companion issue filed against nextcloud/mail).
Interactive flows are unaffected because a session user exists, which makes
the failure very hard to diagnose (in my case: several days).

Suggested fixes (any subset):

• Do not gate calendar scheduling principal resolution on file-sharing
  settings, or provide a session-independent resolution path for scheduling.
• In the group-restriction branch, fall back to the recipient's own
  principal context in background jobs instead of requiring a session user.
• Propagate a non-1.2 scheduleStatus to handleIMip callers (return false)
  and log at warning level instead of debug.

Steps to reproduce

1. Nextcloud 33.0.2 with Mail 5.10, working cron background jobs.
2. Enable admin setting "Restrict users to only share with users in their
   groups" (Settings → Administration → Sharing).
3. In Mail, enable "Automatically create tentative appointments" for an
   account whose address matches the user's profile email (unique on the
   instance).
4. Receive an external iMIP invitation (METHOD:REQUEST, ATTENDEE matches
   exactly) into the synced INBOX.
5. Let the Mail sync job flag it (oc_mail_messages.imip_message = 1) and
   run OCA\Mail\BackgroundJob\IMipMessageJob via cron or
   occ background-job:execute --force-execute.

Expected behavior

The event is created as tentative in the user's calendar; on failure, an
error is logged at warning/error level and reported to the caller.

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response