Repository navigation
Connect Nextcloud once: files, calendars and contacts from one connection #158
Description
Decided: a Nextcloud connection is made once, with one app password, and gives a person their files, their calendars and their contacts. This is a must-have for v0.4.0, and the only way Nextcloud calendars and contacts will come into plMail.
Today
- Files: the Nextcloud integration (
NextcloudDriver, Settings → Integrations) talks WebDAV to/remote.php/dav/files/{user}: browse, attach, save attachments, share links. An administrator can pin the server address for everybody in Admin → Integrations (IntegrationProviderConfig::$baseUrl), which also exempts that host from the private-network block. - Calendars: only through the generic CalDAV connection in Settings → Calendars. The person types the server address and the same app password again, and nothing ties it to their Nextcloud connection.
- Contacts: nothing yet; CardDAV: mirror address books, suggest contacts while composing, edit with two-way sync #109 / Mirror CardDAV address books and suggest contacts while composing #157 add CardDAV as a third separate connection.
What it should be
- One Nextcloud connection, made where it is made today. Its credential, a username and an app password, is the one used for all three: Nextcloud serves CalDAV and CardDAV under the same
/remote.php/davwith the same app password. - Once connected, Settings → Calendars lists that account's calendars and Settings → Contacts its address books, to tick and mirror, without asking for an address or a password again. Disconnecting Nextcloud removes all three.
- The server address comes from the existing connection, so from the administrator's pinned address when there is one. No new environment variable, no second address setting, no second private-network exemption.
- The generic CalDAV and CardDAV connections stay for servers that are not Nextcloud (Radicale, Baïkal, Fastmail, iCloud…).
To settle here before code
- How a calendar or address book records the connection it came from, so disconnecting removes it and a changed app password reaches all three.
- What happens to an existing separate CalDAV connection to the same Nextcloud: left alone, or offered a move to the Nextcloud connection.
- The order of work: the calendar half can land on its own; contacts follow CardDAV: mirror address books, suggest contacts while composing, edit with two-way sync #109's CardDAV engine.
Related
- Connect my Nextcloud: one-click CalDAV connection when NEXTCLOUD_URL is set #108 (a
NEXTCLOUD_URLcalendar shortcut) is replaced by this. - CardDAV: mirror address books, suggest contacts while composing, edit with two-way sync #109 / Mirror CardDAV address books and suggest contacts while composing #157 (CardDAV): the sync engine, address books, the Contacts page and composer suggestions fit this as they are; their connection model has to follow it.
Activity
[-]One-click Nextcloud calendar connection when NEXTCLOUD_URL is set[/-][+]Connect Nextcloud once: files, calendars and contacts from one connection[/+]jo2904 commentedon Oct 15, 2026
Thanks for writing this up. Here is how I'd answer the three open questions, from reading the current model; tell me where you disagree before I start.
1. How a calendar or address book records its connection
It hangs off the Nextcloud
Integrationrow itself:calendar.integration_id(andaddress_book.integration_idin #109) points at the Nextcloud integration, not at a second CalDAV/CardDAV row. Both FKs are alreadyON DELETE CASCADEand the uniqueness is already(integration_id, remote_id), so no new table or column:secret.IntegrationUrlValidator::resolve()with the Nextcloud provider config, so the admin's pinned address wins and its existing private-network exemption applies. No new variable, no second address setting.In code:
CalDavCalendarDriver::supports()acceptsProvider::Nextcloudfor aCalendarSource, but not for a bareProvider, so Nextcloud never shows up in the "connect a CalDAV server" form.{base}/remote.php/dav(NextcloudDriver::DAV_ROOT) instead of.well-known.CalDavClient::baseUrl()reads the config of$integration->providerinstead of hard-codingProvider::CalDav.Provider(something likeoffersDav(DavService): Nextcloud → calendars and address books, CalDav → calendars, CardDav → address books) decides which connections Settings → Calendars and Settings → Contacts list. Nextcloud'skind()staysFiles.2. An existing separate CalDAV connection to the same Nextcloud
Left alone, then offered a move.
remoteId) as "already synced via …", and it can't be ticked. The unique index is per integration, so on its own it wouldn't stop the duplicate.calendar.integration_idand deletes the old row.remoteIds are absolute URLs, so events, sync tokens and colours survive without a full re-sync.3. Order of work
DavService/DavResourcerefactor ofCalDavDiscoveryfrom CardDAV: mirror address books, suggest contacts while composing, edit with two-way sync #109, so both halves share it. Then Nextcloud support in the CalDAV driver, the calendar list in Settings → Calendars, the duplicate guard and the disconnect confirmation.messages.fr.yaml.I'll close #108 once the calendar PR is open, since almost none of its diff survives this design.