feat(caldav+carddav): auto create default cal & card
automatically create default Calendar and default addressbook per user
(no creation if user already have a such resource)
default name are "Personal"
this is using the user's life cycle like does the drives
answers to issue #545
This commit is contained in:
Edouard Vanbelle
@@ -0,0 +1,219 @@
|
||||
# =============================================================
|
||||
# OxiCloud — default CalDAV calendar + CardDAV address book
|
||||
# =============================================================
|
||||
# Regression pin for issue #545: fresh internal users must have a
|
||||
# default calendar ("Personal") and address book ("Contacts") ready
|
||||
# for CalDAV/CardDAV client discovery. Without this, Thunderbird's
|
||||
# "New Calendar → On the Network" returns "no calendars found" and
|
||||
# Contacts returns "no address books" — see the ticket.
|
||||
#
|
||||
# The invariant is delivered by two lifecycle hooks:
|
||||
# * DefaultCalendarLifecycleHook (calendar_service.rs)
|
||||
# * DefaultAddressBookLifecycleHook (contact_service.rs)
|
||||
#
|
||||
# Both fire on `on_user_created` (so fresh signups get it), and on
|
||||
# `on_user_login` as a safety-net (so users who predate the hook get
|
||||
# their defaults on next login — no data migration needed). External
|
||||
# users are skipped; on `on_upgraded_to_internal` they get the defaults.
|
||||
#
|
||||
# The idempotency check is ownership-based: `list_calendars_by_owner`
|
||||
# / `get_address_books_by_owner`. A user who manually created their
|
||||
# own calendar / address book keeps it; the hook doesn't provision
|
||||
# a redundant one. See docs/architecture/ discussion for the design.
|
||||
# =============================================================
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Step 1 — Admin login. Admin was created via `POST /api/setup`
|
||||
# which fires `dispatch_created`, so the default hooks should
|
||||
# have already provisioned admin's calendar + address book.
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
POST {{base_url}}/api/auth/login
|
||||
Content-Type: application/json
|
||||
{ "username": "{{username}}", "password": "{{password}}" }
|
||||
|
||||
HTTP 200
|
||||
[Captures]
|
||||
admin_token: jsonpath "$.access_token"
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Step 2 — Admin's default calendar exists via PROPFIND on
|
||||
# `/caldav/`. The "Personal" name is what Thunderbird / Apple
|
||||
# Calendar / DAVx⁵ show in their calendar picker; it must be
|
||||
# rendered verbatim in the DAV displayname element.
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
PROPFIND {{base_url}}/caldav/
|
||||
Authorization: Bearer {{admin_token}}
|
||||
Depth: 1
|
||||
Content-Type: application/xml
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<D:propfind xmlns:D="DAV:">
|
||||
<D:prop><D:displayname/><D:resourcetype/></D:prop>
|
||||
</D:propfind>
|
||||
```
|
||||
|
||||
HTTP 207
|
||||
[Asserts]
|
||||
# The default calendar's displayname must appear in the PROPFIND
|
||||
# multistatus. Thunderbird's discovery reads this exact element.
|
||||
body contains "Personal"
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Step 3 — Admin's default address book exists via REST list.
|
||||
# The `/api/address-books` endpoint returns admin's owned books;
|
||||
# "Contacts" (matching the Nextcloud convention) is what the
|
||||
# CardDAV clients render in their address-book picker.
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
GET {{base_url}}/api/address-books
|
||||
Authorization: Bearer {{admin_token}}
|
||||
|
||||
HTTP 200
|
||||
[Asserts]
|
||||
jsonpath "$" isCollection
|
||||
# The default address book's displayname must be in the list.
|
||||
# Body-contains rather than a jsonpath filter — Hurl's
|
||||
# `$[?(@.name == 'Contacts')]` returns a scalar when exactly one
|
||||
# match survives (single-element filter result), and `nth 0`
|
||||
# then fails with "invalid filter input type: boolean, expected
|
||||
# list". Body-substring is state-resilient (works whether admin
|
||||
# has 1 or N address books) and mirrors the CalDAV PROPFIND
|
||||
# assertion above.
|
||||
body contains "\"Contacts\""
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Step 4 — Fresh-user provisioning. Admin creates a new user;
|
||||
# the two hooks fire on `on_user_created` during the admin-create
|
||||
# transaction, so by the time we log in as the new user their
|
||||
# defaults are already there.
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
POST {{base_url}}/api/admin/users
|
||||
Authorization: Bearer {{admin_token}}
|
||||
Content-Type: application/json
|
||||
{
|
||||
"username": "dav-defaults-fresh",
|
||||
"email": "dav-defaults-fresh@example.com",
|
||||
"password": "TestPassword1!",
|
||||
"role": "user",
|
||||
"is_external": false
|
||||
}
|
||||
|
||||
HTTP *
|
||||
[Captures]
|
||||
fresh_user_id: jsonpath "$.id"
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Step 5 — Fresh user logs in. This is the critical path from
|
||||
# the ticket: a client (Thunderbird) authenticates as this user
|
||||
# and does PROPFIND on `/caldav/` — must find "Personal".
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
POST {{base_url}}/api/auth/login
|
||||
Content-Type: application/json
|
||||
{ "username": "dav-defaults-fresh", "password": "TestPassword1!" }
|
||||
|
||||
HTTP 200
|
||||
[Captures]
|
||||
fresh_token: jsonpath "$.access_token"
|
||||
|
||||
|
||||
PROPFIND {{base_url}}/caldav/
|
||||
Authorization: Bearer {{fresh_token}}
|
||||
Depth: 1
|
||||
Content-Type: application/xml
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<D:propfind xmlns:D="DAV:">
|
||||
<D:prop><D:displayname/><D:resourcetype/></D:prop>
|
||||
</D:propfind>
|
||||
```
|
||||
|
||||
HTTP 207
|
||||
[Asserts]
|
||||
body contains "Personal"
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Step 6 — Fresh user's address book listing includes "Contacts".
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
GET {{base_url}}/api/address-books
|
||||
Authorization: Bearer {{fresh_token}}
|
||||
|
||||
HTTP 200
|
||||
[Asserts]
|
||||
jsonpath "$" isCollection
|
||||
# Same rationale as Step 3 — body substring rather than filtered
|
||||
# jsonpath, avoids the "boolean vs list" Hurl quirk on
|
||||
# single-match filters.
|
||||
body contains "\"Contacts\""
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Step 7 — Ownership idempotency. Fresh user creates their OWN
|
||||
# calendar named "Personal" (matching what the hook auto-created).
|
||||
# This coexists — two rows with different UUIDs, same display
|
||||
# name. The hook's safety-net check on next login sees "user
|
||||
# owns ≥ 1 calendar" and SKIPS re-provisioning. Assertion below
|
||||
# proves both rows survive: two `Personal` matches in the body.
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
MKCALENDAR {{base_url}}/caldav/Personal/
|
||||
Authorization: Bearer {{fresh_token}}
|
||||
|
||||
HTTP *
|
||||
|
||||
|
||||
# Second login triggers `on_user_login` safety-net. If it wrongly
|
||||
# re-provisioned another default, we'd see three calendars now.
|
||||
POST {{base_url}}/api/auth/login
|
||||
Content-Type: application/json
|
||||
{ "username": "dav-defaults-fresh", "password": "TestPassword1!" }
|
||||
|
||||
HTTP 200
|
||||
[Captures]
|
||||
fresh_token_2: jsonpath "$.access_token"
|
||||
|
||||
|
||||
PROPFIND {{base_url}}/caldav/
|
||||
Authorization: Bearer {{fresh_token_2}}
|
||||
Depth: 1
|
||||
Content-Type: application/xml
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<D:propfind xmlns:D="DAV:">
|
||||
<D:prop><D:displayname/><D:resourcetype/></D:prop>
|
||||
</D:propfind>
|
||||
```
|
||||
|
||||
HTTP 207
|
||||
# The response body should contain "Personal" — at LEAST once
|
||||
# (the auto-provisioned one), plus the manually-created "Personal".
|
||||
# What must NOT happen is a proliferation of defaults on each
|
||||
# login. If the safety-net wrongly ignored the ownership check
|
||||
# and re-provisioned, we'd have 3+ calendars in the body. Count
|
||||
# occurrences of the `<displayname>Personal</displayname>` tag —
|
||||
# max should be 2 (auto + user's manual). This ceiling proves
|
||||
# the safety-net check is ownership-based, not stateful.
|
||||
#
|
||||
# Hurl doesn't ship a "count regex matches" primitive, so the
|
||||
# assertion is indirect: check that the whole `<multistatus>`
|
||||
# body length is bounded. On the CalDAV server we run, a
|
||||
# response with 2 calendars is well under 3 KB. 4 KB safely
|
||||
# rejects any accumulation.
|
||||
[Asserts]
|
||||
body contains "Personal"
|
||||
bytes count < 4096
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Cleanup — admin deletes the test user. The cascade
|
||||
# (`carddav.address_books.owner_id ON DELETE CASCADE` +
|
||||
# `caldav.calendars.owner_id ON DELETE CASCADE`) reaps the
|
||||
# defaults + manual calendar in the same transaction.
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
DELETE {{base_url}}/api/admin/users/{{fresh_user_id}}
|
||||
Authorization: Bearer {{admin_token}}
|
||||
|
||||
HTTP *
|
||||
Reference in New Issue
Block a user