74 lines
7.0 KiB
Markdown
74 lines
7.0 KiB
Markdown
# Familieneinladungen und Abwesenheitsverwaltung
|
|
|
|
Stand: 9. Oktober 2026. Umsetzung der Befunde F01 und F02 aus der [Ablaufprüfung](ABLAUFPRUEFUNG.md), einschließlich Entfernung des künstlichen Gruppenfilters aus F12.
|
|
|
|
## Familieneinladungen
|
|
|
|
- Die Familienanlage erfasst weiterhin Eltern und Kinder gemeinsam. Die Familie, Konten, Aktivierungslinks und Versandaufträge werden gemeinsam gespeichert.
|
|
- Scheitert danach der Mailversand, bleibt die Familienanlage erfolgreich. Das Formular schließt, die Liste aktualisiert sich und eine Warnung weist auf den erneuten Versand hin. Auch die Ergänzung eines Elternteils in einer bestehenden Familie folgt diesem Ablauf.
|
|
- Jeder Empfänger wird bearbeitet, auch wenn eine andere Einladung fehlschlägt.
|
|
- Tabelle, Kartenansicht und Familien-Details zeigen den Status je Elternkonto: aktiviert, Aktivierung offen, Versand läuft, versendet, fehlgeschlagen oder abgelaufen. Soweit vorhanden, wird das Ablaufdatum angezeigt.
|
|
- Kita-Admins können die Einladung innerhalb ihrer Kita beim jeweiligen Elternteil erneut senden. Aktivierte Konten werden nicht erneut eingeladen. Parallel ausgelöste Versandversuche werden gegen doppelte Bearbeitung geschützt.
|
|
- Ein noch gültiger, fehlgeschlagener Versand wird mit demselben Link wiederholt. Bei abgelaufenem oder zuvor erfolgreich versendetem Link wird ein neuer Link für sieben Tage erstellt; ältere Aktivierungslinks des Kontos werden ersetzt. Direkt nach einem erfolgreichen Versand gilt eine Minute Abstand bis zum erneuten Versand.
|
|
- Wird die Adresse eines noch nicht aktivierten Kontos korrigiert, versendet das Speichern automatisch eine neue Einladung an diese Adresse. Solange die Adressänderung ungespeichert ist, ist der separate erneute Versand gesperrt.
|
|
- Bereits bestehende Elternkonten und Aktivierungslinks bleiben gültig. Alte Konten ohne gespeicherten Versandstatus erscheinen als „Aktivierung offen“; beim erneuten Senden wird der Status ergänzt. Das Löschen und Neuanlegen einer Familie ist dafür nicht nötig.
|
|
- Nach der Aktivierung wird der Einladungsstatus abgeschlossen. „Versendet“ bedeutet, dass der Mailtransport die Nachricht angenommen hat; eine tatsächliche Zustellung oder ein späterer Bounce wird hier nicht überwacht.
|
|
|
|
Bei Eingabefehlern bleiben die Formulardaten erhalten. Nach einem erfolgreichen Vorgang öffnet sich das Formular wieder mit einem frischen Zustand. Die Kinder-Schaltfläche entfernt das tatsächlich gewählte Kind aus dem Entwurf.
|
|
|
|
## Kinder-Abwesenheiten
|
|
|
|
„Meine Abwesenheiten“ ist über das Menü und die Dashboard-Karte erreichbar. Die Seite zeigt ausschließlich Meldungen des eigenen Haushalts, getrennt nach aktuellen/zukünftigen und vergangenen Meldungen, mit jeweils bis zu 20 Meldungen pro Seite.
|
|
|
|
| Rolle | Neue Meldung | Ändern oder zurücknehmen |
|
|
| --- | --- | --- |
|
|
| Eltern | Eigene aktive Kinder, ab heute | Eigene Meldungen, deren Beginn nach heute liegt; auch der neue Beginn muss zukünftig bleiben. |
|
|
| Kita-Admin, Notdienst-Koordination, Fachkraft | Der bestehende Dashboard-Meldeweg betrifft den eigenen Haushalt. | Vorhandene Meldungen innerhalb der eigenen Kita, einschließlich laufender Meldungen, in der Kita-Tagesübersicht korrigieren oder zurücknehmen. |
|
|
|
|
Die vom Nutzer bestätigte Mehrtagesregel gilt für die gesamte Meldung: **Sobald sie begonnen hat, übernimmt die Kita auch die noch zukünftigen Tage.** Eltern können die zukünftige Hälfte einer laufenden Meldung nicht eigenständig abtrennen.
|
|
|
|
Die Bearbeitung zeigt Zeitraum, Grund und Bemerkung in einem Dialog. Bei Verschieben des Beginns hinter das bisherige Ende wird das Ende angepasst. Eine Rücknahme erhält einen eigenen Bestätigungsdialog. Laufende Meldungen zeigen Eltern einen verständlichen Hinweis auf die Kita.
|
|
|
|
Die Regeln gelten auch serverseitig:
|
|
|
|
- Aktuelle Rollen und Haushaltszugehörigkeit werden vor Schreibzugriffen aus der Datenbank geprüft.
|
|
- Kalendertage werden unabhängig von der Server-Zeitzone als UTC-Datum gespeichert; die Grenze „heute“ folgt `Europe/Berlin`.
|
|
- Ungültige Tage, umgekehrte Zeiträume und Überschneidungen werden abgewiesen. Gleichzeitige Meldungen für dasselbe Kind werden serialisiert.
|
|
- Ein veralteter Bearbeitungsstand überschreibt keine zwischenzeitliche Änderung. Die Oberfläche bietet bei diesem Konflikt das Aktualisieren der Ansicht an.
|
|
- Erfolgreiche Änderungen aktualisieren Dashboard, eigene Verwaltung und Kita-Tagesübersicht.
|
|
|
|
Der bisherige Gruppenfilter „Krippe/Elementar“ wurde entfernt, weil keine tatsächliche Gruppenzuordnung hinterlegt ist. Ein fachlicher Gruppenfilter bleibt ein eigener späterer Ausbau.
|
|
|
|
## Deployment und Betrieb
|
|
|
|
Das Prisma-Modell `Invitation` erhält einen optionalen Bezug zum Elternkonto sowie Versandzeit, Versuchszähler, Fehlerstatus und eine zeitlich begrenzte Versandsperre. Vorhandene Datensätze müssen nicht neu angelegt werden.
|
|
|
|
Der Docker-Produktionsstart führt vor dem allgemeinen Schemaabgleich automatisch das additive, wiederholbare Upgrade [familieneinladungen.sql](../deploy/sql/familieneinladungen.sql) aus. Es funktioniert auf bestehenden Datenbanken und überspringt noch leere Datenbanken. **Es sind keine neuen Umgebungsvariablen nötig.** Resend-Absender, API-Schlüssel und App-Adresse werden wie bisher verwendet.
|
|
|
|
Bei einem eigenen Startablauf ohne `scripts/start-production.sh` vor dem Start des neuen Codes ausführen:
|
|
|
|
```sh
|
|
npx prisma db execute --file deploy/sql/familieneinladungen.sql --schema prisma/schema.prisma
|
|
npx prisma db push --skip-generate
|
|
```
|
|
|
|
Die normalen Sicherungs- und Schema-Prüfschritte gelten weiterhin; siehe [Deployment und Mailversand](../deploy/DEPLOYMENT_UND_MAILVERSAND.md). Für Familieneinladungen ist kein zusätzlicher Cronjob erforderlich. Fehlgeschlagene oder unterbrochene Versandversuche werden gezielt durch Kita-Admins wiederholt.
|
|
|
|
## Prüfung
|
|
|
|
- Unit-Tests für echte Kalendertage, Berliner Mitternachts-/Zeitumstellungsgrenzen und Einladungszustände.
|
|
- PostgreSQL-Integrationstests mit simuliertem Mailtransport: Speicherung trotz Mailfehler, zweiter Empfänger, gezieltes erneutes Senden, Ablauf/Erneuerung, Alt-Konten, paralleler Versand, Aktivierungsabschluss, Adresskorrektur und Berechtigungen.
|
|
- PostgreSQL-Integrationstests für Eltern- und Kita-Korrekturen, begonnene Mehrtagesmeldungen, fremde Haushalte/Kitas, Überschneidungen, konkurrierende Erstellung und veraltete Bearbeitungsstände.
|
|
- Wiederholbarkeit des SQL-Upgrades auf leerem und bestehendem Testschema mit Erhalt vorhandener Tokens.
|
|
- Lokale Browserprüfung mit deaktiviertem echtem Mailversand: Anlage und Bearbeitung schließen trotz Versandwarnung; Formulare behalten Fehler-Eingaben und lassen sich erneut öffnen; zukünftige Elternmeldung und laufende Kita-Meldung werden erfolgreich korrigiert.
|
|
- TypeScript, ESLint und Produktionsbuild.
|
|
|
|
Testbefehle:
|
|
|
|
```sh
|
|
npm run test:family-absence
|
|
TEST_DATABASE_URL='postgresql://USER@127.0.0.1:PORT/TEST_DATABASE' npm run test:family-absence:integration
|
|
```
|
|
|
|
Integrationstests akzeptieren nur eine ausdrücklich benannte lokale Testdatenbank. Die Browserprüfung nutzt ausschließlich synthetische Daten und verschickt keine echten E-Mails.
|