20 flat scrolling sections replaced with a 10-item sidebar nav (Übersicht,
Mieter, Tickets & Handwerker, Putzplan, WG-Kasse, Inventar & Übergabe,
Zugang, Küche & Müll, Dokumente, Verträge & Abrechnung). One page visible
at a time, collapsible off-canvas menu on mobile. No backend/API changes.
The lock in this WG is a Homematic IP door lock (keypad + alarm), not
Nuki/Tuya as originally specced — confirmed with the user. Homematic IP
has no official self-service partner API for Access-Point-only setups
(no local CCU), so this uses the actively-maintained open-source
`homematicip` Python library (implements the same reverse-engineered
cloud protocol used by the official app) via two scripts rather than
reimplementing the HTTP/HMAC handshake from scratch — lower risk of
subtly wrong protocol details.
- scripts/hmip_register.py: non-interactive pairing (connection
request -> wait for the physical blue-button press on the Access
Point -> auth token). Writes progress to a status file so the API
can poll it instead of blocking a request for up to ~6 minutes.
- scripts/hmip_control.py: list-devices / lock / unlock via
HMIP_ACCESS_POINT + HMIP_AUTH_TOKEN env vars (not CLI args, so they
don't leak into process listings).
- routes/smartLock.ts: POST /smartlock/pairing/start + GET .../status
(LANDLORD/ADMIN, one-time setup), GET /smartlock/devices
(LANDLORD/ADMIN), POST /smartlock/devices/:id/:lock|unlock (any
authenticated user — this is the tenant-facing "keyless door" use
case from the spec). All lock/unlock routes 409 until pairing has
produced HMIP_ACCESS_POINT/HMIP_AUTH_TOKEN.
Does NOT cover temporary guest PIN codes on the keypad itself — that's
handled through Homematic IP's own "eSchlüssel" app feature, which
isn't exposed by this API; guest codes remain DB-only as before.
"Automatische Warnungen bei Auslauf/Kündigungsfristen" was only a
passive dashboard view (GET /contracts/notice-deadlines, isUrgent
flag) — nobody gets notified unless the landlord happens to open the
cockpit. Adds a daily job (same pattern as dailyDunningJob.ts) that
pushes landlords/admins when a contract's notice deadline falls
within 30 days. Dedup is via the Notification history (payload.
contractId within a 14-day cooldown) rather than a new Contract
column, consistent with contracts.ts's existing "no extra model
needed" approach.
sendPushNotification() (services/notificationService.ts) already called
the real OneSignal API correctly, but two things made it unreachable:
no endpoint ever set User.pushToken, and no job existed for the two
push-based requirements beyond rent dunning — cleaning check-in
reminders and the trash-calendar evening push. Both CleaningTask and
TrashSchedule already had an unused `reminderSentAt` column, so the
schema anticipated this and was just never wired up.
- PUT /v1/auth/push-token: registers the current device's OneSignal
Player ID.
- jobs/cleaningReminderJob.ts, jobs/trashReminderJob.ts: same
find-due/send-once/mark-reminderSentAt pattern as the existing
dailyDunningJob.ts. Safe to run without OneSignal credentials
configured — sendPushNotification degrades to an in-app Notification
log when ONESIGNAL_APP_ID/API_KEY or a user's pushToken are absent.
Not done here (needs real third-party setup from the user, same as the
Cloudflare tunnel token pattern): ONESIGNAL_APP_ID/API_KEY in .env, and
a frontend OneSignal Web SDK integration (service worker, VAPID keys)
to actually populate pushToken from a real browser.
Prisma 5.22's generator wants the explicit output to point at the
internal .prisma/client directory (which @prisma/client forwards to),
not the @prisma/client package directory itself — pointing it there
directly made `prisma generate` fail outright ("replace ... with
../backend/node_modules/.prisma/client").
Implements the previously-deferred "Bewertungssystem für Zwischenmieter"
requirement, which existed only as a vague idea with no model, route, or
UI. Design (confirmed with user): any authenticated user can rate any
tenant (1-5 + optional comment), freestanding (not tied to a contract,
creatable any time), visible only to LANDLORD/ADMIN — tenants can submit
ratings but not view them, to keep WG-internal friction out of the open.
- prisma: TenantRating model + User relations. Also pins the Prisma
Client `output` path explicitly: since schema.prisma lives at the repo
root (no package.json there) while node_modules only exists under
backend/, `prisma generate`'s root-inference walked up past the repo
and wrote into an unrelated ancestor directory when invoked from a
fresh checkout. The explicit relative output keeps repo-root schema +
backend-only deps working the same locally and in Docker.
- backend: GET/POST /v1/ratings (role-gated read), GET /v1/ratings/tenants
(name+room only, any authenticated user, for the picker).
- dashboard: rating form for everyone, landlord-only ratings/summary view.
Implements the "1-Klick-PDF-Export für Handwerker" requirement from
the ticketing module spec, which existed only as a schema stub
(HandoverProtocol.pdfUrl) with no actual generator anywhere in the
codebase. Adds a server-side PDF endpoint (pdfkit, no headless
browser needed) summarizing a ticket's category, priority, status,
room, reporter and description, plus a "PDF" button in the landlord
cockpit that downloads it via an authenticated blob fetch (the API
uses a Bearer token, not cookies, so a plain <a href> wouldn't carry
auth).
The seed's deleteMany() chain didn't cover Ticket (or other tables
that now reference User), so it started failing with a foreign key
violation once real ticket data existed. Rather than cascading the
delete (which would wipe real data on every container restart), seed
now only runs against an empty database and is a no-op otherwise.
ts-node resolved node_modules relative to the script path, so running
from prisma/seed.ts (outside backend/) never found bcryptjs or
@prisma/client in backend/node_modules — the seed silently failed on
every container start. Moving the script under backend/prisma/ fixes
resolution; also adds a missing .gitignore for node_modules.
