/opt/tessera keeps its directory (compose derives the project name from it,
and a rename would have orphaned tessera_pgdata) and now tracks main.
COMPOSE_FILE pins it to the production file so the checkout does not switch
the server onto the dev defaults.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NEXT_PUBLIC_API_URL is read by the browser, not by the web container, so
http://api:3001 could never work outside Docker. The test server had been
corrected by hand long ago; the fix never came back here, so the file we
would ship to a customer was the broken one.
Also adopts the server's TESSERA_FORCE_CHANGE default of true, so a fresh
install requires the initial admin password to be changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The note predated 7bda56d and f574884, so two of its three points were
already shipped when it was picked up. Records what each commit actually
closed, and that the .env deny rules block the two committed template
files that hold no secrets.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The page carries platform config, tenant config and one per-user setting. The
per-user one -- the digest interval, which is what an ordinary user actually
comes for -- sits last, below three blocks they may not change.
Checked before writing it up: this is not a permission hole. The admin
endpoints are @Roles-guarded server side, so a normal user cannot change
anything; the page simply has no role check of its own, so they see controls
that fail on save.
The second half is a product question deliberately left open, because it is
not specific to this module: DKV-Fleet has the same shape, and every future
module with a personal setting will ask it again.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
/opt/tessera is not a working copy -- the compose file there is maintained by
hand, and the deploy path only pulls images. Two consequences showed up on the
same day: the renamed encryption key never reached the container although it
was in the server .env, and the "refuse to start without a key" guard does not
apply on alpha at all, because it only exists in the repository file.
The item deliberately stops short of proposing a fix to apply: it first asks
why the file is hand-maintained, since it may carry host-specific settings the
repository lacks, and moving to a checkout blindly would break the running
system.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Fallout from encrypting the LDAP bind password: the base compose file still
carries a hardcoded fallback key, so an install that never sets the variable
starts anyway and encrypts everything with a value that is in the repository.
The prod compose already requires it, which is the behaviour the base file
should have too.
Whether the example env files explain the key could not be checked in that
session, so the item says to look first rather than asserting it is missing.
Also notes, as an optional follow-up, why the variable is called
CALENDAR_ENCRYPTION_KEY and what a rename would have to handle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Notes what was deliberately left out: extracting and renaming the crypto
service out of calendar/ touches five modules and belongs in its own change,
so the existing provider is reused as-is and the naming smell is recorded in
LdapModule instead.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Records the user's choice between the two candidate link targets (the notice
page on oeffentlichevergabe.de, not the awarding portal's own page), what was
checked before touching the adapter, and the trap in verifying it: the target
is a single-page app that answers 200 with an identical shell for any id, so
only rendered content proves the link works.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neither is a Phase 16 defect; both surfaced while testing it and would
otherwise have been lost with the session.
1. Module activation has no licence check — a tenant admin can activate any
catalogue module for their own tenant. The grants matrix is NOT the hole: it
only distributes what is already active. Carries open product questions
(who issues licences, what expiry does), so it is written up as a draft, not
a decision.
2. The LDAP bind password is stored in clear text although an AES-256-GCM
service already exists and is used for calendar, DKV and tender inbox
credentials. Hashing is not an option here — the password must be replayable
to bind against the directory — so encryption at rest is the fix. No open
questions, just work.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
schalli