Server-renderet af FastAPI selv (Jinja2 + vanilla JS/CSS, intet
build-step) mod det eksisterende domæneopløste JSON-API fra 8b.
GET / viser bestillingssiden når en runde er åben (rundeoverskrift,
intro_text, kategori-grupperet vinkatalog med live-beregnet
EUR/DKK-total, bestillingsformular), ellers en tilmeldingsside.
GET /tilmelding er altid tilgængelig uafhængigt af rundestatus, og
GET /afhentning viser rutens meeting_info. Layoutet er modelleret
efter den gamle sides bestillingsside. get_current_round's
serialiseringslogik er udtrukket til en delt _build_page_info-helper,
så JSON-API'et og de nye HTML-sider genbruger nøjagtig samme
domæne-/rundeopslag.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Offentlige endpoints afgør nu ruten via Host-headeren
(Route.public_domain) i stedet for route_id i URL'en, så én
frontend kan betjene flere organisationers domæner via reverse
proxy. GET /public/current-round returnerer altid 200 med
current_round: null når ingen runde er åben (i stedet for 404),
og nyt POST /public/signup lader deltagere tilmelde sig med kun
navn+email uden at røre et eksisterende telefonnummer.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
POST /public/routes/{id}/orders and GET .../current-round are the
first fully unauthenticated routes in the app — no CurrentUser or
org-scoping helper applies, route_id comes straight from the URL.
Participant identification matches the old system's no-login design:
an existing participant (case-insensitive email match on the route) is
reused, and — per explicit user correction — its name/phone/is_active
are overwritten from the submission every time, since there's no login
or "edit my details" page; the order form *is* how members keep their
contact info current. is_active is a checkbox on the form itself
(default true), not inferred. A new email always creates a new
participant row — that's the deliberate no-login way to "change
email". An IntegrityError race on concurrent same-email submissions
falls back to re-selecting the winner rather than 500ing.
Order confirmation email reuses 7b's render/send/log pattern for a
single participant, but a missing order_confirmed template (or missing
route sender identity) is a silent no-op + logger.warning, never a
blocking error — an admin configuration gap must never stop a real
order, unlike task 7b's admin-triggered /announce which fails fast on
the same conditions.
Per explicit user correction, the confirmation email deliberately
reproduces the old system's full-catalog receipt (every wine in the
round, grouped by category, ordered quantity filled in where
applicable) — confirmed via old-emails/Kvitering.eml discussion to be
a deliberate mimicry of the physical order sheet used when buying wine
at the producer's cellar, not a legacy-template artifact to simplify
away. Currency totals are computed at full Decimal precision (EUR
summed, then × eur_dkk_rate with no intermediate rounding) and only
rounded to 2dp (ROUND_HALF_UP) at final display formatting, per
correction — avoids compounding an early rounding error into the DKK
figure.
Empty order_lines is rejected with 400 (not the Pydantic-level 422 a
schema constraint would give) — the old empty-order signup/unsubscribe
hack is intentionally not resurrected here; a real signup/unsubscribe
flow is a separate future task per the user's own framing.
Verified end-to-end directly against the real route 4: a temporary
open round + wine offerings + order_confirmed template, a real order
submitted and a real confirmation email sent/logged, a second order
with the same (differently-cased) email confirmed to update the
existing participant in place rather than duplicate it, a
different-round wine_offering_id rejected (400), an empty order
rejected (400 not 422), and the missing-template case confirmed to
still return 201 with no new MailLog row. All temporary data removed
afterward; the real participant (carsten@itkon.dk, id 133) — legitimately
touched by the get-or-create-with-update logic during testing, exactly
as designed — was restored to its original name/phone/is_active. The
other 307 real participants were untouched throughout.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
POST /webhooks/postal (unauthenticated — RSA signature is the auth)
verifies the X-Postal-Signature-256 header: RSA-SHA256/PKCS1v15 over
the raw request body, using the same keypair as DKIM signing. Verified
directly against Postal's own source (lib/postal/http.rb, signer.rb)
rather than guessed, after the user pointed out the mechanism and that
their instance is new enough to use the -256 (SHA256) header over the
legacy SHA1 one. The public key is stored as the raw base64 DER blob
from the domain's DKIM DNS TXT record (dig TXT
postal-eWHeqb._domainkey.vinindkoeb.dk) — no PEM wrapping needed,
cryptography.load_der_public_key takes it directly.
Events are correlated to MailLog via postal_message_id. MessageSent
(actual delivery confirmation, not to be confused with task 7b's
synchronous "Postal accepted the request") maps to the DELIVERED
status already reserved for it; MessageDeliveryFailed/MessageBounced/
MessageHeld/MessageDelayed map to new terminal/transient statuses.
MessageLoaded/MessageLinkClicked set separate opened_at/clicked_at
timestamps rather than overwriting status, since engagement can happen
after delivery and shouldn't regress it. DomainDNSError and any
unrecognized event are acknowledged (200) and ignored — no message to
correlate.
Discovered along the way: the native_enum=False enum columns are
plain length-capped VARCHARs with no IN-list CHECK constraint, so
adding "held"/"delayed" needed no constraint migration, just the two
new opened_at/clicked_at columns Alembic did autogenerate correctly.
Verified: signature logic in isolation against a self-generated RSA
keypair (valid data/signature accepted, tampered data and garbage
signatures rejected), the real DKIM key parses correctly (1024-bit
RSA), the live endpoint rejects missing/invalid signatures with 401,
and the event-to-MailLog mapping logic was exercised directly (not
over HTTP, since a validly Postal-signed payload can't be forged
without their private key) against an isolated throwaway sandbox —
all cleaned up afterward, real route/participant data confirmed
unaffected throughout.
True end-to-end verification (a real Postal-originated webhook call)
requires the app to be deployed somewhere Postal can reach, plus
configuring the webhook URL in Postal's admin UI — both are deployment
steps outside this coding task.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
POST /purchase-rounds/{id}/announce renders the route's round_announced
MailTemplate with simple {{variable}} substitution (app/services/
mail_rendering.py) for every active participant on the route, sends
via Postal's real HTTP API (app/services/postal.py — request/response
shapes verified directly against docs.postalserver.io, not guessed),
and records one MailLog row per attempt (sent/failed, Postal's
message id + token for the future webhook in 7c, denormalized
rendered_subject so the log reflects what was actually sent even if
the template changes later). A failed send for one participant doesn't
abort the rest — each attempt is isolated and committed individually.
Route gained sender_name/sender_email in 7a; both are now populated
for the real route from the historical emails ("Finn Gram - Fælles
Vinindkøb <finn@vinindkoeb.dk>") directly in the DB, since there's no
Route CRUD API yet.
Verified end-to-end against the real Postal instance: a real test
email was sent and received via an isolated throwaway Organization/
Route/Participant/PurchaseRound/MailTemplate sandbox (never the real
route's 308 participants), MailLog captured the correct Postal message
id/token, and a temporarily-invalid API key produced a clean
sent:0/failed:1 result with Postal's actual error message stored,
not a 500. All test data removed afterward; real route/participant
data confirmed untouched.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MailTemplate holds subject + body_html with plain {{variable}}
placeholders (no loops/conditionals — the user edits these directly
and is comfortable generating list-shaped content like the wine
catalog in code instead, per the real "Kvitering" email reviewed in
old-emails/). One template per (route, event_type), matching the
three CLAUDE.md mail-events (round_announced, order_confirmed,
payment_confirmed); UNIQUE(route_id, event_type) enforces that and
IntegrityError is caught as 409, same pattern as prior tasks.
Route gains nullable sender_name/sender_email — the real old emails
show a per-route sender identity (e.g. "Finn Gram <finn@vinindkoeb.dk>"
for this route), so it lives on Route rather than being duplicated
across each of its templates.
This is data + CRUD only. Actual Postal sending, the round-announce
action, and per-participant send logging are task 7b; a Postal
webhook receiver for delivery status is task 7c — both need real
Postal API access, still to be arranged.
old-emails/ (real historical order/participant data) is gitignored,
same treatment as old_participants.json.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Full CRUD on PurchaseRound and WineOffering, org-scoped via two new
join-based dependencies.py helpers (get_round_in_organization,
get_wine_offering_in_organization) mirroring task 5's pattern. New
rounds always start as draft regardless of what the client posts,
avoiding a confusing creation-time constraint error.
POST /purchase-rounds/{id}/copy implements "kopiér fra forrige runde":
duplicates every round field (dates, texts) and every wine offering
(incl. category) into a fresh draft, leaving the source untouched.
PurchaseRound DELETE gets a three-tier policy based on status: draft
deletable by any admin, open never deletable, closed only by an
elevated superadmin. This is runtime-conditional on the loaded row, so
the elevation check was extracted out of get_current_active_superuser
into a standalone require_elevated_superuser(user, token) helper that
both the dependency and this handler call directly. WineOffering
delete has no such tier — an offering with real order lines is already
blocked by the existing RESTRICT FK, caught here as a 409.
Also seeds the 8 wine categories (empty table blocked any offering
creation) via a plain Alembic data migration, idempotent and
unconditional (no secret involved, unlike the task-4 superuser seed).
Verified end-to-end: dates-required 409, open round successfully
patched with dates, wine offerings created, round copied (new draft,
duplicated offerings with new ids/same category), open-round delete
403, closed-round delete 403 then 204 after /auth/elevate, wine
offering delete 204, draft round delete 204 (cascades its remaining
offering). DB left clean, participant count unaffected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CurrentSuperuser now requires a short-lived (5 min) elevated JWT
claim in addition to the is_superadmin flag, obtained via the new
POST /auth/elevate (no re-authentication — the user is already the
only superadmin in practice; this is a deliberate-confirmation guard
against accidentally triggering a destructive action, not a defense
against a stolen session). Regular login tokens keep working unchanged
for all non-superadmin routes; DELETE /participants/{id} from task 5
now needs a fresh /auth/elevate call, no other code changes required
since CurrentSuperuser's meaning changed underneath it.
create_access_token gained an extra_claims param (backward compatible)
to carry the elevated flag.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Full CRUD on Participant scoped to the caller's organization via new
get_route_in_organization/get_participant_in_organization helpers in
app/dependencies.py (shared cross-cutting spot, reused by task 6).
PATCH is_active is the primary deactivation path — replaces the old
spreadsheet-era "empty order" trick and preserves order history for
participants who leave and later return. DELETE is a separate,
superadmin-gated hard-delete for GDPR erasure requests, which cascades
to the participant's orders.
Adds UNIQUE(route_id, email) at the DB level (existing 308 participants
already conform, per task 3's dedup) plus email normalization on
create/update, so case-variant duplicates can't reappear via the API.
Every write path relies on catching the constraint's IntegrityError for
a clean 409 rather than a racy pre-check.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Password hashing via pwdlib (argon2id), stateless JWT auth (2h expiry)
delivered as an Authorization: Bearer token, with an OAuth2PasswordBearer
dependency (app/dependencies.py) protecting future routes. Establishes
app/routers/ as the convention for feature routes, explicitly registered
in main.py (no auto-discovery, unlike app/models/).
The first admin user is seeded via an Alembic data migration gated on
SUPERUSER_EMAIL/SUPERUSER_PASSWORD env vars (read at migration-run time
only, never persisted to .env/git) rather than a script or open endpoint,
so a fresh `alembic upgrade head` still succeeds without them. The
migration mirrors the users/organization tables locally instead of
importing the live SQLModel classes, keeping it a stable schema
snapshot; it does import app.core.security.hash_password, a pure
utility with no table-shape dependency.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nine SQLModel table models covering the Organization/Route hierarchy
(WineCategory, Organization, User, Route, Participant, PurchaseRound,
WineOffering, Order, OrderLine), with explicit tablenames, FK cascade
behavior, and a CHECK constraint preventing a PurchaseRound from
reaching open/closed status without its opens_at/order_deadline_at/
pickup_at dates set. Also fixes the Alembic script template to import
sqlmodel (needed for autogenerate's AutoString column type).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Config-driven DATABASE_URL shared by the app and Alembic's env.py
(fixes v1's config drift), psycopg3 driver, auto-discovering
app/models package for SQLModel.metadata, and a /health endpoint
that exercises the DB dependency end-to-end.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
