# Kita-Planer – Funktionsübersicht und aktueller Stand
## Ergänzung vom 12.10.2026: Notdienst-Benachrichtigungen
- Automatische Erinnerungen erfassen auch unvollständige Verfügbarkeiten. Das Soll wird aus allen aktiven Kindern und die Istzahl aus unterschiedlichen gültigen Tagen berechnet. Admin-/Koordinationskonten mit eigenem Haushalt gehören zur Eltern-Empfängergruppe.
- Die Erinnerungsfrist bezieht sich jetzt ausdrücklich auf den 26. als Ende der Eintragsfrist. Standard: sieben Tage vorher ab 9 Uhr Berliner Zeit; 0 deaktiviert die automatische Runde. Verpasste Läufe werden innerhalb der noch offenen Frist nachgeholt. Jede Kita/Folgemonat erhält eine automatische Runde; manuelle Erinnerungen sind je Konto/Tag dedupliziert.
- Beim ersten Veröffentlichen werden Mailaufträge in derselben Transaktion gespeichert. Pro erreichbarem Konto wird eine gemeinsame Nachricht mit den aktuellen eigenen Diensten erzeugt. Mehrfaches Veröffentlichen erzeugt keine zweite Runde. Mailfehler ändern den veröffentlichten Status nicht.
- Die Monatsplanung zeigt Versandzahlen und Einzelstatus sowie eine manuelle Wiederholung offener/fehlgeschlagener Nachrichten. Bereits versendete oder inzwischen überholte Aufträge werden dabei nicht neu verschickt.
- Der bestehende geschützte Notdienstjob verarbeitet die Nachrichten automatisch. Gespeicherte Reservierungen, Idempotenzschlüssel, zunehmende Wiederholungsabstände und erneute Berechtigungs-/Einteilungsprüfung sichern die Verarbeitung. Der Produktionsstart startet einen abgebrochenen Worker erneut.
- Additive Migration: `20261012000000_notdienst_notifications`. Sie erhält die bisherigen Constraints und ergänzt drei weitere Tenant-Fremdschlüssel. Einrichtung und Grenzen stehen in [deploy/README.md](../deploy/README.md).
Prüfbefehle: `npm run test:mail`, `npm run test:runtime`, `npm run test:notdienst` und `TEST_DATABASE_URL=postgresql://USER:PASSWORD@127.0.0.1:PORT/kita_notifications_test npm run test:notdienst:notifications` nach Anwendung der Migrationen auf dieser separaten Testdatenbank. Die Versandtests verwenden ersetzte Transporte; reale Eltern werden nicht angeschrieben.
Abnahme: 33 neue Versand-Integrationstests, vier Tests des tatsächlichen SDK-Transports, zwei Supervisor-Tests, sechs Datums-/Fristtests sowie 106 bestehende Sicherheits-, Planungs-, Kalender- und Elternablauftests erfolgreich (151 insgesamt, keine übersprungenen Tests). Browserprüfung mit lokalem Mailserver: automatische Erinnerung einmalig, Veröffentlichung trotz simuliertem Versandfehler, sichtbare Einzelstatus, erfolgreiche Wiederholung und mobile Anzeige. TypeScript und Produktionsbuild erfolgreich; ESLint ohne Fehler mit acht bestehenden Warnungen.
Zusätzliche Upgrade-Prüfung gegen das vorige Schema: vorhandene Familien, Konten, Kinder, veröffentlichter Plan und Einteilung unverändert erhalten; keine nachträglichen Veröffentlichungsmails angelegt. Die Zahl der ergänzenden Tenant-Fremdschlüssel steigt von 41 auf 44.
## Ergänzung vom 12.10.2026: Kalender und kleine Bedienungsverbesserungen
- Eigene Mitbringbeiträge lassen sich direkt mit Speichern/Abbrechen bearbeiten. Enter speichert; Escape schließt den Termindialog und verwirft den Entwurf. Eingaben werden auf 1 bis 500 Zeichen begrenzt; fremde Beiträge können auch von Admin/Koordination nicht umgeschrieben werden. Ein bestätigter Termin mit aktiver Mitbringliste und die Kita-/Autorzuordnung werden serverseitig geprüft.
- Eltern mit Admin- oder Koordinationsrolle können für den eigenen Haushalt Dienste tauschen. Kalenderknöpfe und offene eingehende/ausgehende Anfragen stehen ihnen ebenfalls zur Verfügung. Tauschmails berücksichtigen verifizierte, aktive Elternkonten aller drei Rollen im jeweils beteiligten Haushalt. Konten ohne eigenen Haushalt erhalten dadurch kein Tauschrecht; fremde Angebote und aktive Alarme bleiben gesperrt.
- Die fest eingetragene „4“ am Menüpunkt Notdienst wurde entfernt.
- Kein Schema-Upgrade erforderlich. Automatische Erinnerungen und Veröffentlichungsmails bleiben die nächste Etappe.
Prüfbefehl für die neuen Abläufe: `TEST_DATABASE_URL=postgresql://USER:PASSWORD@127.0.0.1:PORT/kita_quickwins_test npm run test:calendar:integration`. Er verlangt eine ausdrücklich benannte lokale Testdatenbank mit den vorhandenen Migrationen. Die 26 Fälle prüfen echte Server Actions und PostgreSQL; Mailtransport und Anmeldesession werden isoliert ersetzt. Die bestehenden Elternabläufe wurden ebenfalls mit 9 Integrationstests und 9 Berechnungstests geprüft.
Im Browser geprüft: eigener Beitrag speichern und abbrechen, Anzeige bei 390 Pixeln, fehlender Bearbeiten-Knopf bei fremden Beiträgen, Navigation ohne festen Zähler, Admin-Tauschanfrage mit eigenem Angebot sowie Anzeige und Annahme durch Koordination. E-Mails wurden dabei ausschließlich im Entwicklungsmodus simuliert.
Abnahme dieser Etappe: 26 neue Integrationstests, 18 bestehende Elternablauftests und 28 Sicherheitstests erfolgreich (72 insgesamt, keine übersprungenen Tests). TypeScript und Produktionsbuild erfolgreich; projektweites ESLint ohne Fehler mit acht bestehenden Warnungen.
## Ergänzung vom 12.10.2026: Verlässliche Notdienst-Planungsregeln
- Das Verfügbarkeitssoll wird aus allen aktiven Kindern des angemeldeten Haushalts berechnet. Ausgelassene, doppelte, fremde oder inaktive Kinder werden zurückgewiesen; doppelte Datumsangaben zählen nur einmal.
- Oberfläche, Speicherung, Generierung und manuelle Zuweisung verwenden gemeinsame Regeln: nur Werktage des Planungsmonats, ohne bestätigte Schließtage und Teamtage. Mehrtägige Termine schließen beide Randtage ein; Kalenderzeiten werden in `Europe/Berlin` ausgewertet. Ausstehende/abgelehnte Termine und Termine anderer Kitas blockieren nichts.
- Alte ungültige Verfügbarkeiten werden nicht für neue Pläne verwendet. Vor der Veröffentlichung werden Entwürfe auf zulässige Tage und aktive Kinder geprüft. Ungültige vorhandene Einteilungen bleiben sichtbar und können über „Manuell zuweisen“ entfernt werden; aktive Alarme und vergangene veröffentlichte Dienste behalten ihre Bearbeitungssperre.
- Kindlöschung im Elternprofil und in der Familienverwaltung ist bei heutigen/zukünftigen veröffentlichten Notdiensten oder aktiven Alarmen gesperrt. Zuerst muss die Koordination die Einteilung klären. Prüfung und Löschung laufen in derselben serialisierbaren Transaktion mit einer Sperre der betroffenen Kinder.
- Kein Schema-Upgrade erforderlich. Automatische Erinnerungen und Benachrichtigungen bei Erstveröffentlichung sind weiterhin offen.
Prüfbefehle: `npm run test:notdienst` (Datumsregeln) und `TEST_DATABASE_URL=postgresql://USER:PASSWORD@127.0.0.1:PORT/kita_notdienst_test npm run test:notdienst:integration` (echte Server Actions und PostgreSQL). Der Integrationsbefehl verlangt ausdrücklich eine separate lokale Testdatenbank; fehlende Konfiguration führt zu einem Fehler. Zuvor die vorhandenen Migrationen auf dieser Testdatenbank anwenden.
Abnahme: 4 Datumstests, 34 PostgreSQL-Regressionstests und 28 bestehende Sicherheitstests erfolgreich. Im Browser geprüft: gesperrter Teamtag/Wochenende, Speicherung des vollständigen Haushaltssolls, Veröffentlichungssperre, Entfernen einer alten ungültigen Einteilung und gültige manuelle Zuweisung mit anschließender Veröffentlichung. TypeScript und Produktionsbuild erfolgreich; projektweites ESLint ohne Fehler mit acht bestehenden Warnungen.
## Ergänzung vom 09.10.2026: Notdienstalarm
Der Notdienstalarm ist inzwischen umgesetzt. Admins und Koordination alarmieren die eingeteilte Familie für einen ganzen Tag oder ein Zeitfenster. Persönliche Rückmeldelinks erzeugen eine gemeinsame Haushaltsantwort; Dashboard-Hinweise, eine 30-Minuten-Frist, Klärungsbedarf, verspätete Freigabe, telefonische Korrektur, Stornierung, Versandstatus und Hintergrundprüfung sind angebunden. Aktive Alarme sperren Planumzuordnung und Diensttausche. Siehe [NOTDIENSTALARM.md](NOTDIENSTALARM.md) für Bedienung und benötigte Hosting-Konfiguration.
Das Schema ergänzt einen gemeinsamen Alarmvorgang, einzelne Empfänger und Tokens, Hinweise, Mailaufträge und einen Verlauf. Die bisherigen `NotdienstAlert`-Datensätze bleiben erhalten. Ein aktiver Alarm reserviert seine Einteilung eindeutig; Transaktionen schützen konkurrierende Antworten und Planänderungen.
Der bestehende Docker-Start nutzt `prisma db push --skip-generate`. Für kontrollierte SQL-Upgrades liegt alternativ [deploy/sql/notdienstalarm.sql](../deploy/sql/notdienstalarm.sql) vor. Es setzt den vollständigen Personalbereich einschließlich seiner Mail-Erweiterung voraus, ist einmalig auszuführen und enthält keine Datenlöschung. Nicht zusätzlich ausführen, wenn `db push` diese Änderungen bereits angewandt hat. Datenbanksicherung und Prüfung des Ausgangsschemas gehören zum Deployment. Die Auswahl der SQL-Alternativen erklärt die [zentrale Deployment- und Mailanleitung](../deploy/DEPLOYMENT_UND_MAILVERSAND.md).
Aktuelle Releases verwenden versionierte Prisma-Migrationen über den separaten Initialisierungsdienst. Die Einrichtung beschreibt [deploy/README.md](../deploy/README.md); `prisma db push` und die historischen SQL-Upgrades sind kein aktueller Betriebsweg. Der bestehende Hintergrundjob übernimmt zusätzlich Verfügbarkeitserinnerungen und gespeicherte Veröffentlichungsmails.
Bisherige Einzelalarme werden beim Verwaltungsaufruf, Joblauf oder Aufruf eines alten Links in Gruppen pro Einteilung übernommen. Alte gültige Tokens bleiben nutzbar; Originalantworten bleiben gespeichert. Nur vollständig übereinstimmende gültige Antworten ergeben eine sichere gemeinsame Zusage. Widersprüche, fehlende/ungeklärte Empfänger oder doppelte Einzelalarme führen zu Klärungsbedarf. Bei doppelten Datensätzen eines Elternkontos wird ein Rückmeldetoken übernommen; die übrigen Originaldatensätze bleiben erhalten. Die Übernahme verschickt keine erneute Alarmanfrage.
@@ -60,12 +60,9 @@ Parallele Änderungen laufen in serialisierbaren Datenbanktransaktionen mit Wied
## Einführung und Schema
Das Projekt verwendet weiterhin seinen vorhandenen Ablauf mit `prisma db push`. Es gibt keine vollständige versionierte Prisma-Migrationshistorie. Die neuen Tabellen sind additiv; vorhandene Personen erhalten noch kein automatisch befülltes Beschäftigungsprofil.
Aktuelle Releases verwenden die versionierten Migrationen in `prisma/migrations` und einen separaten Initialisierungsdienst vor dem App-Start. Die [zentrale Betriebsanleitung](../deploy/README.md) beschreibt Installation, Updates, Baseline für bestehende Datenbanken und Runtime-Grants. `scripts/start-production.sh` startet die Anwendung; es verändert das Schema nicht. Kein `prisma db push` auf verwalteten Datenbanken verwenden.
- Lokal: Abhängigkeiten installieren, Prisma-Client generieren, Schema gegen eine dafür vorgesehene Datenbank anwenden, App starten und Profile einrichten.
- Im vorhandenen Docker-Ablauf erzeugt `npm run build:prod` den Client; `scripts/start-production.sh` wendet das Schema vor App-Start an.
- [Prüfbares SQL](../deploy/sql/personalbereich.sql) beschreibt dieselbe additive Änderung gegen den dokumentierten Ausgangsstand. Es ist einmalig und nicht idempotent. Entweder den vorhandenen Schemaabgleich **oder** dieses SQL verwenden; das SQL nicht nach bereits erfolgtem Schemaabgleich erneut ausführen.
- Ist der Personalbereich bereits auf Stand `043fed2` eingeführt, beschreibt [Personalbereich-E-Mail-SQL](../deploy/sql/personalbereich-email.sql) ausschließlich die zusätzlichen Mail-Tabellen und die Profileinstellung. Auch dieses Skript ist eine einmalige Alternative zum Schemaabgleich.
Die historischen SQL-Dateien [Personalbereich](../deploy/sql/personalbereich.sql) und [Personalbereich-E-Mails](../deploy/sql/personalbereich-email.sql) dokumentieren ihre damaligen Ausgangsstände. Sie sind kein aktueller Deployment-Schritt und dürfen nicht zusätzlich zu den versionierten Migrationen ausgeführt werden. Vorhandene Personen erhalten weiterhin erst durch Einrichtung ein Beschäftigungsprofil.
Die reale Projekt- und Produktionsdatenbank wurde bei dieser Umsetzung nicht verändert. Alle DB- und Browserprüfungen liefen mit synthetischen Daten in einer separaten lokalen PostgreSQL-Datenbank.
Das Projekt verwendet weiterhin `prisma db push`; es besitzt keine Prisma-Migrationshistorie. Der vorhandene Produktionsstart aktualisiert das Schema automatisch. Die neuen Pflichtfelder haben kompatible Defaults: bisherige Termine bleiben `CHILD`, bisherige Meldungen erhalten `ALLE`. Bestehende Kinderantworten werden nicht verändert.
Aktuelle Releases verwenden die versionierten Migrationen in `prisma/migrations`. Der separate Initialisierungsdienst wendet sie vor dem App-Start an und stellt die Runtime-Grants bereit. Einrichtung und Updates beschreibt [deploy/README.md](../deploy/README.md). Kein `prisma db push` auf verwalteten Datenbanken einsetzen: zusätzliche Tenant-Constraints ergänzen das Prisma-Modell.
Für eine kontrollierte, einmalige Aktualisierung einer Datenbank mit dem bisherigen Schema liegt zusätzlich die additive SQL-Datei `prisma/updates/20261007_parent_flows.sql` vor. Sie ist eine Alternative zum ersten `db push`, kein nachträglich anzuwendender zweiter Schritt. Beispiel:
Die Datei gehört bewusst nicht in `prisma/migrations`: Eine Einführung von `prisma migrate deploy` würde zuerst eine Baseline für bereits existierende Datenbanken verlangen.
`prisma/updates/20261007_parent_flows.sql` dokumentiert den historischen Ausgangsstand vor Einführung der Migrationshistorie. Es gehört nicht zum aktuellen Deployment und darf nicht zusätzlich zu bereits angewandten Migrationen ausgeführt werden. Die kompatiblen Defaults für bisherige Termine (`CHILD`) und Meldungen (`ALLE`) sind in den versionierten Migrationen enthalten.
## Verifikation
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
t.indorf