kevinveenbirkenbachandClaude Opus 5
575a5a87ac
Every script a role ships now lives under `files/<language>/`, and the unit
suite is split the same way: `tests/unit/python/` beside new sibling trees for
the other languages. `tests/lint/filesystem/test_role_files_layout.py` keeps it
that way; directories whose shape is dictated from outside carry a `.nocheck`
naming the constraint (Docker build contexts, WordPress mu-plugins, the Joomla
extension, Odoo addons, Playwright suites, the `files/test/test.sh` harness
that `test-e2e-cli` resolves generically).
This cannot be applied in halves. Moving a file and repointing what names it
are the same change: 14 references resolve only at deploy time, so the tree is
green either before or after, never between.
Those 14 were found by static resolution over every reference class, not by the
test suite -- a full `make quality-high` was green while all of them were
broken:
* 7 `src:` values built from a role variable holding a bare filename
(svc-bkp-remote-2-local, decidim, espocrm, friendica, joomla, pixelfed x2).
The variable doubles as the destination name inside the container, so the
language segment belongs at the call site, not in the variable.
* `sys-service/tasks/04_base.yml` resolved every consumer's systemd script
through `first_found(..., errors='strict')` over `files/script.{sh,py}`.
18 roles ship exactly that and have no template fallback: the play would
have died on each.
* `sys-front-inj-javascript` fell back to `<role>/files/javascript.js`; the
interface now reads `files/javascript/javascript.js`.
* `sys-front-inj-logout/templates/head_sub.j2` built the cache-busting mtime
path through `path_absolute(... 'files', ...)`.
* 4 `ansible.builtin.script:` invocations naming a bare command
(pull.py, prune.sh, set_postgres_superuser_password.sh, ganesha-serve.sh).
* `dev-python/files/shell/install.sh` pointed at a sibling role's script.
Depth-dependent paths inside the moved trees were bumped accordingly: 59
`parents[N]` computations, 12 relative climbs, and the per-role recover CLI,
whose path `cli/administration/recover/recoverers.py` still assembled from the
pre-move location.
Co-Authored-By: Claude Opus 5 (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/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.