feat: Stammdaten, Ersteinrichtung, Zweitfaktor und Protokollansicht

Damit ist Etappe 1 fachlich vollstaendig. Ersteinrichtung in drei Schritten, bewusst ausserhalb des Anwendungsrahmens: der setzt Benutzer, zweiten Faktor UND eine betreute Person voraus - beim allerersten Start gibt es nichts davon. Die Aktion fuer den ersten Zugang sperrt sich selbst, sobald ein Benutzer existiert. Zweiter Faktor: Das Geheimnis wird zuerst nur abgelegt, ohne totpAktiviertAm. Erst ein echter Code aus der App schaltet ihn scharf. Wer sich beim Abtippen vertut oder die falsche App nimmt, wuerde sich sonst dauerhaft aussperren. Erst danach gibt es die Wiederherstellungscodes - einmal angezeigt, danach nur noch als Hash. Betreuungsjahr (src/lib/stammdaten/betreuungsjahr.ts): laeuft ab dem Tag der Bestellung, nicht ab dem Kalenderjahr. Schrittweise vorwaerts gerechnet statt ueber eine Differenz, damit Schaltjahre und der 29. Februar von selbst stimmen. Daran haengen Jahresbericht, Rechnungslegung und die Ausschlussfrist der Aufwandspauschale. Aendert sich das Bestellungsdatum, werden die Pflichtfristen neu abgeleitet - ueber einen dynamischen Import, damit die Stammdaten auch dann speicherbar bleiben, wenn das Fristenmodul fehlt. Protokollansicht zeigt je Eintrag die geaenderten Felder als alt -> neu. Die Aenderungen liegen verschluesselt, weil dort Diagnosen und Kontostaende stehen koennen. Seed legt bewusst keine echten Personendaten an, nur den ersten Zugang. Mit SEED_DEMO=true kommt ein vollstaendiger Beispielfall dazu - Erika Musterfrau, COPD GOLD III, Pflegegrad 3, Heimeinzug Januar 2026, leerstehendes Haus, zwei Versicherungen, laufender Antrag beim Bezirk mit acht Nachforderungen. Nur ausserhalb der Produktion. Docker Compose ohne Reverse Proxy - der ist auf dem Zielserver vorhanden. Die Datenbank hat keine Portfreigabe und ist nur ueber das interne Netz erreichbar; die Anwendung horcht auf 127.0.0.1. Etappe: 1 Phase: Fundament
2026-08-22 02:16:22 +02:00
parent dcd3a8ce71
commit 22b3a9b9e9
134 changed files with 30753 additions and 17 deletions
@@ -0,0 +1,24 @@
+import { NextResponse } from 'next/server'
+import { db } from '@/lib/db'
+
+/**
+ * Betriebsbereitschaft fuer den Healthcheck in docker-compose.
+ *
+ * Bewusst ohne Anmeldung, aber auch ohne jede Auskunft ueber Inhalte:
+ * geprueft wird nur, ob die Datenbank antwortet. Version und Datenbestand
+ * gehen niemanden etwas an, der die Adresse errät.
+ */
+export const runtime = 'nodejs'
+export const dynamic = 'force-dynamic'
+
+export async function GET() {
+  try {
+    await db.$queryRaw`SELECT 1`
+    return NextResponse.json({ status: 'bereit' }, { headers: { 'Cache-Control': 'no-store' } })
+  } catch {
+    return NextResponse.json(
+      { status: 'datenbank nicht erreichbar' },
+      { status: 503, headers: { 'Cache-Control': 'no-store' } },
+    )
+  }
+}
@@ -0,0 +1,140 @@
+import { NextResponse } from 'next/server'
+import { darf } from '@/lib/auth/rollen'
+import { db, nichtGeloescht } from '@/lib/db'
+import { env } from '@/lib/env'
+import { heuteAlsTag, plusJahre, plusTage } from '@/lib/fristen/datum'
+import { icsErzeugen, signaturPruefen, type IcsFrist } from '@/lib/fristen/ics'
+
+/**
+ * Abonnierbarer Fristenkalender.
+ *
+ * Diese Route ist die einzige Stelle der Anwendung, die Fachdaten ohne
+ * Anmeldung herausgibt - ein Kalenderprogramm kann sich nicht anmelden und
+ * keinen zweiten Faktor eingeben. Der Ausgleich dafuer:
+ *
+ * 1. Der Zugang haengt an einer HMAC-signierten Adresse. Ohne AUTH_SECRET
+ *    laesst sie sich nicht erraten oder faelschen.
+ * 2. Es wird trotzdem geprueft, ob der in der Adresse genannte Benutzer
+ *    heute noch aktiv ist und noch Lesezugriff auf das Modul FRISTEN hat.
+ *    Wird ein Mitleser entzogen, ist auch sein Kalender sofort leer.
+ * 3. Ausgeliefert werden nur Titel, Stichtag und Rechtsgrundlage. Kein
+ *    Name der betreuten Person, keine Diagnosen, keine Betraege.
+ * 4. Kein Caching durch Zwischenstationen.
+ */
+
+export const dynamic = 'force-dynamic'
+
+/** Ein Jahr zurueck, drei nach vorn - mehr braucht kein Kalender. */
+const RUECKBLICK_TAGE = 365
+const VORSCHAU_JAHRE = 3
+
+export async function GET(
+  _anfrage: Request,
+  kontext: { params: Promise<{ signatur: string }> },
+): Promise<Response> {
+  const { signatur } = await kontext.params
+
+  const gepruefte = signaturPruefen(signatur)
+  if (!gepruefte) return abgelehnt()
+
+  const { betreuteId, userId } = gepruefte
+
+  const [benutzer, betreute, zugang] = await Promise.all([
+    db.user.findUnique({
+      where: { id: userId },
+      select: { id: true, aktiv: true, geloeschtAm: true, rolle: true },
+    }),
+    db.betreute.findFirst({
+      where: { id: betreuteId, ...nichtGeloescht },
+      select: { id: true, vorname: true, nachname: true },
+    }),
+    db.betreuungsZugang.findUnique({
+      where: { userId_betreuteId: { userId, betreuteId } },
+      select: { rolle: true, freigegebeneModule: true },
+    }),
+  ])
+
+  if (!benutzer || !benutzer.aktiv || benutzer.geloeschtAm || !betreute) return abgelehnt()
+
+  const rechte = zugang
+    ? { rolle: zugang.rolle, freigegebeneModule: zugang.freigegebeneModule }
+    : benutzer.rolle === 'ADMIN'
+      ? { rolle: 'ADMIN' as const, freigegebeneModule: [] }
+      : null
+
+  if (!darf(rechte, 'FRISTEN', 'lesen')) return abgelehnt()
+
+  const heute = heuteAlsTag()
+  const datensaetze = await db.frist.findMany({
+    where: {
+      betreuteId,
+      ...nichtGeloescht,
+      status: { in: ['OFFEN', 'ERLEDIGT'] },
+      datum: { gte: plusTage(heute, -RUECKBLICK_TAGE), lte: plusJahre(heute, VORSCHAU_JAHRE) },
+    },
+    orderBy: { datum: 'asc' },
+    select: {
+      id: true,
+      titel: true,
+      beschreibung: true,
+      datum: true,
+      typ: true,
+      status: true,
+      rechtsgrundlage: true,
+      ausschlussfrist: true,
+      vorwarnungTage: true,
+      aktualisiertAm: true,
+    },
+  })
+
+  const fristen: IcsFrist[] = datensaetze.map((f) => ({
+    id: f.id,
+    // Erledigtes bleibt im Kalender stehen, damit die Historie stimmt - aber
+    // als solches erkennbar und ohne Wecker.
+    titel: f.status === 'ERLEDIGT' ? `✓ ${f.titel}` : f.titel,
+    beschreibung: f.beschreibung,
+    datum: f.datum,
+    rechtsgrundlage: f.rechtsgrundlage,
+    typ: f.typ,
+    ausschlussfrist: f.ausschlussfrist && f.status === 'OFFEN',
+    vorwarnungTage: f.status === 'OFFEN' ? f.vorwarnungTage : [],
+    aktualisiertAm: f.aktualisiertAm,
+  }))
+
+  // Nur die Initialen der betreuten Person: Der Kalendername steht auf dem
+  // Sperrbildschirm des Telefons und in der Kalenderliste des Anbieters.
+  const initialen = `${betreute.vorname.charAt(0)}${betreute.nachname.charAt(0)}`.toUpperCase()
+
+  const ics = icsErzeugen({
+    kalendername: `Betreuung ${initialen} — Fristen`,
+    fristen,
+    basisUrl: env.basisUrl,
+  })
+
+  return new NextResponse(ics, {
+    status: 200,
+    headers: {
+      'Content-Type': 'text/calendar; charset=utf-8',
+      'Content-Disposition': 'inline; filename="fristen.ics"',
+      'Cache-Control': 'private, no-store, max-age=0',
+      'X-Content-Type-Options': 'nosniff',
+      'X-Robots-Tag': 'noindex, nofollow',
+    },
+  })
+}
+
+/**
+ * Immer dieselbe Antwort, egal woran es lag - ob die Signatur falsch war,
+ * der Benutzer gesperrt oder die betreute Person geloescht, geht niemanden
+ * etwas an, der die Adresse durchprobiert.
+ */
+function abgelehnt(): Response {
+  return new NextResponse('Dieser Kalender ist nicht (mehr) verfügbar.', {
+    status: 404,
+    headers: {
+      'Content-Type': 'text/plain; charset=utf-8',
+      'Cache-Control': 'no-store',
+      'X-Content-Type-Options': 'nosniff',
+    },
+  })
+}