[Bug]: [Bug]: Automatically created iMIP invitations (Mail background job) ignore "Default calendar for incoming invitations" and always go to `personal`

[riker513]

⚠️ 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 invitations that Nextcloud Mail processes automatically in the background ("Automatically create tentative appointments in calendar", Mail account setting) are always written to the calendar with URI personal, ignoring the user's "Default calendar for incoming invitations" configured in the Calendar app.

Root cause (from reading the code):

• The Calendar app stores that setting as the DAV property {urn:ietf:params:xml:ns:caldav}schedule-default-calendar-URL on the user principal, in oc_properties, via CustomPropertiesBackend.
• Mail's IMipMessageJob → IMipService::process() → OCP\Calendar\IManager::handleIMip() → CalendarImpl::handleIMipMessage(), which emits schedule on an InvitationResponseServer.
• InvitationResponseServer does not load \Sabre\DAV\PropertyStorage\Plugin / CustomPropertiesBackend, so the stored property is never read there. The only handler for schedule-default-calendar-URL in that server is OCA\DAV\CalDAV\Schedule\Plugin::propFindDefaultCalendarUrl(), which consults IConfig::getUserValue($uid, 'dav', 'defaultCalendar', 'personal') and falls back to personal, then to the first valid calendar by sort order.
• Manager::handleIMip() does call getPrimaryCalendar() (which reads oc_properties) to pick a $calendar, but CalendarImpl::handleIMipMessage() only uses it for the principal; the actual target calendar is re-resolved inside Sabre's scheduleLocalDelivery() via schedule-default-calendar-URL.

Net effect: the UI setting is honored by the main DAV server (Calendar app, CalDAV clients, manual Accept in Mail) but not by the background iMIP path. Nothing is logged; oc_mail_messages.imip_processed = 1, imip_error = 0, and the object is created in calendars/<user>/personal/.

Setting occ user:setting <user> dav defaultCalendar <uri> works around it, but nothing keeps that preference in sync with the property the UI writes.

Related, already fixed for the manual Accept flow in Mail: nextcloud/mail#10983 / nextcloud/mail#11035.

Steps to reproduce

1. User has at least two calendars, one of them with URI personal, plus another one (e.g. work).
2. In the Calendar app → Settings, set "Default calendar for incoming invitations" to work. Verify the row exists in oc_properties (propertyname = '{urn:ietf:params:xml:ns:caldav}schedule-default-calendar-URL', propertyvalue = 'calendars/<user>/work/').
3. Make sure occ user:setting <user> dav shows no defaultCalendar entry.
4. In Mail → Account settings → Calendar settings, enable "Automatically create tentative appointments in calendar".
5. From an external system (Google Calendar, Outlook, another Nextcloud), send a brand-new invitation (METHOD:REQUEST, new UID) to the mail account's address.
6. Wait for the OCA\Mail\BackgroundJob\IMipMessageJob to run (or run it via occ background-job:execute).
7. Check oc_calendarobjects joined with oc_calendars for the invite's UID.

Expected behavior

The tentative event is created in the calendar selected as "Default calendar for incoming invitations" (work).

Actual: the event is created in personal. No warning or error is logged; imip_processed = 1, imip_error = 0.

Nextcloud Server version

33

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

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