kevinveenbirkenbachandClaude Opus 4.7
16bdbf03d7
Three classes of drift cleaned up across 85 .md files:
- Em-dashes: replaced ` — ` with the contextually correct separator
(colon for `term: explanation`, period to split clauses across
sentences/source lines, parentheses for asides, semicolon for
tight-linked continuations). Two intentional exceptions remain
in `docs/contributing/documentation.md` (the rule literal) and
inside a fenced ```sh block in `docs/contributing/actions/debugging/ci.md`.
- SPOT self-labels: rewrote "This is the SPOT for X" to describe
the subject directly ("This directory holds X" / "This file
describes X"). Cross-references to other artefacts' canonical
role remain unchanged.
- Heading-emoji position: moved leading-emoji headings (`# 🧩 Title`)
to trailing position (`# Title 🧩`) per the headline rule that
emojis MUST come after the title text.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.6 KiB
Add LDAP Users Manually for Immediate Sharing
In a default Nextcloud + LDAP setup, user accounts are only created in the internal Nextcloud database after their first login. This means that even if a user exists in LDAP, they cannot receive shared files or folders until they have logged in at least once, or are manually synchronized.
To make LDAP users available for sharing without requiring initial login, follow these steps:
1. Search for the User in LDAP
Check if the user exists in the configured LDAP directory:
docker exec -u www-data nextcloud php occ ldap:search <username>
If the user is found, proceed to the next step.
2. Create the User in Nextcloud from LDAP
Manually trigger a sync to register the user in the Nextcloud database:
docker exec -u www-data nextcloud php occ ldap:check-user --update <username>
Example:
docker exec -u www-data nextcloud php occ ldap:check-user --update viktoriakaffanke
Once executed, the user becomes fully available in the system (for sharing, group membership, and permissions) even without logging in.
3. Synchronize All Known Users (Optional)
To synchronize account data (display name, mail address, group memberships, etc.) for all users currently known to Nextcloud:
docker exec -u www-data nextcloud php occ user:sync-account-data
This step is especially useful after modifying LDAP attributes or group memberships, ensuring up-to-date data in the Nextcloud UI and permission system.
Playwright / E2E: biber First-Login Caveat
When a Playwright scenario exercises the OIDC/LDAP path as biber (or any non-administrator persona) against a freshly provisioned Nextcloud stack, the very first login can fail or stall because the Nextcloud internal account has not yet been materialized from LDAP; this matches the situation described above. On subsequent logins the account exists and the flow behaves normally.
If a brand-new deployment must pass the biber end-to-end scenario on its first run, either:
- Pre-provision
biberviaphp occ ldap:check-user --update biber(and any other personas used by the test suite) as part of the role's post-deploy tasks, or - Extend
roles/web-app-nextcloud/files/javascript.js(exposed to the login page through the injectedjavascript.js.j2template) with a small guard that detects the "user does not exist" Nextcloud error message and retries the OIDC handshake once after a short delay, giving the LDAP plugin time to provision the account.
Either approach keeps the Playwright suite deterministic without disabling the LDAP first-login-provisioning behavior that real users rely on.