diff --git a/Dockerfile b/Dockerfile index 37a8da4..8129dcf 100644 --- a/Dockerfile +++ b/Dockerfile @@ -46,4 +46,4 @@ COPY --from=builder --chown=app:app /app/public ./public RUN mkdir -p /app/uploads/announcements/announcements /app/.next/cache && chown -R app:app /app/uploads /app/.next/cache USER app EXPOSE 3000 -CMD ["node", "server.js"] +CMD ["sh", "scripts/start-production.sh"] diff --git a/deploy/DEPLOYMENT_UND_MAILVERSAND.md b/deploy/DEPLOYMENT_UND_MAILVERSAND.md new file mode 100644 index 0000000..4dacccc --- /dev/null +++ b/deploy/DEPLOYMENT_UND_MAILVERSAND.md @@ -0,0 +1,7 @@ +# Deployment und Mailversand + +Die aktuelle Anleitung steht in [README.md](README.md), die Konfigurationsvorlage in [production.env.example](production.env.example). + +Der Compose-Dienst `migrate` initialisiert das Schema über versionierte Migrationen und stellt den separaten Runtime-Zugang bereit. Die App startet erst nach erfolgreicher Initialisierung. `prisma db push`, Demo-Seeding und historische SQL-Upgrades sind im Produktionsstart nicht vorgesehen. + +Für Resend müssen Versanddomain, `RESEND_API_KEY` und `EMAIL_FROM` gültig konfiguriert sein. `ADMIN_EMAIL` ist das Ziel für das Kontaktformular. Die drei öffentlichen Basis-URLs müssen übereinstimmen, damit Einladungs- und Bestätigungslinks auf die richtige Anwendung zeigen. Der Notdienst-Worker startet im App-Container mit `NOTDIENST_JOB_SECRET`; kein zusätzlicher Cron-Dienst ist erforderlich. diff --git a/deploy/README.md b/deploy/README.md index 827c526..a236d31 100644 --- a/deploy/README.md +++ b/deploy/README.md @@ -4,12 +4,18 @@ Die Anwendung startet ohne Schemaänderungen und ohne Demo-Seeding. Datenbankmig ## Konfiguration -Werte aus `production.env.example` als Hosting-Secrets hinterlegen. `APP_DATABASE_URL` enthält die eingeschränkte Rolle; `MIGRATION_DATABASE_URL` den Datenbankeigentümer. Für lokale CLI-Befehle heißt die jeweils benötigte URL `DATABASE_URL`. `APP_DATABASE_PASSWORD` ist das separate Runtime-Passwort (24–256 Zeichen); in URLs muss es URL-kodiert werden. Keine echten Secrets im Repository speichern. +Werte aus `production.env.example` als Hosting-Secrets hinterlegen. Im Compose-Stack erzeugt der Dienst `migrate` automatisch ein separates Runtime-Passwort im privaten Secret-Volume, wendet die Migrationen an, vergibt die eingeschränkten DB-Rechte und bereitet die Upload-/Cache-Volumes vor. Danach startet `app` mit UID/GID 1001. Das Eigentümerpasswort steht nur PostgreSQL und dem Initialisierungsdienst zur Verfügung. Für manuelle CLI-Befehle außerhalb von Compose bleibt `DATABASE_URL` die jeweilige administrative oder eingeschränkte URL. Keine echten Secrets im Repository speichern. `AUTH_URL`, `NEXTAUTH_URL` und `NEXT_PUBLIC_SITE_URL` müssen dieselbe kanonische HTTPS-Origin verwenden. Der Reverse Proxy terminiert TLS, routet intern auf App-Port 3000 und überschreibt weitergeleitete Host-/IP-Header. `TRUSTED_CLIENT_IP_HEADER` nur setzen, wenn der Proxy den gewählten Header (`x-real-ip` oder `cf-connecting-ip`) zuverlässig überschreibt. Ohne diese Einstellung gelten weiterhin gemeinsame globale und identitätsbezogene Datenbanklimits. Proxyseitig Body-Limit von höchstens 26 MiB, Timeouts und zusätzliche Request-Limits setzen. Compose startet PostgreSQL standardmäßig intern. Bei einer bereits extern verwalteten Coolify-Datenbank den Stack entsprechend anpassen und deren interne URL verwenden; niemals versehentlich einen neuen leeren Datenbankdienst als Ersatz anschließen. pgAdmin ist nur im Profil `maintenance` und nur auf Loopback verfügbar; Zugriff über SSH-Tunnel. +## Neustart mit leerer Datenbank + +Wenn vorhandene Daten ausdrücklich löschbare Testdaten sind: ausschließlich die zu dieser Installation gehörenden Datenbank- und Upload-Volumes zurücksetzen. Danach genügt ein normales Deployment mit `docker compose -f docker-compose.coolify.yml up -d --build app`. Es sind weder eine Baseline-Markierung noch manuelle Schema-Upgrades oder Demo-Seeding erforderlich. Der Initialisierungsdienst läuft vor der App; ein Fehler verhindert deren Start. Bestehende produktive Daten erfordern dagegen die unten beschriebene Vorbereitung. + +Im Normalbetrieb bleiben Datenbank, Uploads, Cache und Runtime-Secret-Volume bei Deployments bestehen. Das Runtime-Passwort wird bei einem normalen Neustart wiederverwendet. Niemals die Datenbank als Startnebenwirkung löschen. + ## Bestehende Installation aktualisieren 1. Datenbank **und** Upload-Volume sichern und Wiederherstellung überprüfen. Wartungsfenster ankündigen und alte App stoppen: das neue Schema und der neue Code gehören zusammen. @@ -24,24 +30,20 @@ Compose-Beispiele (Environment-Secrets vorher bereitstellen): ```sh docker compose -f docker-compose.coolify.yml build app migrate # NUR bei bestehender, zuvor geprüfter Baseline-Datenbank: -docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate npx prisma migrate resolve --applied 20261009000000_baseline -# Bei neuen und bestehenden Datenbanken: -docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate npm run db:migrate:deploy -docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate npm run db:provision-runtime -docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate npm run uploads:backfill -# Nur auf dem vorgesehenen App-Upload-Volume: -docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate chown -R 1001:1001 /app/uploads -# Falls ein bereits vorhandenes Cache-Volume root gehört: dessen Eigentümer separat korrigieren. +docker compose -f docker-compose.coolify.yml run --rm migrate npx prisma migrate resolve --applied 20261009000000_baseline +# Initialisierung läuft automatisch vor der App: docker compose -f docker-compose.coolify.yml up -d app ``` +Die Baseline-Markierung benötigt bei einem manuellen Aufruf eine administrative `DATABASE_URL`; für eine leere Datenbank entfällt sie vollständig. Vorhandene Uploads müssen vor dem Start kontrolliert und ihre Größen unter administrativem Zugang nachgetragen werden. Für bestehende root-eigene Unterverzeichnisse ist eine gezielte Eigentümerkorrektur nötig; die Initialisierung bereitet die Basisverzeichnisse vor. + Bei einem Rollback nach Migration zuerst Kompatibilität prüfen; das alte Image allein zurückzusetzen reicht wegen neuer Pflichtfelder nicht aus. Im Zweifel das geprüfte Backup von Datenbank und Dateien gemeinsam wiederherstellen. ## Auswirkungen auf bestehende Konten Alle JWT-Sitzungen vor diesem Release werden ungültig; erneute Anmeldung ist erforderlich. Administrative Sperren entwerten auch bei späterer Entsperrung dauerhaft die alten Sitzungen. Gründerkonten ohne Kita und ohne echte E-Mail-Prüfung registrieren sich mit derselben Adresse erneut und bestätigen den Link. Bereits bestehende Kita-Gründer behalten ihre bisherige Verifizierung; deren historische Adressen werden dadurch nicht nachträglich als echte Mailbox-Bestätigung nachgewiesen. -Neue Registrierungen bestätigen zuerst die E-Mail-Adresse, wählen anschließend ihr Passwort und erstellen erst danach eine Kita. Beim Ändern einer Elternadresse werden Passwort und bisherige Sitzungen entwertet; die neue Adresse erhält eine Einladung zum Festlegen eines neuen Passworts. Kita-Admins können die Einladung erneut senden. Neue Registrierungslinks gelten 30 Minuten, Einladungen sieben Tage und Notdienst-Bestätigungslinks höchstens 24 Stunden sowie nur für offene, noch relevante Einsätze. Bestehende UUID-Links bleiben innerhalb ihrer Laufzeit kompatibel. Zwei-Faktor-Anmeldung ist auf ausdrücklichen Wunsch vorerst nicht eingeführt. +Neue Registrierungen bestätigen zuerst die E-Mail-Adresse, wählen anschließend ihr Passwort und erstellen erst danach eine Kita. Beim Ändern einer Elternadresse werden Passwort und bisherige Sitzungen entwertet; die neue Adresse erhält eine Einladung zum Festlegen eines neuen Passworts. Kita-Admins können die Einladung erneut senden. Neue Registrierungslinks gelten 30 Minuten, Einladungen sieben Tage und Notdienst-Rückmeldelinks bis zum Ende des jeweiligen Einsatzes; eine gemeinsame Haushaltsantwort kann nur einmal gespeichert werden. Sperren entwerten vorhandene Rückmeldelinks dauerhaft. Die öffentlichen Token-Antworten zeigen nur die benötigten Einsatzangaben. Bestehende UUID-Links bleiben innerhalb ihrer Laufzeit kompatibel. Zwei-Faktor-Anmeldung ist auf ausdrücklichen Wunsch vorerst nicht eingeführt. ## Dateien und Wartung @@ -51,7 +53,7 @@ Grenzen: 10 MiB pro Datei, fünf Dateien und 25 MiB pro Nachricht; standardmäß `npm run uploads:cleanup` zeigt zunächst nur verwaiste Dateien mit mindestens 24 Stunden Alter. Nach Prüfung entfernt `npm run uploads:cleanup -- --delete` diese Dateien. Backups, Speicherüberwachung und eine Aufbewahrungs-/Löschstrategie für Backups separat einrichten. Dateien gelöschter Datensätze werden auch unmittelbar bestmöglich entfernt. -Die SQL-Migrationen ergänzen **31 zusammengesetzte Tenant-Fremdschlüssel**, die Prisma wegen der vorhandenen optionalen Cascade-/SetNull-Beziehungen nicht vollständig abbildet. Zukünftige generierte Migrationen auf unbeabsichtigtes Entfernen dieser Constraints prüfen. Kein `prisma db push` auf verwalteten Datenbanken einsetzen. Runtime-Grants nach zukünftigen Migrationen erneut bereitstellen. +Die SQL-Migrationen ergänzen **41 zusammengesetzte Tenant-Fremdschlüssel**, die Prisma wegen der vorhandenen optionalen Cascade-/SetNull-Beziehungen nicht vollständig abbildet. Zukünftige generierte Migrationen auf unbeabsichtigtes Entfernen dieser Constraints prüfen. Kein `prisma db push` auf verwalteten Datenbanken einsetzen. Runtime-Grants nach zukünftigen Migrationen erneut bereitstellen. ## Verifikation und Updates diff --git a/deploy/production-checklist.md b/deploy/production-checklist.md index b0de402..2929704 100644 --- a/deploy/production-checklist.md +++ b/deploy/production-checklist.md @@ -1,12 +1,14 @@ # Production-Checkliste -## Vor dem Rollout +## Vor dem Rollout mit bestehenden Daten + +Bei einem ausdrücklich genehmigten Reset löschbarer Testdaten entfallen Backup-Übernahme, Baseline-Markierung und Upload-Backfill. Nach dem gezielten Reset initialisiert das normale Deployment den leeren Stand. - [ ] Datenbank und Uploads gesichert; Wiederherstellung geprüft. - [ ] Alte App gestoppt; Wartungsfenster und erneute Anmeldung angekündigt. - [ ] Bestehendes Schema mit Baseline verglichen; Tenant-Preflight ohne Befunde. - [ ] Baseline nur bei bestehender passender DB markiert; anschließend alle Migrationen angewendet. -- [ ] Runtime-Rolle mit separatem Passwort bereitgestellt; App verwendet `APP_DATABASE_URL`. +- [ ] Initialisierungsdienst erfolgreich; App verwendet automatisch die eingeschränkte Runtime-Rolle. - [ ] Upload-Größen nachgetragen; gemeldete fehlende Dateien geprüft. - [ ] Upload- und Cache-Volumes für UID/GID 1001 beschreibbar; Upload-Pfad unverändert. diff --git a/deploy/production.env.example b/deploy/production.env.example index 092491c..029f47f 100644 --- a/deploy/production.env.example +++ b/deploy/production.env.example @@ -11,10 +11,9 @@ POSTGRES_DB="kita_planer" POSTGRES_USER="kita_planer" POSTGRES_PASSWORD="[GENERATE_ME]" -# Unterschiedliche DB-Rollen für Runtime und Migration. URL-Passwörter müssen URL-kodiert sein. -APP_DATABASE_PASSWORD="[GENERATE_ME]" -APP_DATABASE_URL="postgresql://kita_runtime:[URL_ENCODED_APP_PASSWORD]@postgres:5432/kita_planer?schema=public" -MIGRATION_DATABASE_URL="postgresql://kita_planer:[URL_ENCODED_OWNER_PASSWORD]@postgres:5432/kita_planer?schema=public" +# Der Initialisierungsdienst erzeugt automatisch einen separaten Runtime-Zugang. +# Keine zusätzlichen APP_DATABASE_URL-/Passwort-Secrets nötig. +# Passwort wird nur im privaten kita_planer_runtime_secrets-Volume gespeichert. # pgAdmin im Coolify-Compose-Stack PGADMIN_DEFAULT_EMAIL="[admin@deine-domain.de]" @@ -41,6 +40,10 @@ RESEND_API_KEY="re_[PRODUCTION_API_KEY]" EMAIL_FROM="Kita-Planer <[absender@deine-domain.de]>" ADMIN_EMAIL="[kontakt@deine-domain.de]" +# Automatische Notdienst-Fristpruefung im App-Container. +# Eigenes Secret, mindestens 32 Zeichen; generieren mit: openssl rand -hex 32 +NOTDIENST_JOB_SECRET="[GENERATE_ME]" + # Persistenter Upload-Speicher fuer Anhaenge vom Schwarzen Brett. # Muss auf dem Server dauerhaft erhalten bleiben und darf nicht im Repo liegen. UPLOAD_DIR="/var/lib/kita-planer/uploads/announcements" diff --git a/deploy/sql/notdienstalarm.sql b/deploy/sql/notdienstalarm.sql new file mode 100644 index 0000000..e435689 --- /dev/null +++ b/deploy/sql/notdienstalarm.sql @@ -0,0 +1,160 @@ +-- Additives Upgrade für einen Personalbereich einschließlich vorhandener Mail-Erweiterung. +-- Einmalig vor dem Start der neuen Anwendung ausführen, sofern nicht prisma db push verwendet wird. +BEGIN; + +-- CreateEnum +CREATE TYPE "NotdienstAlarmStatus" AS ENUM ('PENDING', 'CONFIRMED', 'DECLINED', 'LATE_CONFIRMATION', 'REVIEW_REQUIRED', 'CANCELLED'); + +-- AlterTable +ALTER TABLE "notdienst_alerts" ADD COLUMN "alarmId" TEXT; + +-- CreateTable +CREATE TABLE "notdienst_alarms" ( + "id" TEXT NOT NULL, + "kitaId" TEXT NOT NULL, + "assignmentId" TEXT, + "activeAssignmentId" TEXT, + "familyId" TEXT NOT NULL, + "familyName" TEXT NOT NULL, + "childName" TEXT NOT NULL, + "date" DATE NOT NULL, + "wholeDay" BOOLEAN NOT NULL DEFAULT true, + "startMinute" INTEGER, + "endMinute" INTEGER, + "expiresAt" TIMESTAMP(3) NOT NULL, + "deadline" TIMESTAMP(3) NOT NULL, + "status" "NotdienstAlarmStatus" NOT NULL DEFAULT 'PENDING', + "triggeredById" TEXT, + "triggeredAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "respondedById" TEXT, + "respondedAt" TIMESTAMP(3), + "responseSource" TEXT, + "escalatedAt" TIMESTAMP(3), + "educatorId" TEXT, + "notes" TEXT, + "cancelledAt" TIMESTAMP(3), + "cancelReason" TEXT, + + CONSTRAINT "notdienst_alarms_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarm_recipients" ( + "id" TEXT NOT NULL, + "alarmId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "token" TEXT NOT NULL, + + CONSTRAINT "notdienst_alarm_recipients_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarm_notifications" ( + "id" TEXT NOT NULL, + "alarmId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "eventKey" TEXT NOT NULL, + "message" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "readAt" TIMESTAMP(3), + + CONSTRAINT "notdienst_alarm_notifications_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarm_emails" ( + "id" TEXT NOT NULL, + "alarmId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "eventKey" TEXT NOT NULL, + "kind" TEXT NOT NULL, + "subject" TEXT NOT NULL, + "message" TEXT NOT NULL, + "path" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "sentAt" TIMESTAMP(3), + "skippedAt" TIMESTAMP(3), + "leaseUntil" TIMESTAMP(3), + "failed" BOOLEAN NOT NULL DEFAULT false, + "attempts" INTEGER NOT NULL DEFAULT 0, + + CONSTRAINT "notdienst_alarm_emails_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarm_history" ( + "id" TEXT NOT NULL, + "alarmId" TEXT NOT NULL, + "actorId" TEXT, + "action" TEXT NOT NULL, + "details" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "notdienst_alarm_history_pkey" PRIMARY KEY ("id") +); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarms_activeAssignmentId_key" ON "notdienst_alarms"("activeAssignmentId"); + +-- CreateIndex +CREATE INDEX "notdienst_alarms_kitaId_date_idx" ON "notdienst_alarms"("kitaId", "date"); + +-- CreateIndex +CREATE INDEX "notdienst_alarms_status_deadline_idx" ON "notdienst_alarms"("status", "deadline"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarm_recipients_token_key" ON "notdienst_alarm_recipients"("token"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarm_recipients_alarmId_userId_key" ON "notdienst_alarm_recipients"("alarmId", "userId"); + +-- CreateIndex +CREATE INDEX "notdienst_alarm_notifications_userId_readAt_idx" ON "notdienst_alarm_notifications"("userId", "readAt"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarm_notifications_alarmId_userId_eventKey_key" ON "notdienst_alarm_notifications"("alarmId", "userId", "eventKey"); + +-- CreateIndex +CREATE INDEX "notdienst_alarm_emails_sentAt_skippedAt_createdAt_idx" ON "notdienst_alarm_emails"("sentAt", "skippedAt", "createdAt"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarm_emails_alarmId_userId_eventKey_key" ON "notdienst_alarm_emails"("alarmId", "userId", "eventKey"); + +-- CreateIndex +CREATE INDEX "notdienst_alarm_history_alarmId_createdAt_idx" ON "notdienst_alarm_history"("alarmId", "createdAt"); + +-- AddForeignKey +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_kitaId_fkey" FOREIGN KEY ("kitaId") REFERENCES "kitas"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_assignmentId_fkey" FOREIGN KEY ("assignmentId") REFERENCES "notdienst_assignments"("id") ON DELETE SET NULL ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_familyId_fkey" FOREIGN KEY ("familyId") REFERENCES "families"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_recipients" ADD CONSTRAINT "notdienst_alarm_recipients_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_recipients" ADD CONSTRAINT "notdienst_alarm_recipients_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_notifications" ADD CONSTRAINT "notdienst_alarm_notifications_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_notifications" ADD CONSTRAINT "notdienst_alarm_notifications_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_emails" ADD CONSTRAINT "notdienst_alarm_emails_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_emails" ADD CONSTRAINT "notdienst_alarm_emails_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_history" ADD CONSTRAINT "notdienst_alarm_history_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alerts" ADD CONSTRAINT "notdienst_alerts_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE SET NULL ON UPDATE CASCADE; + + +COMMIT; diff --git a/deploy/sql/personalbereich-email.sql b/deploy/sql/personalbereich-email.sql new file mode 100644 index 0000000..99b96ab --- /dev/null +++ b/deploy/sql/personalbereich-email.sql @@ -0,0 +1,37 @@ +-- Nur E-Mail-Erweiterung für einen bereits mit 043fed2 eingeführten Personalbereich. +-- Alternative zu prisma db push, nicht zusätzlich oder mehrfach ausführen. +BEGIN; + +-- AlterTable +ALTER TABLE "users" ADD COLUMN "staffDecisionEmails" BOOLEAN NOT NULL DEFAULT true; + +-- CreateTable +CREATE TABLE "staff_emails" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "toAdmins" BOOLEAN NOT NULL DEFAULT false, + "subject" TEXT NOT NULL, + "message" TEXT NOT NULL, + "path" TEXT NOT NULL, + "inviteToken" TEXT, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "sentAt" TIMESTAMP(3), + "skippedAt" TIMESTAMP(3), + "leaseUntil" TIMESTAMP(3), + "attempts" INTEGER NOT NULL DEFAULT 0, + "failed" BOOLEAN NOT NULL DEFAULT false, + + CONSTRAINT "staff_emails_pkey" PRIMARY KEY ("id") +); + +-- CreateIndex +CREATE INDEX "staff_emails_profileId_sentAt_skippedAt_idx" ON "staff_emails"("profileId", "sentAt", "skippedAt"); + +-- AddForeignKey +ALTER TABLE "staff_emails" ADD CONSTRAINT "staff_emails_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_emails" ADD CONSTRAINT "staff_emails_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +COMMIT; diff --git a/deploy/sql/personalbereich.sql b/deploy/sql/personalbereich.sql new file mode 100644 index 0000000..dd7ac0f --- /dev/null +++ b/deploy/sql/personalbereich.sql @@ -0,0 +1,286 @@ +-- Einmalige Einführung des vollständigen Personalbereichs inklusive E-Mails ab ec3f4f9. +-- Alternative zu prisma db push, nicht zusätzlich oder mehrfach ausführen. +BEGIN; + +-- CreateEnum +CREATE TYPE "StaffRequestStatus" AS ENUM ('PENDING', 'APPROVED', 'REJECTED', 'CANCEL_REQUESTED', 'CANCELLED'); + +-- CreateEnum +CREATE TYPE "StaffLeaveKind" AS ENUM ('VACATION', 'TIME_OFF', 'SICKNESS'); + +-- CreateEnum +CREATE TYPE "StaffWeekStatus" AS ENUM ('DRAFT', 'SUBMITTED', 'APPROVED'); + +-- AlterTable +ALTER TABLE "users" ADD COLUMN "staffDecisionEmails" BOOLEAN NOT NULL DEFAULT true; + +-- CreateTable +CREATE TABLE "staff_profiles" ( + "id" TEXT NOT NULL, + "kitaId" TEXT NOT NULL, + "educatorId" TEXT NOT NULL, + "userId" TEXT, + "employmentStart" DATE NOT NULL, + "employmentEnd" DATE, + "trackingStart" DATE NOT NULL, + "openingMinutes" INTEGER NOT NULL DEFAULT 0, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_profiles_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_emails" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "toAdmins" BOOLEAN NOT NULL DEFAULT false, + "subject" TEXT NOT NULL, + "message" TEXT NOT NULL, + "path" TEXT NOT NULL, + "inviteToken" TEXT, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "sentAt" TIMESTAMP(3), + "skippedAt" TIMESTAMP(3), + "leaseUntil" TIMESTAMP(3), + "attempts" INTEGER NOT NULL DEFAULT 0, + "failed" BOOLEAN NOT NULL DEFAULT false, + + CONSTRAINT "staff_emails_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_work_patterns" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "effectiveFrom" DATE NOT NULL, + "dailyMinutes" INTEGER[], + + CONSTRAINT "staff_work_patterns_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_day_overrides" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "date" DATE NOT NULL, + "minutes" INTEGER NOT NULL, + "reason" TEXT NOT NULL, + + CONSTRAINT "staff_day_overrides_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_holidays" ( + "id" TEXT NOT NULL, + "kitaId" TEXT NOT NULL, + "date" DATE NOT NULL, + "name" TEXT NOT NULL, + + CONSTRAINT "staff_holidays_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_leave_accounts" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "year" INTEGER NOT NULL, + "entitlementUnits" INTEGER NOT NULL, + "carryUnits" INTEGER NOT NULL DEFAULT 0, + + CONSTRAINT "staff_leave_accounts_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_leaves" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "kind" "StaffLeaveKind" NOT NULL, + "status" "StaffRequestStatus" NOT NULL DEFAULT 'PENDING', + "startDate" DATE NOT NULL, + "endDate" DATE NOT NULL, + "halfDay" BOOLEAN NOT NULL DEFAULT false, + "minutes" INTEGER, + "note" TEXT, + "decisionNote" TEXT, + "requestedById" TEXT NOT NULL, + "reviewedById" TEXT, + "reviewedAt" TIMESTAMP(3), + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_leaves_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_leave_days" ( + "id" TEXT NOT NULL, + "leaveId" TEXT NOT NULL, + "date" DATE NOT NULL, + "vacationUnits" INTEGER NOT NULL DEFAULT 0, + "creditMinutes" INTEGER NOT NULL, + + CONSTRAINT "staff_leave_days_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_time_entries" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "date" DATE NOT NULL, + "startMinute" INTEGER NOT NULL, + "endMinute" INTEGER NOT NULL, + "breakMinutes" INTEGER NOT NULL DEFAULT 0, + "note" TEXT, + + CONSTRAINT "staff_time_entries_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_weeks" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "weekStart" DATE NOT NULL, + "status" "StaffWeekStatus" NOT NULL DEFAULT 'DRAFT', + "submittedAt" TIMESTAMP(3), + "reviewedAt" TIMESTAMP(3), + "reviewedById" TEXT, + "decisionNote" TEXT, + "dailySnapshot" JSONB, + + CONSTRAINT "staff_weeks_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_adjustments" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "date" DATE NOT NULL, + "minutes" INTEGER NOT NULL, + "reason" TEXT NOT NULL, + "actorId" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_adjustments_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_history" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "actorId" TEXT NOT NULL, + "action" TEXT NOT NULL, + "details" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_history_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_notifications" ( + "id" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "message" TEXT NOT NULL, + "readAt" TIMESTAMP(3), + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_notifications_pkey" PRIMARY KEY ("id") +); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_profiles_educatorId_key" ON "staff_profiles"("educatorId"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_profiles_userId_key" ON "staff_profiles"("userId"); + +-- CreateIndex +CREATE INDEX "staff_profiles_kitaId_idx" ON "staff_profiles"("kitaId"); + +-- CreateIndex +CREATE INDEX "staff_emails_profileId_sentAt_skippedAt_idx" ON "staff_emails"("profileId", "sentAt", "skippedAt"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_work_patterns_profileId_effectiveFrom_key" ON "staff_work_patterns"("profileId", "effectiveFrom"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_day_overrides_profileId_date_key" ON "staff_day_overrides"("profileId", "date"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_holidays_kitaId_date_key" ON "staff_holidays"("kitaId", "date"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_leave_accounts_profileId_year_key" ON "staff_leave_accounts"("profileId", "year"); + +-- CreateIndex +CREATE INDEX "staff_leaves_profileId_status_startDate_idx" ON "staff_leaves"("profileId", "status", "startDate"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_leave_days_leaveId_date_key" ON "staff_leave_days"("leaveId", "date"); + +-- CreateIndex +CREATE INDEX "staff_time_entries_profileId_date_idx" ON "staff_time_entries"("profileId", "date"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_weeks_profileId_weekStart_key" ON "staff_weeks"("profileId", "weekStart"); + +-- CreateIndex +CREATE INDEX "staff_adjustments_profileId_date_idx" ON "staff_adjustments"("profileId", "date"); + +-- CreateIndex +CREATE INDEX "staff_history_profileId_createdAt_idx" ON "staff_history"("profileId", "createdAt"); + +-- CreateIndex +CREATE INDEX "staff_notifications_userId_readAt_createdAt_idx" ON "staff_notifications"("userId", "readAt", "createdAt"); + +-- AddForeignKey +ALTER TABLE "staff_profiles" ADD CONSTRAINT "staff_profiles_kitaId_fkey" FOREIGN KEY ("kitaId") REFERENCES "kitas"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_profiles" ADD CONSTRAINT "staff_profiles_educatorId_fkey" FOREIGN KEY ("educatorId") REFERENCES "educators"("id") ON DELETE NO ACTION ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_profiles" ADD CONSTRAINT "staff_profiles_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE SET NULL ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_emails" ADD CONSTRAINT "staff_emails_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_emails" ADD CONSTRAINT "staff_emails_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_work_patterns" ADD CONSTRAINT "staff_work_patterns_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_day_overrides" ADD CONSTRAINT "staff_day_overrides_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_holidays" ADD CONSTRAINT "staff_holidays_kitaId_fkey" FOREIGN KEY ("kitaId") REFERENCES "kitas"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_leave_accounts" ADD CONSTRAINT "staff_leave_accounts_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_leaves" ADD CONSTRAINT "staff_leaves_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_leave_days" ADD CONSTRAINT "staff_leave_days_leaveId_fkey" FOREIGN KEY ("leaveId") REFERENCES "staff_leaves"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_time_entries" ADD CONSTRAINT "staff_time_entries_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_weeks" ADD CONSTRAINT "staff_weeks_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_adjustments" ADD CONSTRAINT "staff_adjustments_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_history" ADD CONSTRAINT "staff_history_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_notifications" ADD CONSTRAINT "staff_notifications_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_notifications" ADD CONSTRAINT "staff_notifications_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +COMMIT; diff --git a/docker-compose.coolify.yml b/docker-compose.coolify.yml index 0381c2b..cbced6b 100644 --- a/docker-compose.coolify.yml +++ b/docker-compose.coolify.yml @@ -27,7 +27,8 @@ services: NODE_ENV: production PORT: 3000 HOSTNAME: 0.0.0.0 - DATABASE_URL: ${APP_DATABASE_URL:?} + APP_DATABASE_PASSWORD_FILE: /app/runtime-secrets/database-password + APP_DATABASE_NAME: ${POSTGRES_DB:-kita_planer} AUTH_SECRET: ${AUTH_SECRET:?} AUTH_URL: ${AUTH_URL:?} NEXTAUTH_URL: ${NEXTAUTH_URL:?} @@ -38,6 +39,7 @@ services: RESEND_API_KEY: ${RESEND_API_KEY:?} EMAIL_FROM: ${EMAIL_FROM:?} ADMIN_EMAIL: ${ADMIN_EMAIL:?} + NOTDIENST_JOB_SECRET: ${NOTDIENST_JOB_SECRET:?} UPLOAD_DIR: /app/uploads/announcements UPLOAD_TENANT_QUOTA_BYTES: ${UPLOAD_TENANT_QUOTA_BYTES:-268435456} UPLOAD_GLOBAL_QUOTA_BYTES: ${UPLOAD_GLOBAL_QUOTA_BYTES:-10737418240} @@ -45,9 +47,12 @@ services: volumes: - kita_planer_uploads:/app/uploads - kita_planer_next_cache:/app/.next/cache + - kita_planer_runtime_secrets:/app/runtime-secrets:ro depends_on: postgres: condition: service_healthy + migrate: + condition: service_completed_successfully expose: - "3000" read_only: true @@ -63,7 +68,6 @@ services: restart: unless-stopped migrate: - profiles: ["maintenance"] build: context: . dockerfile: Dockerfile @@ -72,11 +76,16 @@ services: NEXT_PUBLIC_SITE_URL: ${NEXT_PUBLIC_SITE_URL:?} environment: NODE_ENV: production - DATABASE_URL: ${MIGRATION_DATABASE_URL:?} - APP_DATABASE_PASSWORD: ${APP_DATABASE_PASSWORD:?} + POSTGRES_DB: ${POSTGRES_DB:-kita_planer} + POSTGRES_USER: ${POSTGRES_USER:-kita_planer} + POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?} + APP_DATABASE_PASSWORD_FILE: /app/runtime-secrets/database-password UPLOAD_DIR: /app/uploads/announcements + command: ["node", "scripts/initialize-production.mjs"] volumes: - kita_planer_uploads:/app/uploads + - kita_planer_next_cache:/app/runtime-cache + - kita_planer_runtime_secrets:/app/runtime-secrets depends_on: postgres: condition: service_healthy @@ -103,4 +112,5 @@ volumes: kita_planer_postgres_data: kita_planer_uploads: kita_planer_next_cache: + kita_planer_runtime_secrets: kita_planer_pgadmin_data: diff --git a/docs/FUNKTIONSUEBERSICHT.md b/docs/FUNKTIONSUEBERSICHT.md new file mode 100644 index 0000000..bd2be46 --- /dev/null +++ b/docs/FUNKTIONSUEBERSICHT.md @@ -0,0 +1,448 @@ +# Kita-Planer – Funktionsübersicht und aktueller Stand + +## 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. + +Die folgende ursprüngliche Bestandsaufnahme bleibt als historischer Stand erhalten; darin als offen bezeichnete Alarmfunktionen sind durch diese Ergänzung überholt. + +Stand: **07.10.2026** + +Geprüfter Ausgangsbranch: `codex/notdienst-swaps` + +Geprüfter Commit: `ec3f4f933d42068c9d8446dc95de9815d5779238` + +Dokumentationsbranch: `codex/funktionsinventar` + +**Ergänzung vom 07.10.2026:** Auf `codex/personalbereich` wurde anschließend der Personalbereich für Arbeitszeit, Urlaub und Freizeitausgleich umgesetzt. Diese Bestandsaufnahme bleibt als Beschreibung des Ausgangsstands erhalten; der neue Umfang, Berechnungsregeln, Einrichtung und aktuelle Prüfungen stehen in [PERSONALBEREICH.md](PERSONALBEREICH.md). Die Aussagen unten zu fehlender Zeiterfassung, Accountverknüpfung und Tests beziehen sich auf den Ausgangscommit. + +**Ergänzung vom 08.10.2026:** Der Personalbereich enthält jetzt auch Aktivierungsmails, Antrags- und Entscheidungshinweise sowie eine Abschalteinstellung im Fachkraftprofil. Der aktuelle Umfang und die Versandkonfiguration stehen ebenfalls in [PERSONALBEREICH.md](PERSONALBEREICH.md). + +## 1. Grundlage der Prüfung + +Diese Bestandsaufnahme beschreibt die im Repository vorhandenen Produktfunktionen. Geprüft wurden Seiten und Navigation, Formulare und Dialoge, Server Actions, API-Routen, Datenmodell, E-Mail-Anbindung und Betriebsdateien. Die Planung in `planung.md`, die UI-Liste in `UI-TODO.md` und der frühere Live-Testplan wurden mit dem aktuellen Code abgeglichen. + +**„Vorhanden“ bedeutet hier: Oberfläche und zugehörige Verarbeitung sind im Code angebunden. Es bedeutet keine Bestätigung durch einen aktuellen Live-Test.** Es wurden keine Produktionsdaten verändert, keine E-Mails verschickt und keine Datenbankänderungen ausgeführt. Die tatsächliche Zustellung von E-Mails, das Verhalten im Browser und die produktive Konfiguration bleiben gesondert zu prüfen. + +Status: + +| Kennzeichnung | Bedeutung | +| --- | --- | +| Vorhanden | Im aktuellen Code als erreichbarer Ablauf umgesetzt. | +| Teilweise | Funktion vorhanden, aber mit konkreten Einschränkungen oder fehlender Anbindung. | +| Vorbereitet | Datenmodell, Komponente oder Aktion vorhanden; vollständiger Nutzerablauf fehlt. | +| Offen | In der Planung vorgesehen, im geprüften Code nicht umgesetzt. | + +## 2. Gesamtüberblick + +Die Anwendung besitzt bereits eine breite MVP-Grundlage für mehrere unabhängige Kitas: Registrierung, Einrichtung, Familien und Kinder, Notdienst-Verfügbarkeiten und Planung, Diensttausch, Kalender, Mitbringlisten, Abwesenheiten, Kontaktdaten und Superadmin-Support. Einige beworbene Abläufe sind jedoch noch nicht vollständig nutzbar, insbesondere Alarmierung, Eltern-Rückmeldungen zu Events und die Anzeige des Schwarzen Bretts für Eltern. + +| Bereich | Stand | Wichtigste Einschränkung | +| --- | --- | --- | +| Öffentliche Website und Kontakt | Vorhanden | Impressum und Datenschutz enthalten Platzhalter. | +| Registrierung, Login, Kita-Einrichtung | Vorhanden | Kein selbstständiger Passwort-Reset; Modulschalter wirken nur teilweise. | +| Dashboard | Vorhanden | News-, RSVP- und Alarm-Komponenten sind nicht eingebunden. | +| Profil und eigene Kinder | Vorhanden | Persönlicher Name, E-Mail und Rolle sind im Profil nur lesbar. | +| Familienverwaltung und feste Ämter | Vorhanden | Kein vollständiger Einladungs-Support mit erneutem Versand/Widerruf. | +| Notdienst-Verfügbarkeiten | Vorhanden | Wochenenden und Schließtage werden nur in der Oberfläche ausgeschlossen. | +| Notdienst-Planung | Vorhanden | Keine automatische Erinnerung und keine E-Mail bei Erstveröffentlichung. | +| Notdienst-Tausch | Vorhanden | Nur Elternrolle kann neue Tauschanfragen starten. | +| Notdienst-Alarmierung | Vorbereitet | Auslösebutton ist auf keiner Seite eingebunden. | +| Kalender und Mitbringlisten | Vorhanden | Keine Kollisionsprüfung für Raumbuchungen; Mitbringsel nicht direkt bearbeitbar. | +| Event-Teilnahme/RSVP | Teilweise | Verwaltung vorhanden, Eltern-Eingabe nicht in eine Seite eingebunden. | +| Abwesenheiten | Vorhanden | Gruppenfilter verwendet eine künstliche Zuordnung. | +| Schwarzes Brett | Teilweise | Veröffentlichung vorhanden, Elternanzeige und Lesestatus fehlen im aktuellen Dashboard. | +| Adressbuch | Vorhanden | Opt-in gilt für Kontaktdaten; weitere Haushaltsdaten bleiben sichtbar. | +| ErzieherInnen-Stammdaten | Vorhanden | Stammdatensatz und Benutzerrolle `ERZIEHER` sind getrennte Konzepte. | +| Superadmin-Verwaltung | Vorhanden | Einladungszähler verwenden ein anderes Modell als der reale Einladungsablauf. | +| Betrieb und Qualität | Teilweise | TypeScript erfolgreich, ESLint mit Fehlern; keine automatisierte Testsuite gefunden. | + +## 3. Rollen und Zugriffsbereiche + +| Rolle | Aktuelle Möglichkeiten | +| --- | --- | +| `SUPERADMIN` | Systemweite Kita-Übersicht, Kita-Diagnosen, Support-Aktionen und Audit-Protokoll. Standardmäßig ohne Kita-Zuordnung und mit eigener Oberfläche unter `/admin`. | +| `ADMIN` | Verwaltung der eigenen Kita: Familien, Ämter, ErzieherInnen, Dienste, Meldungen, Kalender und Notdienst. Mit eigenem Haushalt auch Elternfunktionen nutzbar. | +| `KOORDINATOR` | Notdienstplanung, Kalenderverwaltung, Event-Anmeldungen und Abwesenheitsübersicht. Mit eigenem Haushalt auch Verfügbarkeiten eintragbar. | +| `ERZIEHER` | Dashboard, Kalender, Adressbuch, Profil und Abwesenheitsübersicht. Kein Zugriff auf die Notdienst-Eingabeseite. | +| `ELTERN` | Eigener Haushalt/Kinder, Verfügbarkeiten, Kalender, Terminanfragen, Mitbringsel, Diensttausch, Abwesenheitsmeldungen und Adressbuch. | + +Navigation und serverseitige Rollenprüfungen sind vorhanden. Die Rolle `ERZIEHER` existiert im Datenmodell und wird in Berechtigungen verwendet. Die ErzieherInnen-Verwaltung erstellt jedoch nur Namen als Stammdaten und keine Benutzerkonten. Ein regulärer Dialog zur Einladung von Erzieher-Accounts oder zur Vergabe von Admin-/Koordinatorrollen wurde nicht gefunden. + +Quellen: [Navigation](../src/components/dashboard/sidebar-nav.tsx), [Zugriffsprüfungen](../src/lib/auth-utils.ts), [Datenmodell](../prisma/schema.prisma). + +## 4. Funktionsinventar nach Bereich + +### 4.1 Öffentliche Website und Kontakt + +- Startseite mit Produktbeschreibung, Funktionsvorschauen, Rollenbeschreibung, Einstieg in Registrierung und Login sowie Kontaktbereich. +- Fünf öffentliche Detailseiten: Notdienst-Planer, Kita-Kalender, Eltern-Adressbuch, Krankmeldung und Schwarzes Brett. +- Kontaktformular für allgemeine Fragen, Demo-Anfragen und individuelles Setup. +- Eingaben: Name, optionale Kita, E-Mail-Adresse, Anfrageart und Nachricht. +- Versand einer Anfrage an den konfigurierten Kontakt-Empfänger und einer Bestätigung an die anfragende Person; passende Antwortadressen werden gesetzt. +- Bot-Schutz durch ein unsichtbares Zusatzfeld und ein Limit von fünf Kontaktanfragen je IP-Adresse pro Stunde. Das Limit liegt im Arbeitsspeicher des jeweiligen Prozesses. +- Sitemap, Robots-Datei und Metadaten für öffentliche Seiten. +- Optionales Umami-Tracking über Umgebungsvariablen, auf eine Liste öffentlicher Seiten beschränkt. Suchparameter und URL-Fragmente werden ausgeschlossen; Do-Not-Track wird berücksichtigt. +- Impressum und Datenschutzerklärung sind als Seiten vorhanden, enthalten aber noch Betreiber-, Hosting- und weitere Platzhalter. + +Quellen: [Startseite](../src/app/page.tsx), [Feature-Inhalte](../src/lib/marketing/features.ts), [Kontaktaktion](../src/actions/contact.ts), [Analytics](../src/components/analytics/umami-analytics.tsx), [Impressum](../src/app/impressum/page.tsx), [Datenschutz](../src/app/datenschutz/page.tsx). + +### 4.2 Registrierung, Anmeldung und Einrichtung + +- Gründerregistrierung mit Vorname, Nachname, E-Mail-Adresse, Passwort und verpflichtender Datenschutzannahme. +- Prüfung auf bereits verwendete E-Mail-Adressen und Passwort-Hashing mit bcrypt. +- Gründer erhält zunächst die Adminrolle ohne Kita-Zuordnung und wird direkt angemeldet. +- Kita-Einrichtung mit Name, eindeutigem Slug, Aktivierung von Notdienst/Kalender/Adressbuch und Mindestzahl an Verfügbarkeiten pro Kind. +- Bei aktivem Notdienstmodul ist mindestens ein Verfügbarkeitstag erforderlich; die Einrichtung erlaubt höchstens 31. +- Kita-Anlage und Zuordnung des Gründers erfolgen in einer Datenbanktransaktion; erneute Einrichtung desselben Kontos wird abgefangen. +- Login mit E-Mail und Passwort, Rückleitung zu einer internen Zielseite und allgemeine Fehlermeldung bei falschen Zugangsdaten. +- Abmeldung über Desktop-Navigation und mobiles Menü. +- Nach zehn Fehlversuchen wird das betreffende Konto für 15 Minuten gesperrt; erfolgreicher Login setzt den Zähler zurück. +- JWT-basierte Sessions mit Benutzer-, Kita-, Familien- und Rolleninformationen. Rolle und Zuordnungen werden bei weiteren Session-Aufrufen mit der Datenbank abgeglichen. +- Geschützte Seiten leiten nicht angemeldete Personen zum Login und Gründer ohne Kita zur Einrichtung weiter. +- Datenschutzannahme wird mit Zeitpunkt und Versionskennung gespeichert. Die Sonderseite für fehlende Zustimmung verweist auf Support; sie enthält kein Formular zum Nachholen der Zustimmung. + +**Einschränkungen:** Kein Passwort-vergessen-/Passwort-ändern-Ablauf. Die Gründerregistrierung setzt `emailVerifiedAt` unmittelbar, ohne Bestätigungsmail. Ein allgemeines IP-Limit für Login oder Registrierung ist nicht angebunden; das Kontaktformular hat sein eigenes Limit. + +Quellen: [Registrierung](../src/app/register/actions.ts), [Einrichtung](../src/app/onboarding/actions.ts), [Login](../src/app/login/actions.ts), [Authentifizierung](../src/auth.ts), [Proxy](../src/proxy.ts), [Consent-Seite](../src/app/onboarding/consent/page.tsx). + +### 4.3 Dashboard und Navigation + +- Begrüßung mit Kita-Namen, Benutzernamen und aktuellem Datum. +- Kennzahlen zu Familien, aktiven Kindern, eingetragenen Notdienst-Verfügbarkeiten des Folgemonats und rechnerisch heute anwesenden Kindern. +- Direktes Melden einer Kinderabwesenheit und Übersicht der laufenden/bevorstehenden eigenen Abwesenheiten. +- Schnellzugriffe auf Familienverwaltung, Kalender, Notdienstplanung und Adressbuch. Die drei letztgenannten berücksichtigen die Modulschalter bei der Anzeige. +- Hinweisdialog bei unvollständigem Profil: Telefon, Adresse sowie gegebenenfalls Haushalt und Kinder. Fortschritt wird angezeigt; der Hinweis kann im lokalen Browser dauerhaft ausgeblendet werden. +- Rollenabhängige Seitenleiste und ein auf kleinen Bildschirmen aufklappbares Menü. + +**Einschränkungen:** Die Notdienstkennzahl zählt Verfügbarkeitseinträge, keine tatsächlich besetzten Plantage. Schnellzugriffe auf Verwaltung werden nicht vollständig nach Rolle ausgeblendet; die Zielseiten besitzen Rollenprüfungen. Die Notdienst-Badge `4` in der Seitenleiste ist fest hinterlegt. + +Quellen: [Dashboard](../src/app/dashboard/page.tsx), [Profilhinweis](../src/components/OnboardingDialog.tsx), [Dashboard-Rahmen](../src/components/dashboard/dashboard-shell.tsx). + +### 4.4 Profil, Haushalt und eigene Kinder + +- Anzeige von Name, E-Mail-Adresse, Rolle, Kita, Haushalt, angelegtem Konto und zugewiesenen festen Ämtern. +- Bearbeiten von Telefonnummer, Straße, Postleitzahl und Ort. +- Adressbuchfreigabe erteilen oder zurückziehen; Zeitpunkt der Freigabe wird gespeichert. +- Eigenen Haushalt anlegen, wenn noch keiner zugeordnet ist. +- Eigene Kinder anlegen, bearbeiten und löschen; Vor-/Nachname sowie optionales Geburtsdatum. +- Bei Eingabe eines Geburtsdatums: gültiges Datum, nicht in der Zukunft, höchstens sieben Jahre zurück. +- Datenänderungen an Kindern werden auf den eigenen Haushalt und die eigene Kita begrenzt. +- Eigenes Konto nach Bestätigung löschen. Bestehen aktuelle oder zukünftige veröffentlichte Notdienstpflichten des Haushalts, wird die Selbstlöschung abgelehnt. +- Beim letzten Benutzer eines Haushalts wird die Familie samt abhängigen Kindern gelöscht; bei weiteren Benutzern bleibt der Haushalt bestehen. + +**Einschränkungen:** Name, E-Mail und Rolle lassen sich im persönlichen Profil nicht ändern. Eine Sperre der Kinderlöschung bei bestehenden Notdienstpflichten ist in `deleteMyChild` nicht vorhanden, obwohl die Kontolöschung diese Pflichten prüft. + +Quellen: [Profilseite](../src/app/dashboard/profil/page.tsx), [Profilaktionen](../src/app/dashboard/profil/actions.ts). + +### 4.5 Familienverwaltung, Eltern-Einladungen und feste Ämter + +- Adminübersicht aller Familien mit Eltern und Kindern; Suche nach Familie, Eltern, E-Mail und Kindern. +- Umschalten zwischen Tabelle und Karten. +- Neue Familie mit einem oder zwei Elternteilen sowie einem bis zehn Kindern anlegen. +- Familienname, Namen/E-Mail-Adressen der Eltern und Kindernamen bearbeiten. +- Zweiten Elternteil ergänzen, neue Kinder hinzufügen und Kinder entfernen. Der Bearbeitungsablauf verlangt mindestens ein verbleibendes Kind und höchstens zwei Elternteile. +- Neue Elternkonten erhalten die Rolle `ELTERN` und einen Einladungslink zur Passwortvergabe mit sieben Tagen Gültigkeit. +- Aktivierung prüft Link, Ablaufdatum, Passwortlänge, Passwortbestätigung und Datenschutzannahme; optionales Adressbuch-Opt-in. +- Nach Aktivierung werden Passwort und Zustimmungen gespeichert, der Token gelöscht und die Person direkt angemeldet. +- Die Familienliste zeigt anhand der Kontoverifikation, ob eine Einladung noch offen ist. +- Feste Ämter mit Name und optionaler Beschreibung anlegen und löschen. +- Ein oder mehrere Ämter an einzelne Benutzer vergeben und Zuordnungen entfernen; doppelte identische Zuordnungen werden verhindert. +- Ämter sind im Profil und Adressbuch sichtbar. + +**Einschränkungen:** Kein regulärer Dialog zum erneuten Versand oder Widerruf einer Einladung. Einladungen werden im tatsächlichen Ablauf in `VerificationToken` gespeichert. Das separate Modell `Invitation` ist dafür nicht angebunden. Scheitert der Mailversand nach der Datenanlage, bleibt die Familie angelegt und eine Fehlermeldung wird zurückgegeben. Eine vollständige Familienlöschung durch Kita-Admins ist nicht angeboten. + +Quellen: [Familienaktionen](../src/app/dashboard/families/actions.ts), [Familienliste](../src/app/dashboard/families/_components/families-list-client.tsx), [Einladungsaktivierung](../src/app/invite/%5Btoken%5D/actions.ts), [Ämter](../src/app/dashboard/families/duty-actions.ts). + +### 4.6 Notdienst-Verfügbarkeiten für Eltern + +- Eingabe für den Folgemonat, bezogen auf aktive Kinder des eigenen Haushalts. +- Mindestzahl an ausgewählten Tagen entspricht Anzahl der Kinder × Kita-Einstellung. +- Bereits gespeicherte Haushaltseinträge werden geladen und können erneut gespeichert werden. +- Monatskalender mit Terminen, Kategorien, Veranstaltungsdetails und auswählbaren Verfügbarkeitstagen. +- Die Oberfläche lässt Montag bis Freitag zu und sperrt bestätigte Schließtage. +- Auswahlfortschritt und Rückmeldung bei zu wenigen Tagen. +- Die ausgewählten verschiedenen Tage werden beim Speichern reihum auf die angegebenen Kinder verteilt; bestehende Einträge dieser Kinder im Zielmonat werden ersetzt. +- Eingabefrist ist im Code fest: bis einschließlich 26. des aktuellen Monats, gesperrt ab dem 27. +- Ohne aktive eigene Kinder erscheint ein Hinweis mit Verweis zum Profil. + +**Einschränkungen:** Die Server Action prüft Datumsformat, Zielmonat, Mindestzahl und Haushaltszugehörigkeit, aber keine Wochenenden oder Schließtage. Die Frist ist nicht im Einstellungsdialog konfigurierbar. Abwesenheitsmeldungen werden bei den Verfügbarkeiten nicht automatisch berücksichtigt. + +Quellen: [Elternseite](../src/app/dashboard/notdienst/page.tsx), [Kalendereingabe](../src/app/dashboard/notdienst/notdienst-form.tsx), [Speichern](../src/app/dashboard/notdienst/actions.ts), [Fristregel](../src/lib/date-utils.ts). + +### 4.7 Notdienst-Planungszentrale + +- Admins und Koordinatoren können über Monat/Jahr navigieren; Vorgabe ist der Folgemonat. +- Übersicht von Haushalten, Kindern, Verfügbarkeitstagen, Haushalten mit/ohne Rückmeldung und Planstatus. +- Automatische Erzeugung eines monatlichen Entwurfs; ein bestehender Monatsplan verhindert erneute Generierung. +- Für jeden Montag bis Freitag wird aus verfügbaren Kindern ein Haushalt ausgewählt, der im bisherigen Monatsdurchlauf möglichst selten eingeteilt wurde. Bei Gleichstand kommt Zufall zum Einsatz; der Zähler startet jeden Monat neu. +- Tage ohne Verfügbarkeiten bleiben unbesetzt. +- Vorschau und manuelle Zuordnung zu einem aktiven Kind der Kita; Tage können auch geleert werden. +- Entwurf veröffentlichen; veröffentlichte Einteilungen erscheinen im Kalender. +- Veröffentlichte Pläne nachbearbeiten, solange der betreffende Tag nicht vergangen ist. +- Nach manuellen Änderungen eines veröffentlichten Plans werden E-Mails an betroffene Elternkonten der Rolle `ELTERN` angestoßen; betroffene offene Tauschanfragen werden ungültig. +- Entwurfsplan mit Bestätigungsdialog zurücksetzen und löschen. Veröffentlichte Pläne werden serverseitig vom Reset ausgeschlossen. +- Kita-Einstellungen für Mindestverfügbarkeiten und Erinnerungs-Vorlauf speichern. +- Manuell Erinnerungen an Haushalte versenden, die im ausgewählten Monat gar keinen Verfügbarkeitseintrag haben. +- „Als PDF exportieren“ öffnet den Browser-Druckdialog (`window.print()`); die PDF-Datei entsteht über die Druckfunktion des Browsers. + +**Einschränkungen:** Keine garantierte optimale oder über mehrere Monate ausgeglichene Verteilung. Die Generierung berücksichtigt keine Feiertage, Schließtage, Teamtage oder Kinderabwesenheiten. Ein Erinnerungs-Vorlauf wird gespeichert, aber kein zeitgesteuerter Job verwendet ihn. Haushalte mit zu wenigen Einträgen erhalten über diese Erinnerungsaktion keine Erinnerung, sobald wenigstens ein Eintrag vorliegt. Beim erstmaligen Veröffentlichen wird keine Zuteilungsmail versendet; die entsprechende E-Mail-Vorlage allein ist kein angebundener Versand. + +Quellen: [Planungsseite](../src/app/dashboard/notdienst/plan/page.tsx), [Planaktionen](../src/app/dashboard/notdienst/plan/actions.ts), [Planoberfläche](../src/app/dashboard/notdienst/plan/plan-view.tsx). + +### 4.8 Notdienst-Tausch zwischen Familien + +- Eltern können im Kalender einen fremden Notdienst anfragen und einen eigenen veröffentlichten Dienst zum Tausch anbieten; optionale Nachricht bis 500 Zeichen. +- Beide Dienste müssen derselben Kita angehören, veröffentlicht und heute oder zukünftig sein. Ein Tausch im eigenen Haushalt wird abgewiesen. +- Dienste mit wartender oder bestätigter Alarmierung sind vom Tausch ausgeschlossen. +- Bereits beteiligte Dienste mit offenen Tauschanfragen können keine weitere offene Anfrage erhalten. +- Der angefragte Haushalt erhält eine E-Mail und sieht die offene Anfrage im Kalender. +- Angefragter Haushalt kann annehmen oder ablehnen; anfragender Haushalt kann zurückziehen. +- Annahme vertauscht beide Kinder-Zuordnungen in einer Transaktion, speichert die Entscheidung und storniert weitere betroffene offene Anfragen. +- Annahme und Ablehnung lösen Benachrichtigungen an beide Familien aus; Rücknahme speichert den Status ohne eigenen Mailversand. +- Kalender und Notdienstansichten werden nach Änderungen neu validiert. + +**Einschränkungen:** Neue Anfragen sind auf die exakte Rolle `ELTERN` beschränkt; Eltern mit Admin-/Koordinatorrolle können sie nicht starten. Die Oberfläche zeigt offene Anfragen, keine vollständige abgeschlossene Tauschhistorie. Eine erneute Verfügbarkeitsprüfung für die getauschten Tage erfolgt nicht. + +Quellen: [Tauschaktionen](../src/app/dashboard/kalender/actions.ts), [Kalender und Anfragen](../src/app/dashboard/kalender/_components/calendar-overview-client.tsx), [Tauschdialog](../src/app/dashboard/kalender/_components/termin-list.tsx). + +### 4.9 Notdienst-Alarmierung + +Die am 09.10.2026 abgestimmte Erweiterung ist in [NOTDIENSTALARM_PLAN.md](NOTDIENSTALARM_PLAN.md) beschrieben. Sie ist zunächst geplant; der folgende Abschnitt beschreibt den vorhandenen Code. + +Vorbereitet sind: + +- Server Action zum Auslösen eines Alarms durch Admin/Koordinator für eine Einteilung. +- Kita-Prüfung und Abweisung einer bereits alarmierten Einteilung. +- Eigene Alarmdatensätze und E-Mails für die Elternkonten der eingeteilten Familie mit Rolle `ELTERN`. +- Bestätigungsseite unter `/alert/[token]`; der Link erlaubt die Bestätigung ohne Login. +- Statuswechsel von `PENDING` auf `CONFIRMED` mit Zeitstempel; erneute Bestätigung wird abgewiesen. +- Vorbereitete Button-Komponente für das Auslösen. + +**Aktueller Stand:** `AlertButton` wird von keiner Seite eingebunden. Ein erreichbarer Auslöseablauf und eine laufende Statusübersicht für die Koordination fehlen damit in der aktuellen Oberfläche. Das Datenmodell kann eine erkrankte Fachkraft und Notizen speichern, aber die Aktion nimmt nur die Einteilungs-ID entgegen. Eine Auswahl der Fachkraft, Alarmstornierung, Eskalation oder zeitliche Token-Gültigkeit ist nicht angebunden. + +Quellen: [Alarmaktion](../src/app/dashboard/actions.ts), [ungebundener Alarmbutton](../src/app/dashboard/alert-button.tsx), [Bestätigung](../src/app/alert/%5Btoken%5D/actions.ts). + +### 4.10 Kalender, Terminanfragen und Mitbringlisten + +- Gemeinsamer Kalender für bestätigte Termine, eigene ausstehende Terminanfragen, geplante Elterndienste und veröffentlichte Notdienste. +- Listen-, Monats- und Agendaansicht; Monatsnavigation und Sprung zu heute. +- Tagesdialog mit Termindetails, Diensten und Mitbringlisten. +- Suche nach Titel/Beschreibung und bei Diensten nach Familie beziehungsweise Kind. +- Kategorienfilter und Umschaltung zwischen eigenen und allen Diensten; reguläre Kita-Termine bleiben auch im eigenen Filter sichtbar. +- Kategorien: Kita-Fest, Schließtag, Teamtag, Mitmach-Tag, Elternabend, Mitgliederversammlung, Elterncafé, interner/externer Geburtstag und Sonstiges. +- Terminanfrage mit Titel, Beschreibung, Kategorie, Anfang/Ende und Ganztagsangabe. +- Eigene Anfragen werden als ausstehend angezeigt; Admins/Koordinatoren können ausstehende Anfragen bestätigen oder mit Begründung ablehnen. +- Admins/Koordinatoren können bestätigte Termine direkt anlegen, bearbeiten und endgültig löschen. +- Datumsprüfung: Beginn nicht in der Vergangenheit, Ende nicht vor Beginn. +- Mitbringliste je Termin aktivieren/deaktivieren; Textbeiträge hinzufügen. +- Eigene Beiträge löschen; Admins/Koordinatoren können auch fremde Beiträge löschen. +- Verweise aus Dienst-/Notdienstterminen in die entsprechenden Verwaltungsseiten; Diensttausch über den Kalender. + +**Einschränkungen:** Ausstehende Anfragen blockieren keinen Zeitraum durch eine serverseitige Kollisionsprüfung. Eine Anfrage ist für andere Eltern nicht allgemein als reservierter Slot sichtbar. Mitbringbeiträge lassen sich nicht direkt bearbeiten, sondern nur löschen und neu anlegen. Es wurde kein Kalenderabo, ICS-Export oder Serientermin-Ablauf gefunden. + +Quellen: [Kalenderseite](../src/app/dashboard/kalender/page.tsx), [Kalenderansichten](../src/app/dashboard/kalender/_components/calendar-overview-client.tsx), [Terminaktionen](../src/app/dashboard/kalender/actions.ts), [Mitbringliste](../src/app/dashboard/kalender/_components/mitbringsel-list.tsx). + +### 4.11 Event-Anmeldungen und RSVP + +- Admins/Koordinatoren können Termine mit Teilnahmeabfrage, optionaler Rückmeldefrist und Hinweisen für Teilnehmende anlegen/bearbeiten. +- Verwaltungsseite listet Termine samt Status und zeigt pro Event Zusagen, Absagen und ausstehende Antworten. +- Kindbezogene Teilnehmerliste über alle aktiven Kinder der Kita. +- Server Action für Zu-/Absage eines eigenen aktiven Kindes, inklusive Prüfung von Kita, Haushalt, bestätigtem Termin und Frist. +- Fehlt eine eigene Frist, gilt der Eventbeginn als Rückmeldeschluss. Eine bestehende Antwort kann bis dahin überschrieben werden. +- Teilnehmerhinweise werden im Kalender bei Admin/Koordinator und bei einem Haushalt mit mindestens einer Zusage angezeigt. + +**Aktueller Stand:** Die Eltern-Eingabekomponente `RsvpActionCard` existiert, wird aber von keiner Seite verwendet. Eltern besitzen deshalb im aktuellen Seitenaufbau keinen eingebundenen Zu-/Absagedialog. Außerdem wird `participantInfo` bereits an den Kalender-Client übertragen und nur bei der Darstellung ausgeblendet; die Anzeigeprüfung ist keine serverseitige Zugriffsbeschränkung für diese Information. + +Quellen: [RSVP-Aktionen](../src/actions/rsvp.ts), [Event-Verwaltung](../src/app/dashboard/admin/kalender/admin-calendar-manager.tsx), [ungebundene Elternkomponente](../src/app/dashboard/rsvp-action-card.tsx), [Kalenderdaten](../src/app/dashboard/kalender/page.tsx). + +### 4.12 Krank- und Abwesenheitsmeldungen + +- Eigenes aktives Kind aus dem Haushalt auswählen und für einen Tag oder Zeitraum abmelden. +- Gründe: Krankheit, Urlaub und Sonstiges; optionale Notiz bis 500 Zeichen. +- Ende darf nicht vor dem Beginn liegen; sich überschneidende Meldungen desselben Kindes werden abgewiesen. +- Eigene laufende/bevorstehende Meldungen anzeigen und löschen. +- Tagesübersicht für Admin, Koordinator und Erzieherrolle mit Kind, Familie, Grund, Zeitraum und Notiz. +- Tagesnavigation zurück/vor/heute und freie Datumswahl. +- Grundfilter, Kennzahlen und Hinweise zu Wochenende, Schließtag/Teamtag sowie Tagen mehr als 30 Tage in der Zukunft. +- Abwesenheiten sind nicht als echte Anwesenheitserfassung mit Check-in/Check-out implementiert; „anwesend“ ist aus Kinderzahl minus Meldungen abgeleitet. + +**Einschränkungen:** Gruppen „Krippe“ und „Elementar“ werden aus dem ersten Zeichen des Kindernamens künstlich abgeleitet (`mockGroup`). Das Datenmodell hat keine echte Gruppenzuordnung. Die Anwesenheitszahl dieser Ansicht verwendet die gefilterten Fehlmeldungen bei weiterhin gesamter Kinderzahl und kann deshalb bei aktivem Filter irreführend sein. Eine bestehende Abwesenheit kann nur gelöscht und neu gemeldet, nicht direkt bearbeitet werden. + +Quellen: [Abwesenheitsaktionen](../src/actions/absences.ts), [Elternformular](../src/app/dashboard/absence-card.tsx), [Tagesübersicht](../src/app/dashboard/admin/abwesenheiten/page.tsx), [Filter](../src/app/dashboard/admin/abwesenheiten/_components/absences-client.tsx). + +### 4.13 Wöchentlicher Dienstplan + +- Separater Dienstplan für Haushalte, unabhängig von festen personenbezogenen Ämtern und Notdienst. +- Diensttypen mit Name/Beschreibung anlegen und löschen. +- Wochenraster mit wählbarem Beginn und Zeitraum; Standard zwölf Wochen, maximal 104 Wochen. +- Haushalt je Diensttyp/Kalenderwoche auswählen oder Zuordnung entfernen; Änderungen werden direkt gespeichert. +- Kita-Zugehörigkeit von Diensttyp und Familie wird geprüft. +- Einteilungen erscheinen im gemeinsamen Kalender. +- Manuelle Erinnerungsaktion für noch nicht erinnerte geplante Dienste, deren Beginn in der aktuellen Woche liegt. +- Versand an verifizierte Benutzer der Familie; erfolgreicher Versand wird mit `reminderSentAt` gespeichert. Erneute Zuordnung setzt diesen Wert zurück. + +**Einschränkungen:** Kein automatisch laufender Erinnerungsjob. Status `DONE` und `CANCELLED` existieren im Datenmodell, aber ein regulärer Abschluss-/Stornoablauf ist nicht eingebunden. Eine Änderung setzt den Dienst wieder auf `PLANNED`. Das Löschen eines Diensttyps löscht durch die Datenrelationen auch dessen Einteilungen. + +Quellen: [Dienstplanseite](../src/app/dashboard/admin/dienste/page.tsx), [Raster](../src/app/dashboard/admin/dienste/duty-planner.tsx), [Dienstaktionen](../src/app/dashboard/admin/dienste/actions.ts). + +### 4.14 Schwarzes Brett, E-Mail und Anhänge + +- Admins können eine Ankündigung mit Titel und Markdown-Inhalt erstellen; Vorschau ist im Formular vorhanden. +- PDF-, JPG- und PNG-Anhänge bis zehn MB je Datei. +- Speicherung der Anhangdateien auf dem Server und der Metadaten in der Datenbank. +- Abruf über geschützte API mit Prüfung auf angemeldeten Benutzer und dieselbe Kita; keine Auslieferung über ein öffentliches Uploadverzeichnis. +- Optionaler E-Mail-Versand an verifizierte Haushaltskonten, Erzieherkonten oder beide Gruppen. Die Auswahl betrifft E-Mail-Empfänger und wird nicht als Sichtbarkeitsgruppe der Meldung gespeichert. +- Adminseite zeigt die letzten acht veröffentlichten Meldungen mit Autor, Zeitpunkt und Anhanganzahl. +- Bei Dateischreibfehlern werden die neue Meldung und angefangene Dateien zurückgenommen; bei Mailfehlern bleibt die Meldung gespeichert und eine Warnung wird zurückgegeben. +- Lesestatusmodell und Aktion zum Markieren als gelesen sind vorhanden; `NewsTicker` enthält einen vorbereiteten Meldungsdialog. + +**Aktueller Stand:** `NewsTicker` ist nicht in das Dashboard oder eine andere Seite eingebunden. Eltern können neue Meldungen daher derzeit über den optionalen Mailversand erhalten, besitzen aber keine eingebundene Meldungsliste in der App. Eine Adminauswertung der Lesebestätigungen sowie Bearbeiten/Löschen von Meldungen sind nicht umgesetzt. + +Quellen: [Meldungsaktionen](../src/actions/announcements.ts), [Adminseite](../src/app/dashboard/admin/news/page.tsx), [Formular](../src/app/dashboard/admin/news/news-form.tsx), [ungebundener Ticker](../src/app/dashboard/news-ticker.tsx), [Anhang-API](../src/app/api/announcements/attachments/%5Bid%5D/route.ts). + +### 4.15 Adressbuch + +- Interne Übersicht der Haushalte, bei denen mindestens ein Benutzer der Kontaktfreigabe zugestimmt hat. +- Anzeige von Haushaltsname, Kindern, Elternnamen und festen Ämtern; alphabetische Gruppierung nach Haushaltsnamen. +- E-Mail, Telefon und Adresse werden nur für den jeweiligen Benutzer mit Opt-in geladen. +- Suche nach Familienname, Eltern-/Kindernamen oder sichtbarer E-Mail. +- Filter für Telefonnummer, Ämter und Haushalte mit Opt-in aller zugeordneten Benutzer. +- Detaildialog je Familie; E-Mail- und Telefonlinks starten den jeweiligen Mail-/Telefonhandler. +- Sichtbarkeitsdialog erklärt die Freigabe und führt zum eigenen Profil. +- Optionales Geburtsdatum eines Kindes ist im Detaildialog sichtbar. + +**Einschränkung:** Namen und Ämter eines zweiten Elternteils ohne Kontaktfreigabe sowie Kinderinformationen sind innerhalb eines sichtbaren Haushalts weiterhin sichtbar. Die Freigabe ist technisch kein Opt-in für sämtliche Haushaltsinformationen. + +Quellen: [Adressbuchdaten](../src/app/dashboard/adressbuch/page.tsx), [Adressbuchoberfläche](../src/app/dashboard/adressbuch/_components/directory-client.tsx). + +### 4.16 ErzieherInnen-Stammdaten + +- Admins können Fachkräfte mit Vor- und Nachname anlegen, bearbeiten und löschen. +- Aktivstatus wird gepflegt und dargestellt. +- Diese Datensätze sind keine Login-Konten; die separate Benutzerrolle `ERZIEHER` ist hiervon unabhängig. +- Referenz für Notdienstalarme im Datenmodell vorhanden, aber derzeit keine Fachkraftauswahl im Alarmauslöser. + +Quellen: [Erzieheraktionen](../src/app/dashboard/erzieher/actions.ts), [Erzieheroberfläche](../src/app/dashboard/erzieher/_components/erzieher-list.tsx). + +### 4.17 Systemweite Superadmin-Verwaltung + +- Übersicht aller Kitas mit Slug, Modulstatus, Benutzer-/Familien-/Kinderzahlen, Terminen, Abwesenheiten, Meldungen, offenen Einladungen und letztem Login. +- Hinweise auf Benutzer ohne Kita, Kontosperren, fehlende Datenschutzzustimmung und Familien ohne Benutzer. +- Kita-Diagnose mit Benutzerliste, Rollen, Familien, Verifikationsstatus, Consent, Fehlversuchen und Sperren; zusätzlich Zähler für Konten ohne Passwort und abgelaufene Einladungen. +- Diagnoseaufrufe werden im Audit-Protokoll gespeichert. +- Kita endgültig löschen nach exakter Namensbestätigung, mit kaskadierender Löschung abhängiger Datenbankdatensätze. +- Kita-gebundene Benutzer löschen nach Bestätigung ihrer E-Mail-Adresse; dabei zugehörige Verifikationstokens entfernen. +- Benutzer für weitere Logins sperren, entsperren oder Fehlversuche zurücksetzen. Sperrung setzt `lockedUntil` weit in die Zukunft; Entsperren löscht die Sperre und setzt den Zähler zurück. +- Eigene und andere Superadmin-Konten sowie Konten ohne Kita werden durch diese Support-Aktionen nicht verändert. +- Auditansicht zeigt die neuesten 200 Einträge samt Akteur, Ziel, Zeitpunkt, Aktion und Metadaten. Protokolle können auch nach Löschung der Zielobjekte bestehen bleiben. + +**Einschränkungen:** Offene und abgelaufene Einladungen werden über `Invitation` gezählt, während die tatsächlichen Familien-Einladungen `VerificationToken` nutzen. Eine Superadmin-Benutzerlöschung entfernt nicht automatisch einen nun leeren Haushalt. Eine Sperre wird bei der Anmeldung geprüft; das sofortige Beenden bereits bestehender Sessions ist nicht umgesetzt. + +Quellen: [Adminübersicht und Diagnose-Daten](../src/app/admin/_lib/data.ts), [Support-Aktionen](../src/app/admin/actions.ts), [Auditseite](../src/app/admin/audit/page.tsx). + +## 5. Datenmodell und technische Querschnittsfunktionen + +- PostgreSQL mit Prisma. Eine Kita ist ein Mandant; fachliche Daten sind über `kitaId` zugeordnet. +- Datenmodelle für Kitas, Benutzer, Haushalte, Kinder, Fachkräfte, feste Ämter, Diensttypen/-einteilungen, Abwesenheiten, Meldungen, Anhänge, Lesestatus, Termine, Teilnahme, Mitbringsel, Notdienstpläne/-verfügbarkeiten/-einteilungen/-alarme/-tausche sowie Auditprotokolle und Tokens. +- Eindeutigkeitsregeln unter anderem für E-Mail, Kita-Slug, Monatsplan, Einteilung je Plantag, Verfügbarkeit je Kind/Tag, Teilnahme je Event/Kind und Amt je Benutzer. +- Eingabeprüfung überwiegend mit Zod, Schreibabläufe teilweise als Datenbanktransaktionen, Aktualisierung von Seiten nach Änderungen. +- Gemeinsamer E-Mail-Versand über Resend mit Fehlerbehandlung. Ohne API-Key werden E-Mails nur in der Entwicklungsumgebung simuliert; diese Simulation bestätigt keine Zustellung. +- Vorlagen für Einladung, Alarm, Verfügbarkeitserinnerung, Einteilungsänderung, Diensttausch, Wochen-Diensterinnerung, News und Kontakt. Eine weitere Vorlage für erstmalige Notdienst-Zuteilung ist vorhanden, aber nicht an die Veröffentlichung angebunden. +- Rollen-, Kita- und Consent-Prüfungen über gemeinsame Helfer. Geschützte Dashboard-/Adminlayouts, Seiten und Aktionen setzen Zugriffsprüfungen ein; nicht jede Aktion verwendet denselben Consent-Helfer. +- Viele Datenbankrelationen löschen abhängige Datensätze mit. Das ist nicht gleichbedeutend mit vollständiger Bereinigung von Dateien, allgemeinen Verifikationstokens oder Audit-Snapshots. +- Der Hilfsmodus `TEST_MODE=true` liefert in `requireRole` und `requireKitaSession` künstliche Sessions und umgeht dort die regulären Prüfungen. Er ist nicht auf die Entwicklungsumgebung begrenzt. + +Quelle: [Schema](../prisma/schema.prisma), [Mail](../src/lib/mail.ts), [Auth-Helfer](../src/lib/auth-utils.ts). + +## 6. Seiten- und Schnittstellenverzeichnis + +| Route | Zweck/Zugriff | +| --- | --- | +| `/` | Öffentliche Startseite und Kontakt. | +| `/features/notdienst-planer` | Öffentliche Notdienst-Beschreibung. | +| `/features/kita-kalender` | Öffentliche Kalender-Beschreibung. | +| `/features/eltern-adressbuch` | Öffentliche Adressbuch-Beschreibung. | +| `/features/krankmeldung` | Öffentliche Abwesenheits-Beschreibung. | +| `/features/schwarzes-brett` | Öffentliche Meldungs-Beschreibung. | +| `/impressum`, `/datenschutz` | Öffentliche Informationsseiten mit noch offenen Platzhaltern. | +| `/register`, `/login` | Gründerregistrierung und Anmeldung. | +| `/onboarding` | Kita einrichten nach Anmeldung. | +| `/onboarding/consent` | Hinweis bei fehlender Datenschutzannahme. | +| `/invite/[token]` | Elternkonto über Einladungslink aktivieren. | +| `/alert/[token]` | Notdienstalarm über Link bestätigen. | +| `/forbidden` | Hinweis bei verweigertem Zugriff. | +| `/dashboard` | Kita-Übersicht und eigene Abwesenheiten. | +| `/dashboard/profil` | Eigener Haushalt, Kinder, Kontakte und Kontolöschung. | +| `/dashboard/notdienst` | Verfügbarkeiten; Eltern, Admin, Koordinator. | +| `/dashboard/notdienst/plan` | Planung; Admin, Koordinator. | +| `/dashboard/kalender` | Kita-Kalender und Diensttausch. | +| `/dashboard/adressbuch` | Internes Adressbuch. | +| `/dashboard/families` | Familien und feste Ämter; Admin. | +| `/dashboard/erzieher` | Fachkraft-Stammdaten; Admin. | +| `/dashboard/admin/dienste` | Wochen-Dienstplan; Kita-Admin. Die Aktion erlaubt zusätzlich Superadmin mit Kita-Kontext. | +| `/dashboard/admin/news` | Meldungen veröffentlichen; Admin. | +| `/dashboard/admin/kalender` | Termine und Event-Anmeldungen; Admin, Koordinator. | +| `/dashboard/admin/abwesenheiten` | Tagesübersicht; Admin, Koordinator, Erzieherrolle. | +| `/admin` | Systemweite Kita-Übersicht; Superadmin. | +| `/admin/kitas/[kitaId]` | Kita-Diagnose und Benutzersupport; Superadmin. | +| `/admin/audit` | Systemweites Audit-Protokoll; Superadmin. | +| `/api/auth/[...nextauth]` | Auth.js-Endpunkte. | +| `/api/announcements/attachments/[id]` | Geschützter Anhangdownload. | +| `/sitemap.xml`, `/robots.txt` | Suchmaschinensteuerung. | + +## 7. Betrieb, Entwicklung und Prüfstand + +- Stack laut `package.json`: Next.js 16.2.4, React 19.2.4, TypeScript, Prisma 6, Auth.js/NextAuth v5 beta, PostgreSQL, Tailwind CSS und Resend. +- Lokaler Entwicklungsstart führt vor Next.js automatisch `prisma db push` und den Seed aus. +- Seed legt Demonstrationsdaten mit mehreren Rollen und fachlichen Beispielen an; regulärer Seed ist bei bereits befüllter Datenbank zurückhaltend. Ein separater Reset-Modus existiert. +- Docker-Build und Produktionsstart sind vorhanden; Produktionsstart wendet das Schema über `prisma db push --skip-generate` an. Versionierte Prisma-Migrationen liegen nicht im geprüften Dateibestand. +- Lokale Compose-Datei stellt PostgreSQL bereit; Coolify-Compose enthält App, PostgreSQL, pgAdmin und persistente Datenbank-/Uploadvolumes. +- Umgebungsvariablen-Vorlage und Produktionscheckliste sind vorhanden; ihre tatsächliche Erfüllung wurde nicht auf einem Server geprüft. +- `UPLOAD_DIR` ist persistent vorgesehen. Die Dateihilfsfunktionen hängen noch `announcements` an diesen Pfad an; bei der aktuellen Compose-Konfiguration ergibt sich `/app/uploads/announcements/announcements`. +- Kein Testskript und keine automatisierte Testdateisuite im geprüften Repository gefunden. Demo-Seed und manueller Live-Testplan ersetzen keine automatisierten Tests. + +### Ausgeführte technische Prüfungen + +Die Prüfungen liefen auf dem unveränderten Ausgangscheckout mit den dort bereits installierten Abhängigkeiten. Es wurden keine Bibliotheken installiert und keine Builds oder Datenbankoperationen ausgeführt. + +| Prüfung | Ergebnis | +| --- | --- | +| `./node_modules/.bin/tsc --noEmit --incremental false` | Erfolgreich, Exit-Code 0. | +| `npm run lint` | Fehlgeschlagen, Exit-Code 1: zwei Fehler und neun Warnungen. | +| Quellenprüfung von Seiten, Aktionen, Komponenten und Schema | Durchführung für die oben beschriebenen Funktionsbereiche. | +| Aktueller Browser-/End-to-End-Test | Nicht durchgeführt. | +| Mailzustellung und produktives Deployment | Nicht geprüft. | + +Beide ESLint-Fehler betreffen `as any` im Testmodus von `src/lib/auth-utils.ts` (Zeilen 57 und 91). Die Warnungen betreffen ungenutzte Variablen/Imports im Seed, Kalender, Adressbuch und Abwesenheiten. Diese Bestandsaufnahme ändert keinen Anwendungscode. + +Der vorhandene [Live-Testplan](live-testplan.md) vom 17.05.2026 dokumentiert erfolgreiche Tests von Landingpage/Kontakt, Gründerregistrierung, Einrichtung, Dashboard, Familienanlage und Teilen des Login-Ablaufs. Eltern-Einladungsaktivierung und anschließende Bereinigung sind dort noch offen. Dies sind historische Einträge, keine aktuellen Testnachweise für den geprüften Commit. Die abgehakten Punkte in [UI-TODO.md](../UI-TODO.md) sind ebenfalls historische Angaben; viele der dort ehemals fehlenden Handler sind inzwischen im Code vorhanden. + +Quellen: [Paket und Skripte](../package.json), [Deployment](../deploy/README.md), [Produktionscheckliste](../deploy/production-checklist.md), [Seed](../prisma/seed.ts), [Coolify-Compose](../docker-compose.coolify.yml). + +## 8. Konkrete offene Punkte für die weitere Arbeit + +Die Reihenfolge ist ein Vorschlag aus der Bestandsaufnahme; es wurde nichts davon umgesetzt. + +| Reihenfolge | Thema | Konkreter nächster Schritt | +| --- | --- | --- | +| 1 | Fehlende Elternabläufe | NewsTicker und RSVP-Eingabe an eine erreichbare Seite anbinden; Daten dafür laden. | +| 2 | Notdienstalarm | Auslösebutton, Fachkraftauswahl und Statusanzeige in den aktuellen Seitenaufbau integrieren. | +| 3 | Moduldeaktivierung | Modulschalter in Navigation, Seiten und Server Actions einheitlich prüfen; spätere Einstellungen anbieten. | +| 4 | Notdienstregeln | Wochenenden/Schließtage serverseitig ausschließen und Generierung um Schließtage ergänzen; Abwesenheitsregel festlegen. | +| 5 | Erinnerungen | Automatische Ausführung ergänzen und unterscheiden, ob gar keine oder zu wenige Verfügbarkeiten vorliegen. | +| 6 | Erstveröffentlichung | Zuteilungsmails beim Veröffentlichen anbinden und Mailfehler sichtbar behandeln. | +| 7 | Einladungssupport | Tokenmodell und Superadmin-Zähler vereinheitlichen; erneuten Versand, Ablauf und Widerruf erreichbar machen. | +| 8 | Rechtevergabe | Regulären Ablauf für Koordinator-/Erzieherkonten und Rollenänderungen ergänzen. | +| 9 | Abwesenheitsgruppen | Echte Gruppenzuordnung einführen oder den künstlichen Gruppenfilter entfernen; Kennzahlen konsistent berechnen. | +| 10 | Buchungskonflikte | Fachliche Reservierungsregeln definieren und Überschneidungen serverseitig prüfen. | +| 11 | Selbstverwaltung | Passwort-Reset/-Änderung und direkte Bearbeitung von Abwesenheiten/Mitbringbeiträgen ergänzen. | +| 12 | Löschabläufe | Kinderlöschung bei bestehenden Verpflichtungen prüfen; Anhangdateien und Tokens bei Kita-/Kontolöschungen bereinigen; Audit-Aufbewahrung gesondert definieren. | +| 13 | Zugriffsprüfungen | Testmodus an Entwicklungsumgebung binden; Consent-/Session-Prüfungen und Teilnehmerhinweise serverseitig vereinheitlichen. | +| 14 | Technischer Zustand | Zwei ESLint-Fehler beheben, Migrationsablauf einführen und aussagekräftige Tests für die zentralen Abläufe ergänzen. | +| 15 | Aktuelle Abnahme | Rollenbasierte Browserprüfung, Mailzustellung, Elternaktivierung und Bereinigung anhand eines aktualisierten Testplans durchführen. | +| 16 | Öffentliche Texte | Platzhalter in Impressum/Datenschutz mit den tatsächlichen Betriebsangaben vervollständigen und Marketingversprechen mit dem implementierten Verhalten abgleichen. | + +## 9. Nicht als fertige Produktfunktion vorhanden + +Im geprüften Code wurden kein Abonnement-/Zahlungsablauf, keine Import-/Exportverwaltung für Familien, kein externer Kalenderabgleich, keine Push-/SMS-Alarmierung, keine echte Kita-Gruppenverwaltung und keine Zeiterfassung/Check-in-Funktion gefunden. Vorhandene Planungs- oder Marketingtexte sind dafür kein Umsetzungsnachweis. diff --git a/docs/NOTDIENSTALARM.md b/docs/NOTDIENSTALARM.md new file mode 100644 index 0000000..a097079 --- /dev/null +++ b/docs/NOTDIENSTALARM.md @@ -0,0 +1,65 @@ +# Notdienstalarm + +Stand: 09.10.2026 · Umsetzung auf `codex/notdienstalarm` + +## Bedienung + +Kita-Admins und Notdienst-Koordination finden den Alarm in der Navigation und bei eingeteilten Tagen eines veröffentlichten Notdienstplans. Der Dialog zeigt die betroffene Familie und ihre Elternadressen vor dem Auslösen. Er umfasst einen ganzen Kita-Tag oder ein Zeitfenster, eine Antwortfrist (standardmäßig 30 Minuten), eine optionale interne Fachkraftzuordnung und eine interne Notiz. + +Nur die eingeteilte Familie wird angefragt. Jedes Elternkonto erhält einen eigenen persönlichen Rückmeldelink und einen Hinweis in der App. Die Antwort „Wir übernehmen“ oder „Wir können nicht“ muss ausdrücklich gespeichert werden und gilt für den gesamten Haushalt. Das Öffnen des Links speichert keine Antwort. Die erste gespeicherte Antwort entscheidet auch bei gleichzeitigen Antworten; Änderungen dokumentiert die Koordination. + +| Anzeige | Bedeutung / nächster Schritt | +| --- | --- | +| Antwort ausstehend | Haushalt hat noch nicht geantwortet. | +| Übernahme bestätigt | Rechtzeitige Zusage oder dokumentierte Freigabe durch Koordination. | +| Absage – Klärung erforderlich | Alle Admins und KoordinatorInnen der Kita erhalten sofort einen Hinweis. Ersatz manuell organisieren. | +| Klärung erforderlich – Frist abgelaufen | Nach Ablauf informiert der Hintergrundjob einmalig die Admins und KoordinatorInnen. | +| Verspätete Zusage | Muss durch Koordination freigegeben werden; keine automatische sichere Besetzung. | +| Klärung erforderlich | Uneindeutige frühere Einzelantworten wurden übernommen. Haushalt kontaktieren. | +| Storniert | Haushalt wird informiert; der Link kann keine Antwort mehr speichern. | + +Telefonische Rückmeldungen, Korrekturen, verspätete Freigaben und Stornierungen benötigen eine interne Begründung. Interne Fachkraftdaten, Notizen und Verlauf erscheinen ausschließlich in der Verwaltungsansicht und werden nicht per E-Mail übermittelt. Eltern sehen ihre eigenen Alarme; andere Haushalte und Fachkräfte haben keinen Zugriff. + +Aktive Alarme sperren manuelle Umzuordnung und Diensttausche. Für einen Ersatz zuerst den Alarm stornieren, dann die Einteilung ändern und neu alarmieren. Ein ausstehender E-Mail-Versand lässt sich erneut versuchen, ohne die Antwortfrist neu zu starten. Die Anzeige „vom Maildienst angenommen“ bestätigt die Annahme durch den Versanddienst, nicht die Zustellung im Postfach. + +## Zeiten und Grenzen + +- Kita-Zeitzone: `Europe/Berlin`, einschließlich Sommer-/Winterzeit. Nicht existierende Uhrzeiten bei der Zeitumstellung werden abgelehnt. +- Ganze Tage enden um Mitternacht zum Folgetag. Zeitfenster müssen am selben Tag liegen; Ende nach Beginn. +- Die Antwortfrist startet beim Auslösen, beträgt 1–1440 Minuten und endet spätestens mit dem Einsatz. Alarme sind für heute und zukünftige veröffentlichte Einteilungen möglich. +- Nach Einsatzende können Rückmeldelinks keine Antwort mehr speichern. Der letzte Status bleibt lesbar. +- Die Übersicht zeigt bis zu 100 Alarme seit 30 Tagen vor heute. Direkte Detail-Links öffnen auch ältere Vorgänge. Im Dialog stehen Einteilungen der nächsten 93 Tage zur Wahl; das Dashboard zeigt bis zu zehn aktuelle Alarme. +- Kein SMS-/Push-Versand und keine automatische Alarmierung anderer Familien. Notdienstmails gehören zum Alarmablauf und verwenden nicht die persönliche Einstellung für Personal-Antragsmails. + +## Betrieb und Hintergrundjob + +Benötigt werden die vorhandene Resend-Konfiguration (`RESEND_API_KEY`, `EMAIL_FROM`), die korrekte öffentliche App-Adresse (`NEXT_PUBLIC_SITE_URL`, alternativ `AUTH_URL`/`NEXTAUTH_URL`) und neu `NOTDIENST_JOB_SECRET` mit mindestens 32 Zeichen. Ein zufälliges Secret kann beispielsweise mit `openssl rand -hex 32` erzeugt und in der Hosting-Konfiguration gespeichert werden. Das Secret gehört nicht in Git oder ins Browser-Frontend. + +Der bestehende Docker-Produktionsstart startet `scripts/notdienst-alarm-worker.mjs`. Dieser ruft nach fünf Sekunden und danach ungefähr jede Minute lokal `POST /api/jobs/notdienstalarme` auf. Fristmeldungen entstehen dadurch auch ohne geöffneten Browser, normalerweise innerhalb einer Minute nach Fristende, zuzüglich Laufzeit und möglicher Ausfälle. Bei fehlendem Secret startet der allgemeine Produktionsstart ohne Fristjob und die Verwaltungsseite zeigt einen Hinweis; die Coolify-Vorlage verlangt das Secret. Ein zu kurzes gesetztes Secret stoppt den Produktionsstart. + +Bei einem anderen Hosting-Verfahren muss der Worker als eigener dauerhaft überwachter Prozess gestartet werden oder ein externer Scheduler die Route mindestens einmal pro Minute per POST und `Authorization: Bearer ` aufrufen. Nur `npm run start` startet den Worker nicht. Der Scheduler/Host muss auch nach Neustarts laufen; ein gesetztes Secret allein belegt keine laufende Fristprüfung. + +Der Job bearbeitet bis zu 100 Fristfälle und 100 E-Mail-Aufträge je Lauf. Wiederholte und gleichzeitige Aufrufe werden abgefangen: Fristmeldungen besitzen einen eindeutigen Ereignisschlüssel, Mailaufträge eine Versandreservierung und einen stabilen Idempotenzschlüssel. Versandfehler bleiben gespeichert und werden bei späteren Läufen erneut versucht; bereits angenommene Aufträge werden nicht erneut angefragt. Rollen- und Haushaltszuordnungen werden vor dem Versand erneut geprüft. Überholte Anfragen werden übersprungen. Provider-Garantien zur Idempotenz und tatsächliche Postfachzustellung bleiben Grenzen außerhalb der Anwendung. + +HTTP 401 bedeutet fehlende/falsche Berechtigung, 503 fehlendes/zu kurzes Job-Secret, 500 einen fehlgeschlagenen Lauf. HTTP 200 enthält die Bearbeitungszahlen einschließlich fehlgeschlagener E-Mails; die Versandübersicht und Server-/Worker-Logs sind für die Betriebsprüfung heranzuziehen. Bei Ausfall wird die Fristüberschreitung schon anhand der Uhrzeit in der Oberfläche angezeigt; E-Mail-Eskalation und Reservierungsfreigabe benötigen den nächsten erfolgreichen Joblauf. + +## Datenbank und vorhandene Alarme + +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). + +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. + +## Prüfung + +Abschließender Prüfstand: 20 Alarmtests, 17 Personal-Service-Tests und neun Berechnungstests erfolgreich; TypeScript, ESLint der betroffenen Dateien und Produktionsbuild erfolgreich. Das additive SQL-Upgrade wurde auf einem separaten Schema der isolierten Datenbank angewandt und per Prisma mit dem Zielmodell verglichen: keine Abweichungen. Worker und Jobroute wurden lokal geprüft (401 ohne Secret, 200 mit Secret, Fristmeldung je zuständigem Konto einmalig). Die vorhandenen globalen ESLint-Fehler in `auth-utils.ts` liegen außerhalb dieser Änderung. + +Automatisierte Alarmtests prüfen Rollen und Mandanten, gemeinsame und konkurrierende Antworten, Fristprüfung, Absagen, verspätete Freigaben, Stornierung, Tokens, Versandfehler/erneuten Versand, Altbestände sowie die Sperre vorhandener Plan- und Diensttausch-Aktionen. Sie benötigen ausdrücklich die isolierte lokale Testdatenbank `127.0.0.1:55439/kita_staff_test` und bereinigen nur ihre eigenen Test-Kitas. + +```sh +DATABASE_URL='postgresql://USER@127.0.0.1:55439/kita_staff_test' npm run test:alarms +npm run test:staff +``` + +Die Browserprüfung verwendet ausschließlich Demo-Daten und deaktivierten tatsächlichen E-Mail-Versand. Geprüft wurden Auslösen aus der Einteilung, Zeitfenster, Eltern-Dashboard-Hinweis, persönliche Rückmeldeseite mit expliziter Bestätigung und eine mobile Ansicht ohne horizontalen Überlauf. Produktive Zustellung und Deployment sind separat durchzuführen. diff --git a/docs/NOTDIENSTALARM_PLAN.md b/docs/NOTDIENSTALARM_PLAN.md new file mode 100644 index 0000000..f86cf78 --- /dev/null +++ b/docs/NOTDIENSTALARM_PLAN.md @@ -0,0 +1,109 @@ +# Notdienstalarm – abgestimmter Funktionsplan + +Stand: 09.10.2026 · Branch `codex/notdienstalarm` + +Status: Umgesetzt. Dieser Plan hält die abgestimmten Entscheidungen fest. Bedienung, Betriebsanforderungen und Prüfungen stehen in [NOTDIENSTALARM.md](NOTDIENSTALARM.md). + +## Festgelegter Umfang + +| Thema | Entscheidung | +| --- | --- | +| Zuständigkeit | Nur Kita-Admins und Notdienst-Koordination (`ADMIN`, `KOORDINATOR`) lösen Alarme aus und verwalten sie. | +| Erste Empfänger | Ausschließlich die für das Datum im veröffentlichten Notdienstplan eingeteilte Familie. Alle Elternkonten dieses Haushalts werden einzeln angeschrieben. | +| Rückmeldung | „Wir übernehmen“ oder „Wir können nicht“. Eine Antwort gilt für den gesamten Haushalt. | +| Kanäle | E-Mail und ein deutlich sichtbarer Hinweis in der App. | +| Antwortfrist | Standardmäßig 30 Minuten ab Auslösung; beim Auslösen anpassbar. | +| Einsatzdauer | Wahl zwischen „Ganzer Kita-Tag“ und „Bestimmte Uhrzeiten“ mit Beginn und Ende. | +| Fehlende Übernahme | Absage sofort, ausbleibende Antwort nach Fristablauf: „Klärung erforderlich“. Koordination informieren; Ersatz manuell organisieren. | + +## Ablauf in der Oberfläche + +### 1. Alarm auslösen + +Im veröffentlichten Notdienstplan erhält die Einteilung eine Aktion **Notdienstalarm auslösen**. Eine aktuelle Alarmübersicht ist zusätzlich über das Dashboard erreichbar. + +Der Dialog zeigt Datum, eingeteilte Familie und deren Empfängeradressen. Die auslösende Person wählt die Einsatzdauer, prüft die Antwortfrist und bestätigt den Versand. Bei **Bestimmte Uhrzeiten** sind Beginn und Ende Pflicht; Ende liegt nach Beginn. Bei **Ganzer Kita-Tag** sind keine künstlichen Uhrzeitangaben nötig. Die gewählte Dauer erscheint in der E-Mail und auf der Rückmeldeseite. + +Ein Alarm ist nur für heutige oder zukünftige Einteilungen eines veröffentlichten Plans der eigenen Kita möglich. Notdienst muss für die Kita aktiviert sein. Fehlende Elternkonten werden vor der Auslösung deutlich angezeigt. Eine aktive Alarmierung verhindert einen zweiten Alarm für dieselbe Einteilung. + +Optional kann die ausgefallene Fachkraft intern zugeordnet werden. Dies dient der Zuordnung und erzeugt keine automatische Krankheitsbuchung im Personalbereich. Private interne Notizen und Namen ausgefallener Fachkräfte gehören nicht in die Eltern-E-Mail. + +### 2. Familie informieren und Antwort erfassen + +Jedes Elternkonto erhält eine eigene E-Mail mit Kita, Datum, Einsatzdauer, Antwortfrist und persönlichem Rückmeldelink. Die Nachricht fragt eindeutig nach einer Übernahme. Alle Elternkonten des Haushalts sehen in der App denselben aktiven Alarm. + +Die Rückmeldeseite funktioniert wie bisher ohne Login über einen persönlichen Token. Das Öffnen des Links löst keine Zusage aus. Erst die ausdrückliche Auswahl von **Wir übernehmen** oder **Wir können nicht** mit Bestätigung schreibt die Antwort. + +Die Antwort wird am gemeinsamen Haushaltseinsatz gespeichert, einschließlich Zeitpunkt und antwortendem Elternkonto. Alle anderen Links zeigen anschließend die gemeinsame Antwort. Gleichzeitige gegensätzliche Antworten dürfen nicht beide wirksam werden. Eine bereits gespeicherte Antwort lässt sich nicht versehentlich durch einen zweiten Klick überschreiben. + +### 3. Stand verfolgen und Ersatz klären + +Die Alarmübersicht zeigt Datum, Dauer, Familie, Antwortfrist, gemeinsamen Rückmeldestatus und den Versandstand je Empfänger. Offene Alarme für heute werden besonders hervorgehoben. + +| Anzeige | Bedeutung und nächste Aktion | +| --- | --- | +| Antwort ausstehend | Familie wurde angefragt; die Antwortfrist läuft. | +| Übernahme bestätigt | Der Haushalt hat rechtzeitig zugesagt. Koordination und Admins sehen die Zusage. | +| Klärung erforderlich – Absage | Der Haushalt kann nicht übernehmen. Koordination organisiert Ersatz. | +| Klärung erforderlich – Frist abgelaufen | Es liegt keine Antwort vor. Koordination fasst nach oder organisiert Ersatz. | +| Storniert | Einsatz entfällt; Rückmeldelinks erlauben keine weitere Antwort. | + +Versandfehler sind ein eigener Zustand und dürfen nicht als Absage der Familie erscheinen. Eine fehlgeschlagene E-Mail wird deutlich angezeigt und kann erneut versendet werden; andere Empfänger werden trotzdem bedient. + +Bei Absage oder Fristablauf erhalten zuständige Koordinations- und Admin-Konten derselben Kita einen Hinweis in der App und eine E-Mail. Die Fristmeldung wird je Alarm einmal erzeugt. Die Koordination organisiert Ersatz in dieser Version manuell; weitere Familien werden nicht automatisch alarmiert. + +## Vorgeschlagene Ausgestaltung für Sonderfälle + +Diese Details ergänzen die Nutzerentscheidungen als Umsetzungsvorschlag: + +- **Verspätete Zusage:** Nach Fristablauf bleibt eine Rückmeldung möglich, solange der Einsatz läuft und der Alarm nicht storniert ist. Eine verspätete Zusage wird als solche angezeigt und muss von der Koordination bestätigt werden, damit sie nicht mit bereits organisiertem Ersatz kollidiert. +- **Telefonische Rückmeldung:** Admin oder Koordination kann eine Zusage bzw. Absage für den Haushalt dokumentieren. Herkunft, handelndes Konto und Zeitpunkt bleiben nachvollziehbar. +- **Antwort ändern:** Eine bereits dokumentierte Antwort wird nur durch Admin oder Koordination korrigiert. Eltern erhalten auf der Rückmeldeseite einen Hinweis, die Kita bei Änderungen zu kontaktieren. +- **Stornieren:** Admin oder Koordination storniert mit einer internen Begründung. Alle angeschriebenen Elternkonten werden informiert; offene Links werden unwirksam. Eine neue Alarmierung derselben Einteilung ist danach als neuer Vorgang möglich. +- **Token-Ende:** Für einen ganzen Kita-Tag endet die Rückmeldemöglichkeit spätestens mit dem Datum in Europe/Berlin; bei bestimmten Uhrzeiten mit dem Einsatzende. Die 30-Minuten-Frist für Eskalation ist davon unabhängig. +- **Planänderungen und Tausch:** Aktive Alarme schützen die zugehörige Einteilung vor einem unbemerkten Familienwechsel oder Diensttausch. Ersatz darf nicht durch Änderung eines noch aktiven Alarms auf eine andere Familie übertragen werden. +- **Erinnerung und erneuter Versand:** Eine Wiederholung startet die Antwortfrist nicht automatisch neu. E-Mail-Annahme durch den Versanddienst, Rückmeldung und tatsächliche Anwesenheit bleiben getrennte Informationen. + +## Technische Umsetzung + +Der bestehende `NotdienstAlert` speichert pro Elternkonto einen unabhängigen Status. Für die gemeinsame Haushaltsantwort wird ein übergeordneter Alarmvorgang benötigt; Empfänger, Tokens und Versandversuche sind untergeordnet. Bestehende Datensätze müssen bei der Schemaumstellung berücksichtigt werden, ohne widersprüchliche Einzelantworten als sichere Haushaltszusage zu übernehmen. + +Am Vorgang werden Einteilung und Haushalt, auslösendes Konto, Zeitpunkt, Einsatzart, gegebenenfalls Uhrzeiten, Antwortfrist, gemeinsame Antwort, interne Zuordnung und Stornierungsdaten festgehalten. Empfängerdatensätze führen persönliche Tokens und deren Gültigkeit. Historie und Versandaufträge erlauben Wiederholung und nachvollziehbare Änderungen. + +Alle Aktionen prüfen aktuelle Datenbankrolle, Kita-Zugehörigkeit und Zugriff serverseitig. Auslösung und gemeinsame Rückmeldung laufen transaktional. Eine Datenbanksicherung verhindert mehrere aktive Alarme für dieselbe Einteilung sowie widersprüchliche parallele Antworten. + +Der Versand verwendet die vorhandene Resend-Anbindung mit persistenten Versandaufträgen. Elternmails enthalten ausschließlich notwendige Einsatzdaten. Interne Begründungen, Krankheitsdetails und Daten aus Personalzeitkonten werden nicht übernommen. Alarm-E-Mails sind unabhängig von der Abschalteinstellung für Personal-Entscheidungsmails. + +Die Fristüberwachung braucht eine regelmäßig aufgerufene serverseitige Prüfung, auch wenn niemand die App geöffnet hat. Vorgesehen ist ein geschützter, einmal pro Minute aufgerufener Serverjob. Die Anzeige berechnet Fristablauf zusätzlich direkt aus der gespeicherten Antwortfrist. Die Benachrichtigung kann durch das Prüfintervall und den Mailtransport etwas nach Ablauf eintreffen. Für die Einführung muss der Job in der Hosting-Umgebung eingerichtet werden. + +## Umsetzungsschritte + +1. Gemeinsamen Alarmvorgang, Empfänger, Tokens, Verlauf und Schemaumstellung ergänzen. +2. Auslösung, Haushaltsantwort, Korrektur, Stornierung und erneuten Versand absichern. +3. E-Mail-Vorlagen, Versandaufträge und Benachrichtigung der Koordination anbinden. +4. Alarmdialog, Rückmeldeseite, Dashboard-Hinweise und Statusübersicht umsetzen. +5. Fristprüfung, Hosting-Konfiguration und Einführungsdokumentation ergänzen. +6. Gemeinsame Haushaltsantworten, Fristen, Rollen, Versandfehler und Browserabläufe prüfen. + +## Abnahmefälle + +- Admin und Koordination dürfen auslösen; Eltern, Fachkräfte und Konten anderer Kitas dürfen es nicht. +- Nur die im veröffentlichten Plan eingeteilte Familie wird zunächst angeschrieben. +- Ganzer Kita-Tag und bestimmte Uhrzeiten erscheinen in E-Mail, App und Rückmeldeseite konsistent. +- Eine Zusage oder Absage wirkt auf den gesamten Haushalt; weitere persönliche Links zeigen denselben Stand. +- Zwei gleichzeitige Antworten, doppelte Auslösung und Fristprüfung erzeugen keine doppelten Vorgänge oder widersprüchlichen Zusagen. +- Absage erzeugt sofort Klärungsbedarf; Fristablauf nach 30 Minuten erzeugt ihn auch bei geschlossener App. +- Versandfehler verhindern keine Speicherung, unterbrechen nicht den Versand an weitere Empfänger und lassen sich gezielt wiederholen. +- Verspätete Antwort, telefonisch dokumentierte Antwort und Stornierung bleiben nachvollziehbar. +- Stornierte und zeitlich abgelaufene Links können keinen aktiven Einsatz zusagen. +- Aktive Alarme schützen Einteilungen vor unbemerktem Tausch oder Familienwechsel. + +## Vorhandene Grundlage + +- `src/app/dashboard/actions.ts`: Auslösung und E-Mail-Versand, bisher ein separater Alarm pro Elternkonto. +- `src/app/dashboard/alert-button.tsx`: Vorbereiteter, noch nicht eingebundener Auslösebutton. +- `src/app/alert/[token]/`: Rückmeldeseite und Bestätigung, bisher nur Zusage und ohne zeitliche Token-Gültigkeit. +- `src/app/dashboard/kalender/actions.ts`: Bestehender Tauschausschluss für aktive Alarmierungen. +- `src/lib/mail.ts` und `src/lib/staff/email.ts`: Mailtransport sowie Vorlage für persistente, wiederholbare Versandaufträge. + +Die Planung löst keine Alarme aus und versendet keine E-Mails. diff --git a/docs/PERSONALBEREICH.md b/docs/PERSONALBEREICH.md new file mode 100644 index 0000000..1bc9b10 --- /dev/null +++ b/docs/PERSONALBEREICH.md @@ -0,0 +1,118 @@ +# Personalbereich: Arbeitszeit, Urlaub und Zeitkonto + +Stand: 09.10.2026 + +## Einstieg und Zuständigkeiten + +Der Bereich liegt unter `/dashboard/personal`. Kita-Admins (einschließlich Vorstand mit Rolle `ADMIN`) verwalten alle Personalprofile ihrer Kita. ErzieherInnen bearbeiten eigene Zeiten und Anträge. Eltern und Koordination haben keinen Zugriff. Der interne Teamkalender ist nur für Admins und ErzieherInnen zugänglich. + +Neue Fachkräfte werden unter **ErzieherInnen → ErzieherIn anlegen** in einem Formular eingerichtet: + +1. Vorname, Nachname und E-Mail-Adresse (Pflichtfelder). +2. Tatsächlicher Beschäftigungsbeginn und separat der Start der Zeiterfassung (vorbelegt mit heute, änderbar). Die Erfassung darf nicht vor der Beschäftigung beginnen. +3. **Fachkraft anlegen und einladen** speichert Stammdaten, Personalprofil, Accountverknüpfung und Mailauftrag gemeinsam in einer Transaktion. Unpassende oder schon verknüpfte E-Mail-Adressen verhindern die gesamte Anlage. +4. Anschließend öffnet sich das Personalprofil. Dort werden datierte Netto-Sollstunden für Montag bis Sonntag, Jahresurlaub und ausdrücklich festgelegter Übertrag sowie vorhandene Überstunden eingerichtet. Der Anfangssaldo startet mit 0 Minuten und muss bei vorhandenen Überstunden vor der ersten Zeiterfassung angepasst werden. +5. Die örtlichen Feiertage werden unter **Teamkalender** hinterlegt. Sie gelten separat von den Schließtagen des allgemeinen Kalenders. + +Vorhandene Fachkräfte können ihre fehlende E-Mail und gegebenenfalls die beiden Startdaten direkt über **Bearbeiten** erhalten. Bereits eingerichtete Beschäftigungsdaten, Wochenmodelle und Konten bleiben dabei erhalten. Die E-Mail eines verknüpften Accounts wird angezeigt und kann im Stammdatendialog nicht geändert werden; Namensänderungen werden auch im verknüpften Fachkraft-Account übernommen. + +Die Teamübersicht zeigt E-Mail und Zugangszustand: **Zugang fehlt**, **Einladung ausstehend**, **Account aktiviert** oder **Mailversand fehlgeschlagen**. Für offene Einladungen steht **Einladung erneut senden** zur Verfügung. Ein neuer Link ersetzt den alten. Ein Mailfehler entfernt keine Fachkraft: Er bleibt sichtbar, der Versand kann erneut angestoßen werden. Im Personalbereich kann außerdem der bestehende Mailauftrag erneut versucht werden. + +Der Aktivierungsablauf verwendet die bestehende Passwort- und Consent-Einrichtung unter `/invite/[token]`. Neue Accounts erhalten einen persönlichen, einmal verwendbaren Aktivierungslink mit sieben Tagen Gültigkeit per E-Mail; im Personalprofil kann der Admin zusätzlich einen Link zum Kopieren erzeugen. Ein vorhandener verifizierter Fachkraft-Account derselben Kita ohne andere Profilverknüpfung wird verbunden, ohne eine Aktivierungsmail zu verschicken. Accounts anderer Kitas oder Rollen werden nicht übernommen. + +Die gemeinsame Anlage benötigt keine zusätzlichen Datenbankfelder oder Umgebungsvariablen. Sie verwendet die bestehende Resend-Anbindung; siehe [Deployment und Mailversand](../deploy/DEPLOYMENT_UND_MAILVERSAND.md). + +## Arbeitszeit und Überstunden + +Pro Tag sind mehrere Arbeitsblöcke mit Beginn, Ende und Pause möglich. Zeitblöcke dürfen nicht überlappen. Die Pause wird in Minuten vom Block abgezogen. Zeiten werden für heutige oder vergangene Tage innerhalb der Beschäftigung und ab Erfassungsbeginn erfasst. Blöcke über Mitternacht werden auf zwei Tage aufgeteilt. + +Die Tagesbilanz ist **Istzeit + Urlaub/Krankheit − Sollzeit**. Arbeit an einem freien Tag oder Feiertag zählt als zusätzliche Istzeit. Die Wochenansicht zeigt alle sieben Tage; in einer laufenden Woche fehlen zukünftige Arbeitszeiten noch, deshalb ist ihre Differenz vorläufig. + +Die Fachkraft reicht ihre Woche nach dem letzten vorgesehenen Arbeitstag ein. Offene Abwesenheiten im Zeitraum müssen zuerst geklärt sein. Der Admin prüft die einzelnen Zeiten, genehmigt die Woche oder gibt sie mit Rückmeldung zurück. Eingereichte und genehmigte Wochen sperren Zeitänderungen. Eigene Wochen und eigene Anträge können nicht selbst freigegeben werden. + +Beim Genehmigen wird die Tagesberechnung gespeichert. Nur genehmigte Wochen, der Anfangssaldo und wirksame manuelle Korrekturen zählen zum bestätigten Zeitkonto. Offene oder eingereichte Wochen wirken noch nicht auf dieses Konto. Eine Rückgabe entfernt die Wochenbuchung bis zur erneuten Freigabe. Fehler in manuellen Korrekturen werden durch eine begründete Gegenbuchung behoben. + +## Feste Wochentage und seltene Wechsel + +Wochenmodelle gelten ab ihrem Datum. Eine spätere Änderung überschreibt kein früheres Modell. Seltene Tausche werden über zwei Tagesausnahmen erfasst: der bisherige Arbeitstag erhält 0 Sollstunden, der Ersatztermin die vorgesehenen Stunden. + +Genehmigte Abwesenheiten sowie eingereichte oder genehmigte Wochen schützen ihren Zeitraum auch vor Änderungen an Modellen, Ausnahmen und Feiertagen. Betroffene Freigaben müssen vor einer solchen Änderung zurückgegeben bzw. storniert werden. Grunddaten und Anfangssaldo werden nach der ersten Erfassung geschützt; das Beschäftigungsende bleibt über einen eigenen Ablauf verwaltbar, sofern bestehende Zeiten und Anträge nicht verletzt werden. + +## Urlaub + +Urlaub ist ganztägig oder für einen einzelnen halben Tag möglich. Nur vorgesehene Arbeitstage verbrauchen Urlaub. Wochenenden sind nicht pauschal frei: Entscheidend sind Wochenmodell und Tagesausnahmen. Feiertage verbrauchen keinen Urlaub und erzeugen keine Sollzeit. Ein halber Urlaubstag schreibt die Hälfte der Tages-Sollzeit gut; bei ungerader Minutenzahl wird auf eine ganze Minute gerundet. + +Ein Jahreskonto führt Anspruch plus Übertrag, genommenen Urlaub, genehmigten geplanten Urlaub, offene Anträge und verfügbaren Rest. Offene Anträge werden bei weiteren Anträgen berücksichtigt. Abgelehnte und stornierte Anträge verbrauchen nichts. Zeiträume über den Jahreswechsel werden auf die jeweiligen Jahreskonten verteilt. Anspruch und Übertrag werden nicht automatisch anteilig berechnet oder zum Jahreswechsel übertragen. + +Offene Anträge können geändert oder zurückgezogen werden. Bei genehmigten Anträgen wird eine Stornierung beantragt. Bis zur Entscheidung bleibt die Abwesenheit gebucht. Krankheit hinterlegt der Admin; sie entlastet die Sollzeit, ohne Urlaub zu verbrauchen. KollegInnen sehen Krankheit im Teamkalender nur als **Abwesend**, ohne persönliche Notizen oder Kontodaten. + +## Freizeitausgleich + +Freizeitausgleich wird für einen einzelnen vorgesehenen Arbeitstag in Stunden beantragt. Das bestätigte verfügbare Guthaben muss ausreichen; weitere offene Anträge werden dabei berücksichtigt. + +Nach Genehmigung wird die Zeit reserviert. Freizeitausgleich erzeugt keine zusätzliche Istzeit oder Urlaubsgutschrift. Beispiel: 6 Stunden Soll, 5 Stunden Arbeit und 1 Stunde Freizeitausgleich ergeben eine Tagesbilanz von −1 Stunde. Mit der Wochenfreigabe wird diese Stunde im Zeitkonto gebucht und die Reservierung entfällt. Dadurch wird die Stunde genau einmal abgezogen. Bei offenen Stornierungen bleibt die Reservierung erhalten. + +## Hinweise und Nachvollziehbarkeit + +Neue Anträge und eingereichte Wochen erzeugen interne Hinweise für Kita-Admins. Entscheidungen und Rückgaben erzeugen Hinweise für die betroffene Fachkraft. Hinweise lassen sich als gelesen markieren; jede Person kann ausschließlich eigene Hinweise quittieren. Das Personalprofil zeigt die letzten 30 Änderungen. Im Datenmodell werden sämtliche Änderungen mit Zeitpunkt und handelnder User-ID gespeichert. + +Parallele Änderungen laufen in serialisierbaren Datenbanktransaktionen mit Wiederholung bei Schreibkonflikten. Rollen, Accountstatus, Eigentümer und Kita-Zugehörigkeit werden serverseitig geprüft. Das Löschen von Fachkräften mit Personalprofil wird verhindert; sie können auf inaktiv gesetzt werden. Bei Accountlöschung bleiben Personalaufzeichnungen ohne Accountverknüpfung erhalten. Die Löschung einer Kita entfernt auch ihren Personalbereich. + +## 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. + +- 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 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. + +## Prüfungen + +- `npm run test:staff`: Berechnungstests für Teilzeit, halbe Tage, Feiertage, Jahreswechsel, Statuswechsel, Pausen, Snapshots und Freizeitausgleich. +- `npm run test:staff:integration`: echte Datenbankabläufe für Mandantentrennung, Rollen und Eigentümer, Anträge, Freigaben, parallele Änderungen, Sperren, Rückgaben, Aktivierungslinks und Beschäftigungsende. +- Integrationstests akzeptieren ausschließlich `127.0.0.1:55439/kita_staff_test`. Beispiel: `DATABASE_URL=postgresql://USER@127.0.0.1:55439/kita_staff_test npm run test:staff:integration`. Die leere Testdatenbank vorher mit dem aktuellen Schema einrichten. Tests bereinigen nur ihre eigens erzeugten Testkitas. +- Browserprüfung: Admin richtet Profil, 18-Stunden-Woche und 18 Urlaubstage ein; Erzieherin erfasst drei Blöcke mit Pausen, reicht eine 19-Stunden-Woche ein und beantragt einen Urlaubstag. Nach Adminfreigabe zeigt das Zeitkonto 11 Stunden (10 Stunden Anfangssaldo + 1 Stunde Wochenplus) und das Urlaubskonto 17 Tage. Der Urlaub erscheint im Teamkalender. + +Ergebnisse der abschließenden Prüfung: + +| Prüfung | Ergebnis | +| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Berechnungstests | 9 bestanden. | +| Integrationstests | 25 bestanden; einschließlich gemeinsamer Anlage, vollständigem Rollback bei E-Mail-Konflikten, Bearbeitung bestehender Fachkräfte, Kontenschutz, Rollenprüfung und Empfänger, Opt-out, Versandfehler, Token-Erneuerung und paralleler Versandversuche. Testkitas danach bereinigt. | +| TypeScript | Erfolgreich. | +| ESLint für sämtliche geänderten Anwendungsteile und neue Tests | Erfolgreich, ohne Warnungen. | +| Projektweites ESLint | Die bereits vorhandenen zwei `as any`-Fehler in `src/lib/auth-utils.ts` und neun Warnungen bestehen weiterhin. | +| Endgültiger Produktionsbuild | Erfolgreich, einschließlich `/dashboard/personal`. | +| Vollständiges und inkrementelles SQL-Skript | Erfolgreich in isolierten Prüfschemata; anschließend jeweils kein Unterschied zum Prisma-Schema. | +| Browser | Admin- und ErzieherInnen-Ablauf einschließlich Freigaben erfolgreich. Mobile Ansicht und Arbeitszeitdialog ohne Seitenüberlauf geprüft. Abschalten der E-Mail-Hinweise im Demo-Profil gespeichert und nach Neuladen verifiziert; anschließend wieder eingeschaltet. | + +Die vom bestehenden Build gemeldete Warnung zu mehreren Lockfiles bzw. dem Turbopack-Arbeitsverzeichnis und die bestehende Prisma-Konfigurationswarnung sind unabhängig vom Personalbereich. Eine produktive Bereitstellung oder Mailzustellung wurde nicht durchgeführt. + +## Prüfung der gemeinsamen Fachkraft-Anlage (09.10.2026) + +- 25 Personal-Integrationstests, TypeScript, ESLint der geänderten Anwendungsteile und Produktionsbuild erfolgreich. +- Lokale Browserprüfung mit synthetischen Daten: Datum vor Beschäftigungsbeginn abgewiesen, Eingaben erhalten, korrigierte Anlage erfolgreich und unmittelbar zum Personalprofil weitergeleitet. +- Resend im lokalen Produktionsbuild bewusst deaktiviert: gespeicherte Fachkraft und wiederholbarer Mailfehler in Personalbereich und Teamliste sichtbar; erneute Einladung aus der Teamliste erfolgreich ausgelöst. +- Bestehende Fachkraft ohne Zugang zeigt E-Mail und fehlende Startdaten direkt im Bearbeitungsdialog. Mobilprüfung bei 390 × 844 Pixeln: Dialog ohne horizontalen Überlauf, längerer Inhalt innerhalb des Dialogs scrollbar. +- Keine echten Aktivierungsmails versendet; keine Änderung an Produktionsdaten vorgenommen. + +## E-Mail-Hinweise + +Die E-Mail-Erweiterung wurde am 08.10.2026 ausdrücklich beauftragt. Sie verwendet die vorhandene Resend-Anbindung: + +| Nachricht | Empfänger | Inhalt | +| ------------------------------------------------------------- | -------------------------------------------------------- | ---------------------------------------------------------------------- | +| Accountaktivierung | Vom Kita-Admin eingetragene E-Mail-Adresse der Fachkraft | Kita, Name, persönlicher Aktivierungslink mit sieben Tagen Gültigkeit. | +| Antrag / Änderung / Stornierung oder Arbeitswoche eingereicht | Alle Kita-Admins derselben Kita, einzeln angeschrieben | Name, Zeitraum und Hinweis auf Prüfung im geschützten Personalbereich. | +| Entscheidung / Rückgabe | Account-Adresse der betroffenen Fachkraft | Art, Zeitraum und Status mit Link in den geschützten Personalbereich. | + +Fachkräfte können Entscheidungsmails unter **Mein Profil → E-Mail-Hinweise** abschalten. Aktivierungslinks und interne App-Hinweise bleiben davon unabhängig. Krankheitsbuchungen erzeugen keine E-Mail. Private Notizen, Entscheidungsbegründungen und Zeit- oder Urlaubskontostände werden nicht per E-Mail übertragen. + +Versandaufträge werden innerhalb derselben Datenbanktransaktion wie die Personalaktion gespeichert. Der Versand erfolgt anschließend; ein Fehler macht den gespeicherten Antrag nicht rückgängig. Ausstehende Mails erscheinen im Personalbereich mit **Versand erneut versuchen**. Admins dürfen die Aufträge ihrer Kita wiederholen, Fachkräfte nur eigene. Pro Aktion werden bis zu 50 ausstehende Aufträge verarbeitet. Es gibt keinen zusätzlichen Hintergrundjob. + +Vor jedem Versand werden Kita-Zugehörigkeit, aktuelle Rolle, Accountverknüpfung und gegebenenfalls die Abschalteinstellung geprüft. Ersetzte, abgelaufene oder bereits verwendete Aktivierungslinks werden übersprungen. Eine fünfminütige Versandsperre verhindert parallele Versuche für denselben Auftrag; ein stabiler Resend-Idempotenzschlüssel vermindert doppelte Zustellungen bei Wiederholungen. Eine Zustellbestätigung des Empfängerpostfachs wird nicht erfasst. + +Benötigt werden `RESEND_API_KEY`, `EMAIL_FROM` und eine öffentliche App-Adresse über `NEXT_PUBLIC_SITE_URL`, alternativ `AUTH_URL` oder `NEXTAUTH_URL`. Ohne Konfiguration bleibt ein Produktionsversand ausstehend und wird als Warnung angezeigt. Im Entwicklungsmodus ohne Resend-Schlüssel wird der bestehende lokale Mailtransport simuliert. Die Tests verwenden ausschließlich einen eingesetzten Testtransport; es wurden keine echten E-Mails verschickt. diff --git a/docs/elternablaeufe.md b/docs/elternablaeufe.md new file mode 100644 index 0000000..9261157 --- /dev/null +++ b/docs/elternablaeufe.md @@ -0,0 +1,39 @@ +# Elternabläufe: Mitteilungen und Teilnahmeantworten + +## Verhalten + +- Die Übersicht zeigt offene Rückmeldungen und drei aktuelle Mitteilungen. Das Archiv unter `/dashboard/mitteilungen` enthält alle für das eigene Konto sichtbaren Meldungen, zwölf pro Seite. +- Termine können eine Antwort pro Kind oder pro Familie verlangen. Familienzusagen brauchen mindestens einen teilnehmenden Erwachsenen; Absagen speichern 0 Erwachsene. Beide Elternkonten bearbeiten dieselbe Antwort. +- Die Terminart schlägt bei neuen Terminen eine Antwortart vor. Die Verwaltung kann sie ändern, solange keine Antworten vorliegen. Danach verhindert auch die Server Action einen Wechsel. Normale Terminänderungen erhalten die bisherigen Teilnahmefelder. +- Kinderantworten werden für alle eigenen aktiven Kinder gemeinsam in einer Transaktion gespeichert. Eigene und fremde Kinder dürfen nicht gemischt werden. Frist, Terminstatus, Haushalt, Kita und aktiviertes Terminmodul werden serverseitig geprüft. +- Ohne eigene Rückmeldefrist gilt der Terminbeginn. Nach Fristablauf bleiben die Antworten im Kalender lesbar. Die Eingabe ist in Monatsansicht, Liste und Agenda erreichbar. +- Empfängergruppen sind Eltern, ErzieherInnen oder beide. Die Gruppe steuert App-Anzeige, Lesestatus-Aktion, Anhänge und optionalen E-Mail-Versand. Admins können sämtliche Meldungen der eigenen Kita zur Verwaltung sehen. Eltern mit Koordinationsrolle gehören mit ihrem Haushalt zur Elterngruppe; Erzieherkonten gehören zur Erziehergruppe. +- Teilnehmerhinweise werden nur bei einer Zusage des Haushalts oder für Admin/Koordination an den Kalender-Client übertragen. + +## Bestehende Daten und Schemaaktualisierung + +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. + +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: + +```sh +psql "$DATABASE_URL" -v ON_ERROR_STOP=1 --single-transaction -f prisma/updates/20261007_parent_flows.sql +npm run prisma:generate +``` + +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. + +## Verifikation + +```sh +npm run test:parent-flows +TEST_DATABASE_URL=postgresql://USER@127.0.0.1:PORT/TESTDB npm run test:parent-flows:integration +npx tsc --noEmit +npm run build +``` + +Die Integrationstests benötigen eine Node.js-Version mit experimentellem Modul-Mocking (hier geprüft mit Node.js 26), eine ausdrücklich über `TEST_DATABASE_URL` gesetzte lokale PostgreSQL-Testdatenbank und das aktuelle Schema. Sie legen eigene Kitas mit zufälligen IDs an und entfernen ausschließlich diese Testkitas wieder. Kein automatischer Zugriff auf `DATABASE_URL` ohne Testfreigabe. + +Die Tests prüfen Erwachsenenanzahl, gemischte Kinderantworten, gemeinsame Familienantworten, Fristablauf, Terminabsage, Moduldeaktivierung, Kita-/Haushaltsgrenzen, gesperrte Antwortart einschließlich paralleler erster Rückmeldung, erhaltene Terminoptionen sowie verweigerte Team-Meldungen und Anhänge für Eltern. E-Mail-Empfänger werden anhand derselben Gruppenregeln geprüft; es werden keine echten E-Mails verschickt. + +Zusätzlich im Browser geprüft: Familienzusage, unterschiedliche Antworten für zwei Kinder, verschwundene offene Hinweise, Lesen/Ändern der gemeinsamen Antwort aus einem zweiten Elternkonto, abgelaufene Eingabe, Kalender-Monats- und Agendaansicht, Lesestatus, Archivnavigation, Verwaltungsauswertung, gesperrte Antwortart und Eltern-/Erzieher-Empfängertrennung. Die Rückmeldeformulare und Übersicht wurden auch bei 390 Pixeln Breite visuell geprüft. diff --git a/package.json b/package.json index c9824c3..eed8161 100644 --- a/package.json +++ b/package.json @@ -7,7 +7,7 @@ "build": "next build && node scripts/prepare-standalone.mjs", "build:prod": "prisma generate && next build && node scripts/prepare-standalone.mjs", "start": "next start", - "start:prod": "node .next/standalone/server.js", + "start:prod": "sh .next/standalone/scripts/start-production.sh", "lint": "eslint", "prisma:generate": "prisma generate", "prisma:migrate": "prisma migrate dev", @@ -19,7 +19,12 @@ "db:provision-runtime": "node scripts/provision-runtime-role.mjs", "uploads:backfill": "tsx scripts/backfill-attachment-sizes.ts", "uploads:cleanup": "tsx scripts/cleanup-attachments.ts", - "test:security:http": "node tests/security-http.cjs" + "test:security:http": "node tests/security-http.cjs", + "test:staff": "tsx --test tests/staff-calculations.test.ts", + "test:staff:integration": "tsx --test tests/staff-service.test.ts", + "test:alarms": "tsx --experimental-test-module-mocks --test tests/notdienst-alarm.test.ts", + "test:parent-flows": "tsx --test tests/parent-flows.test.ts", + "test:parent-flows:integration": "tsx --experimental-test-module-mocks --test tests/parent-flows.integration.test.ts" }, "prisma": { "seed": "tsx prisma/seed.ts" diff --git a/prisma/migrations/20261009040000_current_features/migration.sql b/prisma/migrations/20261009040000_current_features/migration.sql new file mode 100644 index 0000000..d2f203d --- /dev/null +++ b/prisma/migrations/20261009040000_current_features/migration.sql @@ -0,0 +1,483 @@ +BEGIN; +-- CreateEnum +CREATE TYPE "RsvpMode" AS ENUM ('CHILD', 'FAMILY'); + +-- CreateEnum +CREATE TYPE "AnnouncementAudience" AS ENUM ('ELTERN', 'ERZIEHER', 'ALLE'); + +-- CreateEnum +CREATE TYPE "NotdienstAlarmStatus" AS ENUM ('PENDING', 'CONFIRMED', 'DECLINED', 'LATE_CONFIRMATION', 'REVIEW_REQUIRED', 'CANCELLED'); + +-- CreateEnum +CREATE TYPE "StaffRequestStatus" AS ENUM ('PENDING', 'APPROVED', 'REJECTED', 'CANCEL_REQUESTED', 'CANCELLED'); + +-- CreateEnum +CREATE TYPE "StaffLeaveKind" AS ENUM ('VACATION', 'TIME_OFF', 'SICKNESS'); + +-- CreateEnum +CREATE TYPE "StaffWeekStatus" AS ENUM ('DRAFT', 'SUBMITTED', 'APPROVED'); + +-- AlterTable +ALTER TABLE "users" ADD COLUMN "staffDecisionEmails" BOOLEAN NOT NULL DEFAULT true; + +-- AlterTable +ALTER TABLE "announcements" ADD COLUMN "audience" "AnnouncementAudience" NOT NULL DEFAULT 'ALLE'; + +-- AlterTable +ALTER TABLE "termine" ADD COLUMN "rsvpMode" "RsvpMode" NOT NULL DEFAULT 'CHILD'; + +-- AlterTable +ALTER TABLE "notdienst_alerts" ADD COLUMN "alarmId" TEXT; + +-- CreateTable +CREATE TABLE "staff_profiles" ( + "id" TEXT NOT NULL, + "kitaId" TEXT NOT NULL, + "educatorId" TEXT NOT NULL, + "userId" TEXT, + "employmentStart" DATE NOT NULL, + "employmentEnd" DATE, + "trackingStart" DATE NOT NULL, + "openingMinutes" INTEGER NOT NULL DEFAULT 0, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_profiles_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_emails" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "toAdmins" BOOLEAN NOT NULL DEFAULT false, + "subject" TEXT NOT NULL, + "message" TEXT NOT NULL, + "path" TEXT NOT NULL, + "inviteToken" TEXT, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "sentAt" TIMESTAMP(3), + "skippedAt" TIMESTAMP(3), + "leaseUntil" TIMESTAMP(3), + "attempts" INTEGER NOT NULL DEFAULT 0, + "failed" BOOLEAN NOT NULL DEFAULT false, + + CONSTRAINT "staff_emails_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_work_patterns" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "effectiveFrom" DATE NOT NULL, + "dailyMinutes" INTEGER[], + + CONSTRAINT "staff_work_patterns_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_day_overrides" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "date" DATE NOT NULL, + "minutes" INTEGER NOT NULL, + "reason" TEXT NOT NULL, + + CONSTRAINT "staff_day_overrides_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_holidays" ( + "id" TEXT NOT NULL, + "kitaId" TEXT NOT NULL, + "date" DATE NOT NULL, + "name" TEXT NOT NULL, + + CONSTRAINT "staff_holidays_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_leave_accounts" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "year" INTEGER NOT NULL, + "entitlementUnits" INTEGER NOT NULL, + "carryUnits" INTEGER NOT NULL DEFAULT 0, + + CONSTRAINT "staff_leave_accounts_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_leaves" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "kind" "StaffLeaveKind" NOT NULL, + "status" "StaffRequestStatus" NOT NULL DEFAULT 'PENDING', + "startDate" DATE NOT NULL, + "endDate" DATE NOT NULL, + "halfDay" BOOLEAN NOT NULL DEFAULT false, + "minutes" INTEGER, + "note" TEXT, + "decisionNote" TEXT, + "requestedById" TEXT NOT NULL, + "reviewedById" TEXT, + "reviewedAt" TIMESTAMP(3), + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_leaves_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_leave_days" ( + "id" TEXT NOT NULL, + "leaveId" TEXT NOT NULL, + "date" DATE NOT NULL, + "vacationUnits" INTEGER NOT NULL DEFAULT 0, + "creditMinutes" INTEGER NOT NULL, + + CONSTRAINT "staff_leave_days_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_time_entries" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "date" DATE NOT NULL, + "startMinute" INTEGER NOT NULL, + "endMinute" INTEGER NOT NULL, + "breakMinutes" INTEGER NOT NULL DEFAULT 0, + "note" TEXT, + + CONSTRAINT "staff_time_entries_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_weeks" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "weekStart" DATE NOT NULL, + "status" "StaffWeekStatus" NOT NULL DEFAULT 'DRAFT', + "submittedAt" TIMESTAMP(3), + "reviewedAt" TIMESTAMP(3), + "reviewedById" TEXT, + "decisionNote" TEXT, + "dailySnapshot" JSONB, + + CONSTRAINT "staff_weeks_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_adjustments" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "date" DATE NOT NULL, + "minutes" INTEGER NOT NULL, + "reason" TEXT NOT NULL, + "actorId" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_adjustments_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_history" ( + "id" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "actorId" TEXT NOT NULL, + "action" TEXT NOT NULL, + "details" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_history_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "staff_notifications" ( + "id" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "profileId" TEXT NOT NULL, + "message" TEXT NOT NULL, + "readAt" TIMESTAMP(3), + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "staff_notifications_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "family_event_participations" ( + "id" TEXT NOT NULL, + "kitaId" TEXT NOT NULL, + "eventId" TEXT NOT NULL, + "familyId" TEXT NOT NULL, + "status" "EventParticipationStatus" NOT NULL, + "adultCount" INTEGER NOT NULL DEFAULT 0, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "updatedAt" TIMESTAMP(3) NOT NULL, + + CONSTRAINT "family_event_participations_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarms" ( + "id" TEXT NOT NULL, + "kitaId" TEXT NOT NULL, + "assignmentId" TEXT, + "activeAssignmentId" TEXT, + "familyId" TEXT NOT NULL, + "familyName" TEXT NOT NULL, + "childName" TEXT NOT NULL, + "date" DATE NOT NULL, + "wholeDay" BOOLEAN NOT NULL DEFAULT true, + "startMinute" INTEGER, + "endMinute" INTEGER, + "expiresAt" TIMESTAMP(3) NOT NULL, + "deadline" TIMESTAMP(3) NOT NULL, + "status" "NotdienstAlarmStatus" NOT NULL DEFAULT 'PENDING', + "triggeredById" TEXT, + "triggeredAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "respondedById" TEXT, + "respondedAt" TIMESTAMP(3), + "responseSource" TEXT, + "escalatedAt" TIMESTAMP(3), + "educatorId" TEXT, + "notes" TEXT, + "cancelledAt" TIMESTAMP(3), + "cancelReason" TEXT, + + CONSTRAINT "notdienst_alarms_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarm_recipients" ( + "id" TEXT NOT NULL, + "alarmId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "token" TEXT NOT NULL, + "sessionVersion" INTEGER NOT NULL DEFAULT 0, + + CONSTRAINT "notdienst_alarm_recipients_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarm_notifications" ( + "id" TEXT NOT NULL, + "alarmId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "eventKey" TEXT NOT NULL, + "message" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "readAt" TIMESTAMP(3), + + CONSTRAINT "notdienst_alarm_notifications_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarm_emails" ( + "id" TEXT NOT NULL, + "alarmId" TEXT NOT NULL, + "userId" TEXT NOT NULL, + "eventKey" TEXT NOT NULL, + "kind" TEXT NOT NULL, + "subject" TEXT NOT NULL, + "message" TEXT NOT NULL, + "path" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "sentAt" TIMESTAMP(3), + "skippedAt" TIMESTAMP(3), + "leaseUntil" TIMESTAMP(3), + "failed" BOOLEAN NOT NULL DEFAULT false, + "attempts" INTEGER NOT NULL DEFAULT 0, + + CONSTRAINT "notdienst_alarm_emails_pkey" PRIMARY KEY ("id") +); + +-- CreateTable +CREATE TABLE "notdienst_alarm_history" ( + "id" TEXT NOT NULL, + "alarmId" TEXT NOT NULL, + "actorId" TEXT, + "action" TEXT NOT NULL, + "details" TEXT NOT NULL, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + + CONSTRAINT "notdienst_alarm_history_pkey" PRIMARY KEY ("id") +); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_profiles_educatorId_key" ON "staff_profiles"("educatorId"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_profiles_userId_key" ON "staff_profiles"("userId"); + +-- CreateIndex +CREATE INDEX "staff_profiles_kitaId_idx" ON "staff_profiles"("kitaId"); + +-- CreateIndex +CREATE INDEX "staff_emails_profileId_sentAt_skippedAt_idx" ON "staff_emails"("profileId", "sentAt", "skippedAt"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_work_patterns_profileId_effectiveFrom_key" ON "staff_work_patterns"("profileId", "effectiveFrom"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_day_overrides_profileId_date_key" ON "staff_day_overrides"("profileId", "date"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_holidays_kitaId_date_key" ON "staff_holidays"("kitaId", "date"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_leave_accounts_profileId_year_key" ON "staff_leave_accounts"("profileId", "year"); + +-- CreateIndex +CREATE INDEX "staff_leaves_profileId_status_startDate_idx" ON "staff_leaves"("profileId", "status", "startDate"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_leave_days_leaveId_date_key" ON "staff_leave_days"("leaveId", "date"); + +-- CreateIndex +CREATE INDEX "staff_time_entries_profileId_date_idx" ON "staff_time_entries"("profileId", "date"); + +-- CreateIndex +CREATE UNIQUE INDEX "staff_weeks_profileId_weekStart_key" ON "staff_weeks"("profileId", "weekStart"); + +-- CreateIndex +CREATE INDEX "staff_adjustments_profileId_date_idx" ON "staff_adjustments"("profileId", "date"); + +-- CreateIndex +CREATE INDEX "staff_history_profileId_createdAt_idx" ON "staff_history"("profileId", "createdAt"); + +-- CreateIndex +CREATE INDEX "staff_notifications_userId_readAt_createdAt_idx" ON "staff_notifications"("userId", "readAt", "createdAt"); + +-- CreateIndex +CREATE INDEX "family_event_participations_kitaId_idx" ON "family_event_participations"("kitaId"); + +-- CreateIndex +CREATE INDEX "family_event_participations_familyId_idx" ON "family_event_participations"("familyId"); + +-- CreateIndex +CREATE UNIQUE INDEX "family_event_participations_eventId_familyId_key" ON "family_event_participations"("eventId", "familyId"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarms_activeAssignmentId_key" ON "notdienst_alarms"("activeAssignmentId"); + +-- CreateIndex +CREATE INDEX "notdienst_alarms_kitaId_date_idx" ON "notdienst_alarms"("kitaId", "date"); + +-- CreateIndex +CREATE INDEX "notdienst_alarms_status_deadline_idx" ON "notdienst_alarms"("status", "deadline"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarm_recipients_token_key" ON "notdienst_alarm_recipients"("token"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarm_recipients_alarmId_userId_key" ON "notdienst_alarm_recipients"("alarmId", "userId"); + +-- CreateIndex +CREATE INDEX "notdienst_alarm_notifications_userId_readAt_idx" ON "notdienst_alarm_notifications"("userId", "readAt"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarm_notifications_alarmId_userId_eventKey_key" ON "notdienst_alarm_notifications"("alarmId", "userId", "eventKey"); + +-- CreateIndex +CREATE INDEX "notdienst_alarm_emails_sentAt_skippedAt_createdAt_idx" ON "notdienst_alarm_emails"("sentAt", "skippedAt", "createdAt"); + +-- CreateIndex +CREATE UNIQUE INDEX "notdienst_alarm_emails_alarmId_userId_eventKey_key" ON "notdienst_alarm_emails"("alarmId", "userId", "eventKey"); + +-- CreateIndex +CREATE INDEX "notdienst_alarm_history_alarmId_createdAt_idx" ON "notdienst_alarm_history"("alarmId", "createdAt"); + +-- AddForeignKey +ALTER TABLE "staff_profiles" ADD CONSTRAINT "staff_profiles_kitaId_fkey" FOREIGN KEY ("kitaId") REFERENCES "kitas"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_profiles" ADD CONSTRAINT "staff_profiles_educatorId_fkey" FOREIGN KEY ("educatorId") REFERENCES "educators"("id") ON DELETE NO ACTION ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_profiles" ADD CONSTRAINT "staff_profiles_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE SET NULL ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_emails" ADD CONSTRAINT "staff_emails_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_emails" ADD CONSTRAINT "staff_emails_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_work_patterns" ADD CONSTRAINT "staff_work_patterns_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_day_overrides" ADD CONSTRAINT "staff_day_overrides_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_holidays" ADD CONSTRAINT "staff_holidays_kitaId_fkey" FOREIGN KEY ("kitaId") REFERENCES "kitas"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_leave_accounts" ADD CONSTRAINT "staff_leave_accounts_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_leaves" ADD CONSTRAINT "staff_leaves_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_leave_days" ADD CONSTRAINT "staff_leave_days_leaveId_fkey" FOREIGN KEY ("leaveId") REFERENCES "staff_leaves"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_time_entries" ADD CONSTRAINT "staff_time_entries_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_weeks" ADD CONSTRAINT "staff_weeks_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_adjustments" ADD CONSTRAINT "staff_adjustments_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_history" ADD CONSTRAINT "staff_history_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_notifications" ADD CONSTRAINT "staff_notifications_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "staff_notifications" ADD CONSTRAINT "staff_notifications_profileId_fkey" FOREIGN KEY ("profileId") REFERENCES "staff_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "family_event_participations" ADD CONSTRAINT "family_event_participations_kitaId_fkey" FOREIGN KEY ("kitaId") REFERENCES "kitas"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "family_event_participations" ADD CONSTRAINT "family_event_participations_eventId_fkey" FOREIGN KEY ("eventId") REFERENCES "termine"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "family_event_participations" ADD CONSTRAINT "family_event_participations_familyId_fkey" FOREIGN KEY ("familyId") REFERENCES "families"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_kitaId_fkey" FOREIGN KEY ("kitaId") REFERENCES "kitas"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_assignmentId_fkey" FOREIGN KEY ("assignmentId") REFERENCES "notdienst_assignments"("id") ON DELETE SET NULL ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_familyId_fkey" FOREIGN KEY ("familyId") REFERENCES "families"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_recipients" ADD CONSTRAINT "notdienst_alarm_recipients_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_recipients" ADD CONSTRAINT "notdienst_alarm_recipients_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_notifications" ADD CONSTRAINT "notdienst_alarm_notifications_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_notifications" ADD CONSTRAINT "notdienst_alarm_notifications_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_emails" ADD CONSTRAINT "notdienst_alarm_emails_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_emails" ADD CONSTRAINT "notdienst_alarm_emails_userId_fkey" FOREIGN KEY ("userId") REFERENCES "users"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alarm_history" ADD CONSTRAINT "notdienst_alarm_history_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "notdienst_alerts" ADD CONSTRAINT "notdienst_alerts_alarmId_fkey" FOREIGN KEY ("alarmId") REFERENCES "notdienst_alarms"("id") ON DELETE SET NULL ON UPDATE CASCADE; + + +COMMIT; diff --git a/prisma/migrations/20261009050000_new_feature_tenant_constraints/migration.sql b/prisma/migrations/20261009050000_new_feature_tenant_constraints/migration.sql new file mode 100644 index 0000000..03103d0 --- /dev/null +++ b/prisma/migrations/20261009050000_new_feature_tenant_constraints/migration.sql @@ -0,0 +1,13 @@ +BEGIN; +-- Additional tenant invariants intentionally supplement Prisma relations. +ALTER TABLE "staff_profiles" ADD CONSTRAINT "staff_profiles_educatorId_tenant_fkey" FOREIGN KEY ("educatorId", "kitaId") REFERENCES "educators"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "staff_profiles" ADD CONSTRAINT "staff_profiles_userId_tenant_fkey" FOREIGN KEY ("userId", "kitaId") REFERENCES "users"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "family_event_participations" ADD CONSTRAINT "family_event_participations_eventId_tenant_fkey" FOREIGN KEY ("eventId", "kitaId") REFERENCES "termine"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "family_event_participations" ADD CONSTRAINT "family_event_participations_familyId_tenant_fkey" FOREIGN KEY ("familyId", "kitaId") REFERENCES "families"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_familyId_tenant_fkey" FOREIGN KEY ("familyId", "kitaId") REFERENCES "families"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_assignmentId_tenant_fkey" FOREIGN KEY ("assignmentId", "kitaId") REFERENCES "notdienst_assignments"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_activeAssignmentId_tenant_fkey" FOREIGN KEY ("activeAssignmentId", "kitaId") REFERENCES "notdienst_assignments"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_triggeredById_tenant_fkey" FOREIGN KEY ("triggeredById", "kitaId") REFERENCES "users"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_respondedById_tenant_fkey" FOREIGN KEY ("respondedById", "kitaId") REFERENCES "users"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +ALTER TABLE "notdienst_alarms" ADD CONSTRAINT "notdienst_alarms_educatorId_tenant_fkey" FOREIGN KEY ("educatorId", "kitaId") REFERENCES "educators"("id", "kitaId") ON DELETE NO ACTION ON UPDATE NO ACTION; +COMMIT; diff --git a/prisma/schema.prisma b/prisma/schema.prisma index 04dd041..b95c7b2 100644 --- a/prisma/schema.prisma +++ b/prisma/schema.prisma @@ -63,6 +63,17 @@ enum TerminStatus { CANCELLED } +enum RsvpMode { + CHILD + FAMILY +} + +enum AnnouncementAudience { + ELTERN + ERZIEHER + ALLE +} + enum EventParticipationStatus { ATTENDING NOT_ATTENDING @@ -84,6 +95,15 @@ enum NotdienstAlertStatus { CANCELLED } +enum NotdienstAlarmStatus { + PENDING + CONFIRMED + DECLINED + LATE_CONFIRMATION + REVIEW_REQUIRED + CANCELLED +} + enum NotdienstSwapStatus { PENDING ACCEPTED @@ -143,7 +163,11 @@ model Kita { notdienstAvailabilities NotdienstAvailability[] notdienstAssignments NotdienstAssignment[] notdienstAlerts NotdienstAlert[] + notdienstAlarms NotdienstAlarm[] notdienstSwapRequests NotdienstSwapRequest[] + staffProfiles StaffProfile[] + staffHolidays StaffHoliday[] + familyEventParticipations FamilyEventParticipation[] @@map("kitas") } @@ -158,15 +182,17 @@ model Family { kitaId String kita Kita @relation(fields: [kitaId], references: [id], onDelete: Cascade) - name String + name String + notdienstAlarms NotdienstAlarm[] createdAt DateTime @default(now()) updatedAt DateTime @updatedAt - users User[] - children Child[] - dutyAssignments DutyAssignment[] + users User[] + children Child[] + dutyAssignments DutyAssignment[] notdienstSwapRequestsStarted NotdienstSwapRequest[] @relation("NotdienstSwapRequesterFamily") + familyEventParticipations FamilyEventParticipation[] @@index([kitaId]) @@map("families") @@ -212,6 +238,7 @@ model User { privacyPolicyVersion String? /// Zeitstempel des Opt-Ins für das interne Kita-Adressbuch (Modul 3). directoryOptInAt DateTime? + staffDecisionEmails Boolean @default(true) // Auth-Bookkeeping emailVerifiedAt DateTime? @@ -227,21 +254,27 @@ model User { // Relations dutyAssignments ParentDutyAssignment[] - notdienstAvailabilities NotdienstAvailability[] - notdienstAlertsAssigned NotdienstAlert[] @relation("NotdienstAlertParent") - notdienstAlertsTriggered NotdienstAlert[] @relation("NotdienstAlertTrigger") - notdienstPlansCreated NotdienstPlan[] @relation("NotdienstPlanCreator") - notdienstSwapRequestsStarted NotdienstSwapRequest[] @relation("NotdienstSwapRequester") - notdienstSwapRequestsResponded NotdienstSwapRequest[] @relation("NotdienstSwapResponder") - announcementsAuthored Announcement[] @relation("AnnouncementAuthor") - announcementReads AnnouncementRead[] + notdienstAvailabilities NotdienstAvailability[] + notdienstAlertsAssigned NotdienstAlert[] @relation("NotdienstAlertParent") + notdienstAlertsTriggered NotdienstAlert[] @relation("NotdienstAlertTrigger") + notdienstPlansCreated NotdienstPlan[] @relation("NotdienstPlanCreator") + notdienstSwapRequestsStarted NotdienstSwapRequest[] @relation("NotdienstSwapRequester") + notdienstSwapRequestsResponded NotdienstSwapRequest[] @relation("NotdienstSwapResponder") + announcementsAuthored Announcement[] @relation("AnnouncementAuthor") + announcementReads AnnouncementRead[] termineCreated Termin[] @relation("TerminCreator") termineApproved Termin[] @relation("TerminApprover") mitbringselItems MitbringselItem[] - invitationsCreated Invitation[] @relation("InvitationCreator") - auditLogsAuthored AuditLog[] @relation("AuditLogActor") + invitationsCreated Invitation[] @relation("InvitationCreator") + auditLogsAuthored AuditLog[] @relation("AuditLogActor") + staffProfile StaffProfile? + staffNotifications StaffNotification[] + staffEmails StaffEmail[] + alarmRecipients NotdienstAlarmRecipient[] + alarmNotifications NotdienstAlarmNotification[] + alarmEmails NotdienstAlarmEmail[] @@index([kitaId]) @@index([familyId]) @@ -300,12 +333,238 @@ model Educator { updatedAt DateTime @updatedAt notdienstAlerts NotdienstAlert[] + staffProfile StaffProfile? @@index([kitaId]) @@map("educators") @@unique([id, kitaId]) } +// Personalbereich: Tage als UTC-Datum, Zeiten als Minuten, Anspruch in halben Tagen. +enum StaffRequestStatus { + PENDING + APPROVED + REJECTED + CANCEL_REQUESTED + CANCELLED +} + +enum StaffLeaveKind { + VACATION + TIME_OFF + SICKNESS +} + +enum StaffWeekStatus { + DRAFT + SUBMITTED + APPROVED +} + +model StaffProfile { + id String @id @default(cuid()) + kitaId String + kita Kita @relation(fields: [kitaId], references: [id], onDelete: Cascade) + educatorId String @unique + educator Educator @relation(fields: [educatorId], references: [id], onDelete: NoAction) + userId String? @unique + user User? @relation(fields: [userId], references: [id], onDelete: SetNull) + employmentStart DateTime @db.Date + employmentEnd DateTime? @db.Date + trackingStart DateTime @db.Date + openingMinutes Int @default(0) + createdAt DateTime @default(now()) + workPatterns StaffWorkPattern[] + dayOverrides StaffDayOverride[] + leaveAccounts StaffLeaveAccount[] + leaves StaffLeave[] + timeEntries StaffTimeEntry[] + weeks StaffWeek[] + adjustments StaffAdjustment[] + history StaffHistory[] + notifications StaffNotification[] + emails StaffEmail[] + + @@index([kitaId]) + @@map("staff_profiles") +} + +// Persisted in the same transaction as the staff action; delivered after commit. +model StaffEmail { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + userId String + user User @relation(fields: [userId], references: [id], onDelete: Cascade) + toAdmins Boolean @default(false) + subject String + message String + path String + inviteToken String? + createdAt DateTime @default(now()) + sentAt DateTime? + skippedAt DateTime? + leaseUntil DateTime? + attempts Int @default(0) + failed Boolean @default(false) + + @@index([profileId, sentAt, skippedAt]) + @@map("staff_emails") +} + +model StaffWorkPattern { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + effectiveFrom DateTime @db.Date + // Montag bis Sonntag; 0 bedeutet arbeitsfrei. + dailyMinutes Int[] + + @@unique([profileId, effectiveFrom]) + @@map("staff_work_patterns") +} + +model StaffDayOverride { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + date DateTime @db.Date + minutes Int + reason String + + @@unique([profileId, date]) + @@map("staff_day_overrides") +} + +model StaffHoliday { + id String @id @default(cuid()) + kitaId String + kita Kita @relation(fields: [kitaId], references: [id], onDelete: Cascade) + date DateTime @db.Date + name String + + @@unique([kitaId, date]) + @@map("staff_holidays") +} + +model StaffLeaveAccount { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + year Int + entitlementUnits Int + carryUnits Int @default(0) + + @@unique([profileId, year]) + @@map("staff_leave_accounts") +} + +model StaffLeave { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + kind StaffLeaveKind + status StaffRequestStatus @default(PENDING) + startDate DateTime @db.Date + endDate DateTime @db.Date + halfDay Boolean @default(false) + minutes Int? + note String? + decisionNote String? + requestedById String + reviewedById String? + reviewedAt DateTime? + createdAt DateTime @default(now()) + days StaffLeaveDay[] + + @@index([profileId, status, startDate]) + @@map("staff_leaves") +} + +model StaffLeaveDay { + id String @id @default(cuid()) + leaveId String + leave StaffLeave @relation(fields: [leaveId], references: [id], onDelete: Cascade) + date DateTime @db.Date + vacationUnits Int @default(0) + creditMinutes Int + + @@unique([leaveId, date]) + @@map("staff_leave_days") +} + +model StaffTimeEntry { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + date DateTime @db.Date + startMinute Int + endMinute Int + breakMinutes Int @default(0) + note String? + + @@index([profileId, date]) + @@map("staff_time_entries") +} + +model StaffWeek { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + weekStart DateTime @db.Date + status StaffWeekStatus @default(DRAFT) + submittedAt DateTime? + reviewedAt DateTime? + reviewedById String? + decisionNote String? + // Snapshot von Soll-, Ist- und Abwesenheitsminuten bei Genehmigung. + dailySnapshot Json? + + @@unique([profileId, weekStart]) + @@map("staff_weeks") +} + +model StaffAdjustment { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + date DateTime @db.Date + minutes Int + reason String + actorId String + createdAt DateTime @default(now()) + + @@index([profileId, date]) + @@map("staff_adjustments") +} + +model StaffHistory { + id String @id @default(cuid()) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + actorId String + action String + details String + createdAt DateTime @default(now()) + + @@index([profileId, createdAt]) + @@map("staff_history") +} + +model StaffNotification { + id String @id @default(cuid()) + userId String + user User @relation(fields: [userId], references: [id], onDelete: Cascade) + profileId String + profile StaffProfile @relation(fields: [profileId], references: [id], onDelete: Cascade) + message String + readAt DateTime? + createdAt DateTime @default(now()) + + @@index([userId, readAt, createdAt]) + @@map("staff_notifications") +} + // ===================================================================== // PARENT DUTIES (Feste Ämter / Elterndienste, Modul 3) // ===================================================================== @@ -430,8 +689,9 @@ model Announcement { kitaId String kita Kita @relation(fields: [kitaId], references: [id], onDelete: Cascade) - title String - content String + title String + content String + audience AnnouncementAudience @default(ALLE) authorId String author User @relation("AnnouncementAuthor", fields: [authorId], references: [id], onDelete: Cascade) @@ -528,6 +788,7 @@ model Termin { /// Teilnahme-Abfrage für Ausflüge und besondere Events. requiresRsvp Boolean @default(false) + rsvpMode RsvpMode @default(CHILD) rsvpDeadline DateTime? participantInfo String? @@ -542,8 +803,9 @@ model Termin { createdAt DateTime @default(now()) updatedAt DateTime @updatedAt - mitbringselItems MitbringselItem[] - participations EventParticipation[] + mitbringselItems MitbringselItem[] + participations EventParticipation[] + familyParticipations FamilyEventParticipation[] @@index([kitaId, startDate]) @@index([kitaId, status]) @@ -573,6 +835,25 @@ model EventParticipation { @@map("event_participations") } +model FamilyEventParticipation { + id String @id @default(cuid()) + kitaId String + kita Kita @relation(fields: [kitaId], references: [id], onDelete: Cascade) + eventId String + event Termin @relation(fields: [eventId], references: [id], onDelete: Cascade) + familyId String + family Family @relation(fields: [familyId], references: [id], onDelete: Cascade) + status EventParticipationStatus + adultCount Int @default(0) + createdAt DateTime @default(now()) + updatedAt DateTime @updatedAt + + @@unique([eventId, familyId]) + @@index([kitaId]) + @@index([familyId]) + @@map("family_event_participations") +} + model MitbringselItem { id String @id @default(cuid()) kitaId String @@ -671,7 +952,8 @@ model NotdienstAssignment { createdAt DateTime @default(now()) updatedAt DateTime @updatedAt - alerts NotdienstAlert[] + alerts NotdienstAlert[] + alarms NotdienstAlarm[] swapRequestsAsTarget NotdienstSwapRequest[] @relation("NotdienstSwapTargetAssignment") swapRequestsAsOffered NotdienstSwapRequest[] @relation("NotdienstSwapOfferedAssignment") @@ -700,11 +982,11 @@ model NotdienstSwapRequest { offeredAssignmentId String offeredAssignment NotdienstAssignment @relation("NotdienstSwapOfferedAssignment", fields: [offeredAssignmentId], references: [id], onDelete: Cascade) - status NotdienstSwapStatus @default(PENDING) + status NotdienstSwapStatus @default(PENDING) message String? respondedById String? - respondedBy User? @relation("NotdienstSwapResponder", fields: [respondedById], references: [id], onDelete: SetNull) + respondedBy User? @relation("NotdienstSwapResponder", fields: [respondedById], references: [id], onDelete: SetNull) respondedAt DateTime? createdAt DateTime @default(now()) @@ -719,10 +1001,117 @@ model NotdienstSwapRequest { /// Aktive Alarmierung — wird bei Krankmeldung einer Fachkraft /// vom Koordinator ausgelöst. Bestätigung via Magic-Link (Token). +model NotdienstAlarm { + id String @id @default(cuid()) + kitaId String + kita Kita @relation(fields: [kitaId], references: [id], onDelete: Cascade) + assignmentId String? + assignment NotdienstAssignment? @relation(fields: [assignmentId], references: [id], onDelete: SetNull) + // Nullable unique reservation: cancelled or ended alarms release the assignment. + activeAssignmentId String? @unique + familyId String + family Family @relation(fields: [familyId], references: [id], onDelete: Cascade) + familyName String + childName String + date DateTime @db.Date + wholeDay Boolean @default(true) + startMinute Int? + endMinute Int? + expiresAt DateTime + deadline DateTime + status NotdienstAlarmStatus @default(PENDING) + triggeredById String? + triggeredAt DateTime @default(now()) + respondedById String? + respondedAt DateTime? + responseSource String? + escalatedAt DateTime? + educatorId String? + notes String? + cancelledAt DateTime? + cancelReason String? + recipients NotdienstAlarmRecipient[] + notifications NotdienstAlarmNotification[] + emails NotdienstAlarmEmail[] + history NotdienstAlarmHistory[] + legacyAlerts NotdienstAlert[] + + @@index([kitaId, date]) + @@index([status, deadline]) + @@map("notdienst_alarms") +} + +model NotdienstAlarmRecipient { + id String @id @default(cuid()) + alarmId String + alarm NotdienstAlarm @relation(fields: [alarmId], references: [id], onDelete: Cascade) + userId String + user User @relation(fields: [userId], references: [id], onDelete: Cascade) + token String @unique + sessionVersion Int @default(0) + + @@unique([alarmId, userId]) + @@map("notdienst_alarm_recipients") +} + +model NotdienstAlarmNotification { + id String @id @default(cuid()) + alarmId String + alarm NotdienstAlarm @relation(fields: [alarmId], references: [id], onDelete: Cascade) + userId String + user User @relation(fields: [userId], references: [id], onDelete: Cascade) + eventKey String + message String + createdAt DateTime @default(now()) + readAt DateTime? + + @@unique([alarmId, userId, eventKey]) + @@index([userId, readAt]) + @@map("notdienst_alarm_notifications") +} + +model NotdienstAlarmEmail { + id String @id @default(cuid()) + alarmId String + alarm NotdienstAlarm @relation(fields: [alarmId], references: [id], onDelete: Cascade) + userId String + user User @relation(fields: [userId], references: [id], onDelete: Cascade) + eventKey String + kind String + subject String + message String + path String + createdAt DateTime @default(now()) + sentAt DateTime? + skippedAt DateTime? + leaseUntil DateTime? + failed Boolean @default(false) + attempts Int @default(0) + + @@unique([alarmId, userId, eventKey]) + @@index([sentAt, skippedAt, createdAt]) + @@map("notdienst_alarm_emails") +} + +model NotdienstAlarmHistory { + id String @id @default(cuid()) + alarmId String + alarm NotdienstAlarm @relation(fields: [alarmId], references: [id], onDelete: Cascade) + actorId String? + action String + details String + createdAt DateTime @default(now()) + + @@index([alarmId, createdAt]) + @@map("notdienst_alarm_history") +} + model NotdienstAlert { - id String @id @default(cuid()) - kitaId String - kita Kita @relation(fields: [kitaId], references: [id], onDelete: Cascade) + id String @id @default(cuid()) + alarmId String? + alarm NotdienstAlarm? @relation(fields: [alarmId], references: [id], onDelete: SetNull) + kitaId String + kita Kita @relation(fields: [kitaId], references: [id], onDelete: Cascade) assignmentId String assignment NotdienstAssignment @relation(fields: [assignmentId], references: [id], onDelete: Cascade) @@ -771,13 +1160,13 @@ model AuditLog { actorUser User? @relation("AuditLogActor", fields: [actorUserId], references: [id], onDelete: SetNull) actorEmail String - action String - targetType AuditTargetType - targetId String - targetLabel String + action String + targetType AuditTargetType + targetId String + targetLabel String targetKitaId String? - metadata Json? + metadata Json? createdAt DateTime @default(now()) @@index([actorUserId]) diff --git a/prisma/updates/20261007_parent_flows.sql b/prisma/updates/20261007_parent_flows.sql new file mode 100644 index 0000000..8ce3dda --- /dev/null +++ b/prisma/updates/20261007_parent_flows.sql @@ -0,0 +1,44 @@ +-- CreateEnum +CREATE TYPE "RsvpMode" AS ENUM ('CHILD', 'FAMILY'); + +-- CreateEnum +CREATE TYPE "AnnouncementAudience" AS ENUM ('ELTERN', 'ERZIEHER', 'ALLE'); + +-- AlterTable +ALTER TABLE "announcements" ADD COLUMN "audience" "AnnouncementAudience" NOT NULL DEFAULT 'ALLE'; + +-- AlterTable +ALTER TABLE "termine" ADD COLUMN "rsvpMode" "RsvpMode" NOT NULL DEFAULT 'CHILD'; + +-- CreateTable +CREATE TABLE "family_event_participations" ( + "id" TEXT NOT NULL, + "kitaId" TEXT NOT NULL, + "eventId" TEXT NOT NULL, + "familyId" TEXT NOT NULL, + "status" "EventParticipationStatus" NOT NULL, + "adultCount" INTEGER NOT NULL DEFAULT 0, + "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, + "updatedAt" TIMESTAMP(3) NOT NULL, + + CONSTRAINT "family_event_participations_pkey" PRIMARY KEY ("id") +); + +-- CreateIndex +CREATE INDEX "family_event_participations_kitaId_idx" ON "family_event_participations"("kitaId"); + +-- CreateIndex +CREATE INDEX "family_event_participations_familyId_idx" ON "family_event_participations"("familyId"); + +-- CreateIndex +CREATE UNIQUE INDEX "family_event_participations_eventId_familyId_key" ON "family_event_participations"("eventId", "familyId"); + +-- AddForeignKey +ALTER TABLE "family_event_participations" ADD CONSTRAINT "family_event_participations_kitaId_fkey" FOREIGN KEY ("kitaId") REFERENCES "kitas"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "family_event_participations" ADD CONSTRAINT "family_event_participations_eventId_fkey" FOREIGN KEY ("eventId") REFERENCES "termine"("id") ON DELETE CASCADE ON UPDATE CASCADE; + +-- AddForeignKey +ALTER TABLE "family_event_participations" ADD CONSTRAINT "family_event_participations_familyId_fkey" FOREIGN KEY ("familyId") REFERENCES "families"("id") ON DELETE CASCADE ON UPDATE CASCADE; + diff --git a/scripts/initialize-production.mjs b/scripts/initialize-production.mjs new file mode 100644 index 0000000..9f8ebf7 --- /dev/null +++ b/scripts/initialize-production.mjs @@ -0,0 +1,27 @@ +import { mkdirSync, existsSync, readFileSync, writeFileSync, chmodSync, chownSync } from 'node:fs'; +import { randomBytes } from 'node:crypto'; +import { spawnSync } from 'node:child_process'; +const passwordFile = process.env.APP_DATABASE_PASSWORD_FILE; +if (!passwordFile) throw new Error('Runtime password file is required.'); +const directory = passwordFile.slice(0, passwordFile.lastIndexOf('/')); +mkdirSync(directory, { recursive: true, mode: 0o700 }); +const password = existsSync(passwordFile) ? readFileSync(passwordFile, 'utf8').trim() : randomBytes(32).toString('hex'); +if (!/^[a-f0-9]{64}$/.test(password)) throw new Error('Invalid runtime password file.'); +if (!existsSync(passwordFile)) writeFileSync(passwordFile, password + '\n', { flag: 'wx', mode: 0o400 }); +chmodSync(passwordFile, 0o400); +chownSync(passwordFile, 1001, 1001); +chownSync(directory, 1001, 1001); +const ownerUrl = new URL('postgresql://postgres:5432/' + encodeURIComponent(process.env.POSTGRES_DB || 'kita_planer')); +ownerUrl.username = process.env.POSTGRES_USER || 'kita_planer'; +ownerUrl.password = process.env.POSTGRES_PASSWORD || ''; +if (!ownerUrl.password) throw new Error('Database owner password is required.'); +const environment = { ...process.env, DATABASE_URL: ownerUrl.toString(), APP_DATABASE_PASSWORD: password }; +for (const args of [['node_modules/prisma/build/index.js', 'migrate', 'deploy'], ['scripts/provision-runtime-role.mjs']]) { + const result = spawnSync(process.execPath, args, { env: environment, stdio: 'inherit' }); + if (result.status !== 0) process.exit(result.status || 1); +} +for (const path of ['/app/uploads', '/app/uploads/announcements', '/app/uploads/announcements/announcements', '/app/runtime-cache']) { + mkdirSync(path, { recursive: true, mode: 0o700 }); + chownSync(path, 1001, 1001); +} +console.log('Database initialized; restricted application access and volumes are ready.'); diff --git a/scripts/notdienst-alarm-worker.mjs b/scripts/notdienst-alarm-worker.mjs new file mode 100644 index 0000000..7a6b9a2 --- /dev/null +++ b/scripts/notdienst-alarm-worker.mjs @@ -0,0 +1,42 @@ +// Runs inside the application container. No external cron service or browser is required. +const secret = process.env.NOTDIENST_JOB_SECRET; +if (!secret || secret.length < 32) { + console.error( + "Notdienst-Fristprüfung deaktiviert: NOTDIENST_JOB_SECRET muss mindestens 32 Zeichen haben.", + ); + process.exit(1); +} +const port = Number(process.env.PORT || 3000); +if (!Number.isInteger(port) || port < 1 || port > 65535) process.exit(1); +let stopped = false; +let timer; +async function tick() { + const started = Date.now(); + try { + const response = await fetch( + `http://127.0.0.1:${port}/api/jobs/notdienstalarme`, + { + method: "POST", + headers: { authorization: `Bearer ${secret}` }, + signal: AbortSignal.timeout(50000), + }, + ); + if (!response.ok) + console.error( + `Notdienst-Fristprüfung: HTTP ${response.status}; erneuter Versuch in einer Minute.`, + ); + } catch { + console.error( + "Notdienst-Fristprüfung momentan nicht erreichbar; erneuter Versuch in einer Minute.", + ); + } + if (!stopped) + timer = setTimeout(tick, Math.max(1000, 60000 - (Date.now() - started))); +} +for (const signal of ["SIGINT", "SIGTERM"]) + process.on(signal, () => { + stopped = true; + clearTimeout(timer); + process.exit(0); + }); +timer = setTimeout(tick, 5000); diff --git a/scripts/prepare-standalone.mjs b/scripts/prepare-standalone.mjs index 904a554..57b77fa 100644 --- a/scripts/prepare-standalone.mjs +++ b/scripts/prepare-standalone.mjs @@ -1,3 +1,7 @@ -import { cpSync } from 'node:fs'; +import { cpSync, mkdirSync } from 'node:fs'; cpSync('.next/static', '.next/standalone/.next/static', { recursive: true }); cpSync('public', '.next/standalone/public', { recursive: true }); +mkdirSync('.next/standalone/scripts', { recursive: true }); +cpSync('scripts/start-production.sh', '.next/standalone/scripts/start-production.sh'); +cpSync('scripts/notdienst-alarm-worker.mjs', '.next/standalone/scripts/notdienst-alarm-worker.mjs'); +cpSync('scripts/runtime-database-url.mjs', '.next/standalone/scripts/runtime-database-url.mjs'); diff --git a/scripts/runtime-database-url.mjs b/scripts/runtime-database-url.mjs new file mode 100644 index 0000000..95ce0c2 --- /dev/null +++ b/scripts/runtime-database-url.mjs @@ -0,0 +1,8 @@ +import { readFileSync } from 'node:fs'; +const file = process.env.APP_DATABASE_PASSWORD_FILE; +if (!file) throw new Error('Runtime password file is required.'); +const password = readFileSync(file, 'utf8').trim(); +if (!/^[a-f0-9]{64}$/.test(password)) throw new Error('Invalid runtime password file.'); +const url = new URL('postgresql://kita_runtime@postgres:5432/' + encodeURIComponent(process.env.APP_DATABASE_NAME || 'kita_planer')); +url.password = password; +process.stdout.write(url.toString()); diff --git a/scripts/start-production.sh b/scripts/start-production.sh index c1d6edd..27c573a 100755 --- a/scripts/start-production.sh +++ b/scripts/start-production.sh @@ -1,4 +1,12 @@ #!/bin/sh set -eu -# Apply reviewed migrations separately before starting the runtime. +cd "$(dirname "$0")/.." +if [ -n "${APP_DATABASE_PASSWORD_FILE:-}" ]; then + DATABASE_URL="$(node scripts/runtime-database-url.mjs)" + export DATABASE_URL +fi +# Schema changes are applied by the maintenance image before runtime startup. +if [ -n "${NOTDIENST_JOB_SECRET:-}" ]; then + node scripts/notdienst-alarm-worker.mjs & +fi exec node server.js diff --git a/src/actions/announcements.ts b/src/actions/announcements.ts index 0abaff5..e7dfd2c 100644 --- a/src/actions/announcements.ts +++ b/src/actions/announcements.ts @@ -7,13 +7,17 @@ import { serializableTransaction } from "@/lib/transaction"; import { rateLimit } from "@/lib/rate-limit"; import { createElement } from "react"; import { revalidatePath } from "next/cache"; -import { Prisma, UserRole } from "@prisma/client"; +import { AnnouncementAudience, UserRole, type Prisma } from "@prisma/client"; import { z } from "zod"; import { NewsEmail } from "@/emails/NewsEmail"; import { requireKitaSession, requireRole } from "@/lib/auth-utils"; import { getAppEmailConfigError, sendAppEmail } from "@/lib/mail"; import { prisma } from "@/lib/prisma"; +import { + announcementRecipientWhere, + visibleAnnouncementAudiences, +} from "@/lib/announcement-access"; const audienceSchema = z.enum(["ELTERN", "ERZIEHER", "ALLE"]); @@ -29,24 +33,7 @@ function getSafeFileName(name: string) { } async function getRecipients(kitaId: string, audience: z.infer) { - const where: Prisma.UserWhereInput = - audience === "ELTERN" - ? { - kitaId, - familyId: { not: null }, - emailVerifiedAt: { not: null }, - } - : audience === "ERZIEHER" - ? { - kitaId, - role: UserRole.ERZIEHER, - emailVerifiedAt: { not: null }, - } - : { - kitaId, - emailVerifiedAt: { not: null }, - OR: [{ familyId: { not: null } }, { role: UserRole.ERZIEHER }], - }; + const where: Prisma.UserWhereInput = { kitaId, emailVerifiedAt: { not: null }, ...announcementRecipientWhere(audience as AnnouncementAudience) }; const users = await prisma.user.findMany({ where: { ...where, disabledAt: null, privacyPolicyAcceptedAt: { not: null } }, @@ -118,6 +105,7 @@ export async function createAnnouncement(formData: FormData) { kitaId, title: parsed.data.title, content: parsed.data.content, + audience: parsed.data.audience, authorId: session.user.id, attachments: { create: attachmentInputs.map((attachment) => ({ @@ -158,7 +146,10 @@ export async function createAnnouncement(formData: FormData) { rm(attachmentPath(attachment.id), { force: true }), ), ); - console.error("Ankündigungs-Anhang konnte nicht gespeichert werden:", error); + console.error( + "Ankündigungs-Anhang konnte nicht gespeichert werden:", + error, + ); return { error: "Anhang konnte nicht gespeichert werden." }; } } @@ -190,6 +181,7 @@ export async function createAnnouncement(formData: FormData) { revalidatePath("/dashboard"); revalidatePath("/dashboard/admin/news"); + revalidatePath("/dashboard/mitteilungen"); if (emailError) { return { @@ -208,6 +200,7 @@ export async function markAnnouncementRead(announcementId: string) { where: { id: announcementId, kitaId: session.user.kitaId, + audience: { in: visibleAnnouncementAudiences(session.user) }, }, select: { id: true }, }); @@ -234,5 +227,6 @@ export async function markAnnouncementRead(announcementId: string) { }); revalidatePath("/dashboard"); + revalidatePath("/dashboard/mitteilungen"); return { success: true }; } diff --git a/src/actions/rsvp.ts b/src/actions/rsvp.ts index 83eede9..47162b7 100644 --- a/src/actions/rsvp.ts +++ b/src/actions/rsvp.ts @@ -3,20 +3,16 @@ import { revalidatePath } from "next/cache"; import { EventParticipationStatus, + RsvpMode, TerminStatus, UserRole, } from "@prisma/client"; -import { z } from "zod"; +import { rsvpSubmissionSchema } from "@/lib/rsvp"; +import { lockEvent } from "@/lib/event-lock"; import { requireKitaSession, requireRole } from "@/lib/auth-utils"; import { prisma } from "@/lib/prisma"; -const submitRsvpSchema = z.object({ - eventId: z.string().min(1), - childId: z.string().min(1), - status: z.nativeEnum(EventParticipationStatus), -}); - export type EventParticipantDto = { childId: string; childName: string; @@ -24,79 +20,120 @@ export type EventParticipantDto = { status: EventParticipationStatus | null; }; -export async function submitEventRsvp(rawPayload: unknown) { +export async function submitEventRsvp( + rawPayload: unknown, +): Promise<{ error?: string; success?: boolean }> { const session = await requireKitaSession(); - const parsed = submitRsvpSchema.safeParse(rawPayload); - - if (!parsed.success) { - return { error: "Ungültige Eingabedaten." }; + const parsed = rsvpSubmissionSchema.safeParse(rawPayload); + if (!parsed.success) + return { + error: + "Bitte alle Antworten und bei Familienzusagen die Anzahl Erwachsener angeben.", + }; + if (!session.user.familyId || session.user.role === UserRole.ERZIEHER) { + return { + error: "Für Rückmeldungen ist ein Elternkonto mit Haushalt erforderlich.", + }; } - - if (!session.user.familyId) { - return { error: "Dein Account ist noch keinem Haushalt zugeordnet." }; + const kitaId = session.user.kitaId; + const familyId = session.user.familyId; + const payload = parsed.data; + try { + const result = await prisma.$transaction(async (tx) => { + await lockEvent(tx, payload.eventId, kitaId); + const event = await tx.termin.findFirst({ + where: { id: payload.eventId, kitaId }, + select: { + status: true, + requiresRsvp: true, + rsvpMode: true, + rsvpDeadline: true, + startDate: true, + kita: { select: { terminModuleEnabled: true } }, + }, + }); + if ( + !event?.kita.terminModuleEnabled || + !event.requiresRsvp || + event.status !== TerminStatus.CONFIRMED + ) { + return { error: "Für diesen Termin ist keine Rückmeldung aktiv." }; + } + if (event.rsvpMode !== payload.mode) + return { + error: "Die Antwortart wurde geändert. Bitte lade den Termin erneut.", + }; + if (payload.mode === RsvpMode.FAMILY) { + const family = await tx.family.findFirst({ + where: { id: familyId, kitaId }, + select: { id: true }, + }); + if (!family) return { error: "Haushalt wurde nicht gefunden." }; + if ( + (event.rsvpDeadline ?? event.startDate) <= new Date() || + event.startDate <= new Date() + ) { + return { error: "Die Rückmeldefrist ist bereits abgelaufen." }; + } + await tx.familyEventParticipation.upsert({ + where: { eventId_familyId: { eventId: payload.eventId, familyId } }, + create: { + kitaId, + eventId: payload.eventId, + familyId, + status: payload.status, + adultCount: payload.adultCount, + }, + update: { status: payload.status, adultCount: payload.adultCount }, + }); + } else { + const children = await tx.child.findMany({ + where: { kitaId, familyId, active: true }, + select: { id: true }, + }); + const ids = new Set(children.map((child) => child.id)); + if ( + payload.responses.length !== ids.size || + payload.responses.some((row) => !ids.has(row.childId)) + ) { + return { + error: + "Bitte antworte für alle eigenen aktiven Kinder. Lade den Termin bei Änderungen erneut.", + }; + } + if ( + (event.rsvpDeadline ?? event.startDate) <= new Date() || + event.startDate <= new Date() + ) { + return { error: "Die Rückmeldefrist ist bereits abgelaufen." }; + } + for (const response of payload.responses) { + await tx.eventParticipation.upsert({ + where: { + eventId_childId: { + eventId: payload.eventId, + childId: response.childId, + }, + }, + create: { kitaId, eventId: payload.eventId, ...response }, + update: { status: response.status }, + }); + } + } + return { success: true }; + }); + if (result.error) return result; + revalidatePath("/dashboard"); + revalidatePath("/dashboard/kalender"); + revalidatePath("/dashboard/admin/kalender"); + return result; + } catch (error) { + console.error("Rückmeldung konnte nicht gespeichert werden:", error); + return { + error: + "Rückmeldung konnte nicht gespeichert werden. Bitte versuche es erneut.", + }; } - - const { eventId, childId, status } = parsed.data; - - const event = await prisma.termin.findFirst({ - where: { - id: eventId, - kitaId: session.user.kitaId, - }, - select: { - id: true, - status: true, - requiresRsvp: true, - rsvpDeadline: true, - startDate: true, - }, - }); - - if (!event || !event.requiresRsvp || event.status !== TerminStatus.CONFIRMED) { - return { error: "Für diesen Termin ist keine Rückmeldung aktiv." }; - } - - const deadline = event.rsvpDeadline ?? event.startDate; - if (deadline < new Date()) { - return { error: "Die Rückmeldefrist ist bereits abgelaufen." }; - } - - const child = await prisma.child.findFirst({ - where: { - id: childId, - kitaId: session.user.kitaId, - familyId: session.user.familyId, - active: true, - }, - select: { id: true }, - }); - - if (!child) { - return { error: "Dieses Kind gehört nicht zu deinem Haushalt." }; - } - - await prisma.eventParticipation.upsert({ - where: { - eventId_childId: { - eventId, - childId, - }, - }, - create: { - kitaId: session.user.kitaId, - eventId, - childId, - status, - }, - update: { - status, - }, - }); - - revalidatePath("/dashboard"); - revalidatePath("/dashboard/kalender"); - revalidatePath("/dashboard/admin/kalender"); - return { success: true }; } export async function getEventParticipants( diff --git a/src/app/alert/[token]/actions.ts b/src/app/alert/[token]/actions.ts index ea8bd7d..ce3a008 100644 --- a/src/app/alert/[token]/actions.ts +++ b/src/app/alert/[token]/actions.ts @@ -1,18 +1,37 @@ "use server"; +import { publicActionError } from "@/lib/action-error"; import { revalidatePath } from "next/cache"; -import { NotdienstAlertStatus } from "@prisma/client"; -import { prisma } from "@/lib/prisma"; -import { activeAlertTokenWhere } from "@/lib/alert-tokens"; -import { hashToken, isPublicToken } from "@/lib/tokens"; +import { respondToAlarm } from "@/lib/alarms/service"; +import { deliverAlarmEmails } from "@/lib/alarms/email"; import { limitPublicAction } from "@/lib/rate-limit"; +import { hashToken, isPublicToken } from "@/lib/tokens"; + +export async function respondAlertAction(token: string, approve: boolean) { + if (!isPublicToken(token) || typeof approve !== "boolean") + return { error: "Ungültiger Rückmeldelink." }; + if (!(await limitPublicAction("alarm-response", hashToken(token), 12, 60))) + return { error: "Bitte kurz warten und erneut versuchen." }; + try { + const result = await respondToAlarm(token, approve); + // The household response is already committed; transport failure must not undo it. + try { + await deliverAlarmEmails(result.emailIds); + } catch { + /* Persistent jobs will retry. */ + } + revalidatePath("/alert/[token]", "page"); + revalidatePath("/dashboard"); + revalidatePath("/dashboard/notdienst/alarm"); + return { success: true }; + } catch (error) { + const message = publicActionError(error, ""); + if (message) return { error: message }; + return { + error: + "Die Rückmeldung konnte nicht gespeichert werden. Bitte den aktuellen Stand prüfen.", + }; + } +} export async function confirmAlertAction(token: string) { - if (!isPublicToken(token)) return { error: "Ungültiger Bestätigungs-Link." }; - if (!(await limitPublicAction("alert-confirm", hashToken(token), 10, 900))) return { error: "Bitte versuche es später erneut." }; - const updated = await prisma.notdienstAlert.updateMany({ - where: activeAlertTokenWhere(token), - data: { status: NotdienstAlertStatus.CONFIRMED, confirmedAt: new Date() }, - }); - if (updated.count !== 1) return { error: "Dieser Link ist abgelaufen oder wurde bereits verwendet." }; - revalidatePath("/dashboard"); - return { success: true }; + return respondAlertAction(token, true); } diff --git a/src/app/alert/[token]/alert-confirm-form.tsx b/src/app/alert/[token]/alert-confirm-form.tsx index 6310c47..f78ce81 100644 --- a/src/app/alert/[token]/alert-confirm-form.tsx +++ b/src/app/alert/[token]/alert-confirm-form.tsx @@ -1,37 +1,65 @@ "use client"; - -import { useTransition } from "react"; -import { Loader2 } from "lucide-react"; -import { toast } from "sonner"; - +import { useState, useTransition } from "react"; +import { useRouter } from "next/navigation"; import { Button } from "@/components/ui/button"; -import { confirmAlertAction } from "./actions"; +import { respondAlertAction } from "./actions"; export function AlertConfirmForm({ token }: { token: string }) { - const [isPending, startTransition] = useTransition(); - - const handleConfirm = () => { - startTransition(async () => { - const result = await confirmAlertAction(token); - if ("error" in result && result.error) { - toast.error(result.error as string); - } else { - toast.success("Erfolgreich bestätigt!"); - } - }); - }; - + const [choice, setChoice] = useState(null); + const [pending, start] = useTransition(); + const [error, setError] = useState(""); + const router = useRouter(); return ( - +
+ {choice === null ? ( +
+ + +
+ ) : ( +
+

+ {choice + ? "Wir sagen für unseren Haushalt zu." + : "Unser Haushalt kann diesen Einsatz nicht übernehmen."}{" "} + Diese Antwort gilt für alle Elternkonten des Haushalts. +

+
+ + +
+
+ )} + {error && ( +

+ {error} +

+ )} +
); } diff --git a/src/app/alert/[token]/page.tsx b/src/app/alert/[token]/page.tsx index 903c4f8..d4bc5fe 100644 --- a/src/app/alert/[token]/page.tsx +++ b/src/app/alert/[token]/page.tsx @@ -1,131 +1,114 @@ import { notFound } from "next/navigation"; -import { format } from "date-fns"; -import { de } from "date-fns/locale"; -import { BellRing, ShieldCheck, XCircle } from "lucide-react"; -import { NotdienstAlertStatus } from "@prisma/client"; - -import { activeAlertTokenWhere } from "@/lib/alert-tokens"; -import { isPublicToken } from "@/lib/tokens"; -import { prisma } from "@/lib/prisma"; +import { BellRing, CheckCircle2 } from "lucide-react"; +import { getPublicAlarm } from "@/lib/alarms/service"; import { - Card, - CardContent, - CardDescription, - CardHeader, - CardTitle, -} from "@/components/ui/card"; + alarmLabel, + dateKey, + durationLabel, + instantLabel, +} from "@/lib/alarms/format"; import { AlertConfirmForm } from "./alert-confirm-form"; +export const metadata = { + title: "Notdienstalarm · Kita-Planer", + robots: { index: false, follow: false }, + referrer: "no-referrer" as const, +}; export const dynamic = "force-dynamic"; -export const metadata = { title: "Notdienst Alarm · Kita-Planer", robots: { index: false, follow: false } }; - export default async function AlertPage({ params, }: { params: Promise<{ token: string }>; }) { const { token } = await params; - - if (!isPublicToken(token)) notFound(); - const alert = await prisma.notdienstAlert.findFirst({ - where: activeAlertTokenWhere(token), - select: { - status: true, - parentUser: { - select: { - firstName: true, - }, - }, - kita: { - select: { - name: true, - }, - }, - assignment: { - select: { - date: true, - child: { - select: { - firstName: true, - lastName: true, - }, - }, - }, - }, - }, - }); - - if (!alert) { - notFound(); - } - - const isPending = alert.status === NotdienstAlertStatus.PENDING; - const isConfirmed = alert.status === NotdienstAlertStatus.CONFIRMED; - + const alarm = await getPublicAlarm(token); + if (!alarm) notFound(); + const now = new Date(), + expired = alarm.expiresAt <= now; + const canRespond = alarm.status === "PENDING" && !expired; + const overdue = alarm.deadline <= now; return ( -
- - -
- {isPending ? ( - - ) : isConfirmed ? ( - - ) : ( - - )} -
- - {isPending - ? "Notdienst Einsatz!" - : isConfirmed - ? "Einsatz bestätigt" - : "Alarm abgebrochen"} - - - Kita {alert.kita.name} - - - -
-

Datum

-

- {format(alert.assignment.date, "EEEE, dd. MMMM yyyy", { - locale: de, - })} -

-
-

Eingeteiltes Kind

-

- {alert.assignment.child.firstName}{" "} - {alert.assignment.child.lastName} -

-
- -
- {isPending ? ( - <> -

- Hallo {alert.parentUser.firstName}, eine Fachkraft hat sich - krankgemeldet und du bist heute für den Notdienst eingeteilt. - Bitte bestätige deinen Einsatz schnellstmöglich! +

+
+
+

+ Kita-Planer · {alarm.kitaName} +

+ {alarm.status === "CONFIRMED" ? ( + + ) : ( + + )} +

+ {alarm.status === "PENDING" + ? "Könnt ihr den Notdienst übernehmen?" + : alarmLabel(alarm)} +

+

+ Hallo {alarm.firstName}, diese Rückmeldung gilt für euren gesamten + Haushalt. +

+
+
+
+
+
Datum
+
+ {dateKey(alarm.date).split("-").reverse().join(".")} +
+
+
+
Einsatz
+
{durationLabel(alarm)}
+
+
+
Haushalt
+
{alarm.familyName}
+
+
+
Antwortfrist
+
+ {instantLabel(alarm.deadline)} Uhr +
+
+
+ {canRespond ? ( + <> + {overdue && ( +

+ Die Antwortfrist ist abgelaufen. Ihr könnt noch antworten. + Eine verspätete Zusage muss die Koordination freigeben, da + möglicherweise bereits Ersatz organisiert wird.

- - - ) : isConfirmed ? ( -

- Danke, {alert.parentUser.firstName}! Dein Einsatz wurde - erfolgreich bestätigt. Die Kita rechnet mit dir. -

- ) : ( -

- Dieser Einsatz wurde vom Koordinator abgebrochen. Du musst nicht - einspringen. -

- )} -
- - -
+ )} + + + ) : ( +
+ {alarm.status === "CANCELLED" + ? "Der Einsatz wurde storniert. Ihr müsst für diesen Alarm nicht einspringen." + : alarm.status === "CONFIRMED" + ? "Euer Haushalt hat zugesagt. Die Kita rechnet mit euch. Bei einer Änderung kontaktiert bitte die Koordination." + : alarm.status === "LATE_CONFIRMATION" + ? "Eure verspätete Zusage ist gespeichert. Wartet bitte auf die Freigabe durch die Koordination." + : alarm.status === "DECLINED" + ? "Die Absage eures Haushalts ist gespeichert. Die Koordination kümmert sich um Ersatz." + : alarm.status === "REVIEW_REQUIRED" + ? "Die bisherigen Rückmeldungen müssen von der Koordination geprüft werden. Bitte kontaktiert die Kita." + : "Der Einsatz ist beendet. Dieser Rückmeldelink ist abgelaufen."} +
+ )} +

+ Den persönlichen Link bitte innerhalb eures Haushalts behalten. + Änderungen einer gespeicherten Antwort klärt ihr mit der Kita. +

+
+ + ); } diff --git a/src/app/api/announcements/attachments/[id]/route.ts b/src/app/api/announcements/attachments/[id]/route.ts index bf9d061..ea2ee5c 100644 --- a/src/app/api/announcements/attachments/[id]/route.ts +++ b/src/app/api/announcements/attachments/[id]/route.ts @@ -5,6 +5,7 @@ import { NextResponse } from "next/server"; import { getKitaSession } from "@/lib/auth-utils"; import { prisma } from "@/lib/prisma"; +import { visibleAnnouncementAudiences } from "@/lib/announcement-access"; export const runtime = "nodejs"; @@ -26,6 +27,7 @@ export async function GET( id, announcement: { kitaId: user.kitaId, + audience: { in: visibleAnnouncementAudiences(user) }, }, }, select: { diff --git a/src/app/api/jobs/notdienstalarme/route.ts b/src/app/api/jobs/notdienstalarme/route.ts new file mode 100644 index 0000000..dde469e --- /dev/null +++ b/src/app/api/jobs/notdienstalarme/route.ts @@ -0,0 +1,32 @@ +import { revalidatePath } from "next/cache"; +import { authorizeAlarmJob, runAlarmJob } from "@/lib/alarms/job"; + +export const runtime = "nodejs"; +export const dynamic = "force-dynamic"; +export async function POST(request: Request) { + const status = authorizeAlarmJob(request.headers.get("authorization")); + if (status !== 200) + return Response.json( + { + error: + status === 503 + ? "Fristprüfung ist nicht konfiguriert." + : "Nicht autorisiert.", + }, + { status }, + ); + try { + const result = await runAlarmJob(); + revalidatePath("/dashboard"); + revalidatePath("/dashboard/notdienst/alarm"); + return Response.json(result); + } catch { + return Response.json( + { + error: + "Fristprüfung fehlgeschlagen; nächster Aufruf versucht es erneut.", + }, + { status: 500 }, + ); + } +} diff --git a/src/app/dashboard/actions.ts b/src/app/dashboard/actions.ts index 785012b..0ea30b6 100644 --- a/src/app/dashboard/actions.ts +++ b/src/app/dashboard/actions.ts @@ -1,126 +1,10 @@ "use server"; - -import { serializableTransaction } from "@/lib/transaction"; -import { UserFacingError, publicActionError } from "@/lib/action-error"; -import { hashToken, newToken } from "@/lib/tokens"; -import { rateLimit } from "@/lib/rate-limit"; -import { createElement } from "react"; -import { format } from "date-fns"; -import { de } from "date-fns/locale"; -import { revalidatePath } from "next/cache"; -import { NotdienstAlertStatus, UserRole } from "@prisma/client"; - -import { AlertEmail } from "@/emails/AlertEmail"; -import { requireRole } from "@/lib/auth-utils"; -import { getAppEmailConfigError, sendAppEmail } from "@/lib/mail"; -import { prisma } from "@/lib/prisma"; - -const BASE_URL = - process.env.NEXTAUTH_URL ?? process.env.AUTH_URL ?? "http://localhost:3000"; - +import { alarmAction } from "./notdienst/alarm/actions"; +// Existing callers use the shared household workflow and the same guards. export async function triggerAlertAction(assignmentId: string) { - const session = await requireRole([UserRole.ADMIN, UserRole.KOORDINATOR]); - const kitaId = session.user.kitaId!; - - if (!(await rateLimit(`alerts:${kitaId}:${session.user.id}`, 50, 3600)).allowed) return { error: "Zu viele Alarme. Bitte versuche es später erneut." }; - try { - const [existing, assignment] = await Promise.all([ - // Prüfen ob es schon einen aktiven Alert für dieses Assignment gibt - prisma.notdienstAlert.findFirst({ - where: { assignmentId, kitaId }, - }), - prisma.notdienstAssignment.findFirst({ - where: { id: assignmentId, kitaId, plan: { status: "PUBLISHED" } }, - include: { - child: { - select: { - id: true, - familyId: true, - firstName: true, - lastName: true, - family: { - select: { - users: { - where: { role: UserRole.ELTERN, emailVerifiedAt: { not: null }, disabledAt: null, privacyPolicyAcceptedAt: { not: null } }, - select: { - id: true, - email: true, - firstName: true, - lastName: true, - }, - }, - }, - }, - }, - }, - }, - }), - ]); - - if (existing) { - return { error: "Für diese Einteilung wurde bereits ein Alarm ausgelöst." }; - } - - if (!assignment) { - return { error: "Notdienst-Einteilung wurde nicht gefunden." }; - } - - const parents = assignment.child.family.users; - - if (parents.length === 0) { - return { error: "Kein Elternteil für diesen Notdienst hinterlegt." }; - } - - const mailConfigError = getAppEmailConfigError(); - if (mailConfigError) { - return { error: mailConfigError }; - } - - const dateLabel = format(assignment.date, "EEEE, dd. MMMM yyyy", { - locale: de, - }); - const childName = `${assignment.child.firstName} ${assignment.child.lastName}`; - const alertJobs = parents.map(parent => ({ email: parent.email, token: newToken(), parentId: parent.id })); - await serializableTransaction(async tx => { - if (await tx.notdienstAlert.findFirst({ where: { assignmentId, kitaId }, select: { id: true } })) { - throw new UserFacingError("Für diese Einteilung wurde bereits ein Alarm ausgelöst."); - } - const current = await tx.notdienstAssignment.findFirst({ where: { id: assignmentId, kitaId, plan: { status: "PUBLISHED" } }, select: { childId: true, date: true } }); - const today = new Date(); today.setUTCHours(0, 0, 0, 0); - if (!current || current.childId !== assignment.child.id || current.date < today) throw new UserFacingError("Die Einteilung hat sich geändert oder liegt in der Vergangenheit. Bitte lade die Seite neu."); - for (const job of alertJobs) { - const parent = await tx.user.findFirst({ where: { id: job.parentId, kitaId, familyId: assignment.child.familyId, - email: job.email, disabledAt: null, emailVerifiedAt: { not: null }, privacyPolicyAcceptedAt: { not: null } }, select: { id: true } }); - if (!parent) throw new UserFacingError("Die Empfänger haben sich geändert. Bitte lade die Seite neu."); - await tx.notdienstAlert.create({ data: { kitaId, assignmentId, parentUserId: parent.id, - triggeredById: session.user.id, status: NotdienstAlertStatus.PENDING, confirmationToken: hashToken(job.token) } }); - } - }); - - for (const job of alertJobs) { - const emailResult = await sendAppEmail({ - to: job.email, - subject: `Dringender Notdienst-Alarm für ${dateLabel}`, - react: createElement(AlertEmail, { - date: dateLabel, - childName, - confirmLink: `${BASE_URL}/alert/${job.token}`, - }), - }); - - if (!emailResult.success) { - revalidatePath("/dashboard"); - return { - error: `Alarm wurde angelegt, aber mindestens eine E-Mail konnte nicht versendet werden: ${emailResult.error}`, - }; - } - } - - revalidatePath("/dashboard"); - - return { success: true }; - } catch (error) { - console.error(error); - return { error: publicActionError(error, "Fehler beim Auslösen des Alarms.") }; - } + return alarmAction("create", { + assignmentId, + wholeDay: true, + replyMinutes: 30, + }); } diff --git a/src/app/dashboard/admin/kalender/admin-calendar-manager.tsx b/src/app/dashboard/admin/kalender/admin-calendar-manager.tsx index c554794..59ce6f7 100644 --- a/src/app/dashboard/admin/kalender/admin-calendar-manager.tsx +++ b/src/app/dashboard/admin/kalender/admin-calendar-manager.tsx @@ -3,6 +3,7 @@ import { useMemo, useState, useTransition } from "react"; import { EventParticipationStatus, + RsvpMode, TerminStatus, TerminType, } from "@prisma/client"; @@ -19,6 +20,7 @@ import { } from "lucide-react"; import { toast } from "sonner"; +import { suggestedRsvpMode } from "@/lib/rsvp"; import { Badge } from "@/components/ui/badge"; import { Button } from "@/components/ui/button"; import { @@ -48,10 +50,7 @@ import { TableRow, } from "@/components/ui/table"; import { Textarea } from "@/components/ui/textarea"; -import { - createTerminAdmin, - updateTerminAdmin, -} from "../../kalender/actions"; +import { createTerminAdmin, updateTerminAdmin } from "../../kalender/actions"; type AdminTerminDto = { id: string; @@ -64,6 +63,12 @@ type AdminTerminDto = { allDay: boolean; mitbringselListEnabled: boolean; requiresRsvp: boolean; + rsvpMode: RsvpMode; + familyParticipations: { + familyId: string; + status: EventParticipationStatus; + adultCount: number; + }[]; rsvpDeadline: string | null; participantInfo: string | null; participations: { @@ -81,9 +86,11 @@ type ChildDto = { export function AdminCalendarManager({ termine, childRows, + familyRows, }: { termine: AdminTerminDto[]; childRows: ChildDto[]; + familyRows: { id: string; name: string }[]; }) { const rsvpCount = termine.filter((termin) => termin.requiresRsvp).length; const pendingCount = termine.filter( @@ -104,8 +111,8 @@ export function AdminCalendarManager({

- Termine verwalten, RSVP aktivieren und den Rücklauf pro Kind - verfolgen. + Termine verwalten, RSVP aktivieren und den Rücklauf pro Familie oder + Kind verfolgen.

@@ -134,7 +141,7 @@ export function AdminCalendarManager({ Noch keine Termine

- Lege den ersten Termin an, um RSVP-Rückmeldungen einzusammeln. + Lege den ersten Termin an, um RSVP-Rückmeldungen einzusammeln.

@@ -145,6 +152,7 @@ export function AdminCalendarManager({ key={termin.id} termin={termin} childRows={childRows} + familyRows={familyRows} /> ))} @@ -156,11 +164,25 @@ export function AdminCalendarManager({ function AdminTerminCard({ termin, childRows, + familyRows, }: { termin: AdminTerminDto; childRows: ChildDto[]; + familyRows: { id: string; name: string }[]; }) { - const stats = useMemo(() => getStats(termin, childRows), [termin, childRows]); + const isFamily = termin.rsvpMode === RsvpMode.FAMILY; + const rows = useMemo( + () => + isFamily + ? familyRows.map((family) => ({ + id: family.id, + name: family.name, + familyName: family.name, + })) + : childRows, + [isFamily, familyRows, childRows], + ); + const stats = useMemo(() => getStats(termin, rows), [termin, rows]); return ( @@ -175,7 +197,9 @@ function AdminTerminCard({ {getStatusLabel(termin.status)} {termin.requiresRsvp && ( - RSVP aktiv + + Antwort pro {isFamily ? "Familie" : "Kind"} + )} {termin.title} @@ -217,14 +241,19 @@ function AdminTerminCard({

{stats.attending} Zugesagt / {stats.notAttending} Abgesagt /{" "} - {stats.pending} Ausstehend + {stats.pending} Ausstehend{" "} + {isFamily ? `· ${stats.adultCount} Erwachsene` : ""}

Frist:{" "} {termin.rsvpDeadline - ? format(new Date(termin.rsvpDeadline), "dd.MM.yyyy HH:mm", { - locale: de, - }) + ? format( + new Date(termin.rsvpDeadline), + "dd.MM.yyyy HH:mm", + { + locale: de, + }, + ) : "bis Terminbeginn"}

@@ -241,18 +270,24 @@ function AdminTerminCard({ - Kind - Familie + {isFamily ? "Familie" : "Kind"} + {isFamily ? "Erwachsene" : "Familie"} Status - {childRows.map((child) => { + {rows.map((child) => { const status = stats.statusByChildId.get(child.id) ?? null; return ( - {child.name} - {child.familyName} + + {child.name} + + + {isFamily + ? (stats.adultCounts.get(child.id) ?? "–") + : child.familyName} + @@ -283,6 +318,13 @@ function TerminFormDialog({ const [requiresRsvp, setRequiresRsvp] = useState( termin?.requiresRsvp ?? false, ); + const [rsvpMode, setRsvpMode] = useState( + termin?.rsvpMode ?? suggestedRsvpMode(TerminType.KITA_FEST), + ); + const [modeTouched, setModeTouched] = useState(false); + const modeLocked = + !!termin && + termin.participations.length + termin.familyParticipations.length > 0; const [isPending, startTransition] = useTransition(); function handleAction(formData: FormData) { @@ -300,6 +342,7 @@ function TerminFormDialog({ allDay: formData.get("allDay") === "on", mitbringselListEnabled: formData.get("mitbringselListEnabled") === "on", requiresRsvp: hasRsvp, + rsvpMode, rsvpDeadline: hasRsvp && deadlineRaw ? new Date(deadlineRaw).toISOString() : null, participantInfo: String(formData.get("participantInfo") ?? ""), @@ -330,6 +373,10 @@ function TerminFormDialog({ setOpen(nextOpen); if (nextOpen) { setRequiresRsvp(termin?.requiresRsvp ?? false); + setRsvpMode( + termin?.rsvpMode ?? suggestedRsvpMode(TerminType.KITA_FEST), + ); + setModeTouched(false); } }} > @@ -380,6 +427,12 @@ function TerminFormDialog({ { + setRsvpMode(e.target.value as RsvpMode); + setModeTouched(true); + }} + className="h-10 rounded-lg border border-[var(--hairline)] bg-[var(--surface)] px-3 text-sm disabled:opacity-60" + > + + + + {modeLocked ? ( +

+ Die Antwortart ist gesperrt, da bereits Rückmeldungen + vorliegen. +

+ ) : null} + +
+ [ - participation.childId, - participation.status, - ]), +function getStats(termin: AdminTerminDto, rows: ChildDto[]) { + const isFamily = termin.rsvpMode === RsvpMode.FAMILY; + const statusByChildId = new Map( + isFamily + ? termin.familyParticipations.map((row) => [row.familyId, row.status]) + : termin.participations.map((row) => [row.childId, row.status]), + ); + const adultCounts = new Map( + termin.familyParticipations.map((row) => [row.familyId, row.adultCount]), ); - let attending = 0; let notAttending = 0; - - children.forEach((child) => { - const status = statusByChildId.get(child.id); - if (status === EventParticipationStatus.ATTENDING) attending += 1; + let adultCount = 0; + for (const row of rows) { + const status = statusByChildId.get(row.id); + if (status === EventParticipationStatus.ATTENDING) { + attending += 1; + adultCount += adultCounts.get(row.id) ?? 0; + } if (status === EventParticipationStatus.NOT_ATTENDING) notAttending += 1; - }); - + } return { attending, notAttending, - pending: Math.max(children.length - attending - notAttending, 0), + pending: rows.length - attending - notAttending, statusByChildId, + adultCounts, + adultCount, }; } diff --git a/src/app/dashboard/admin/kalender/page.tsx b/src/app/dashboard/admin/kalender/page.tsx index 9fcc6bb..768d808 100644 --- a/src/app/dashboard/admin/kalender/page.tsx +++ b/src/app/dashboard/admin/kalender/page.tsx @@ -14,7 +14,7 @@ export default async function AdminKalenderPage() { return
Kein Mandant zugeordnet.
; } - const [termine, children] = await Promise.all([ + const [termine, children, families] = await Promise.all([ prisma.termin.findMany({ where: { kitaId }, select: { @@ -28,6 +28,10 @@ export default async function AdminKalenderPage() { allDay: true, mitbringselListEnabled: true, requiresRsvp: true, + rsvpMode: true, + familyParticipations: { + select: { familyId: true, status: true, adultCount: true }, + }, rsvpDeadline: true, participantInfo: true, participations: { @@ -60,6 +64,11 @@ export default async function AdminKalenderPage() { { firstName: "asc" }, ], }), + prisma.family.findMany({ + where: { kitaId }, + select: { id: true, name: true }, + orderBy: { name: "asc" }, + }), ]); return ( @@ -70,6 +79,7 @@ export default async function AdminKalenderPage() { endDate: termin.endDate.toISOString(), rsvpDeadline: termin.rsvpDeadline?.toISOString() ?? null, }))} + familyRows={families} childRows={children.map((child) => ({ id: child.id, name: `${child.firstName} ${child.lastName}`, diff --git a/src/app/dashboard/admin/news/news-form.tsx b/src/app/dashboard/admin/news/news-form.tsx index 4f85420..628b0e7 100644 --- a/src/app/dashboard/admin/news/news-form.tsx +++ b/src/app/dashboard/admin/news/news-form.tsx @@ -64,7 +64,9 @@ export function NewsForm() { rows={10} value={content} onChange={(event) => setContent(event.target.value)} - placeholder={"## Liebe Familien,\n\nhier stehen die offiziellen Informationen..."} + placeholder={ + "## Liebe Familien,\n\nhier stehen die offiziellen Informationen..." + } required />

@@ -110,21 +112,23 @@ export function NewsForm() {

- {sendEmail && ( -
- - -
- )} +
+ +

+ Bestimmt, wer die Meldung und Anhänge in der App sehen darf und + optional die E-Mail erhält. +

+ +
diff --git a/src/app/dashboard/admin/news/page.tsx b/src/app/dashboard/admin/news/page.tsx index 0fde6ef..f885001 100644 --- a/src/app/dashboard/admin/news/page.tsx +++ b/src/app/dashboard/admin/news/page.tsx @@ -13,6 +13,7 @@ import { CardHeader, CardTitle, } from "@/components/ui/card"; +import { announcementAudienceLabels } from "@/lib/announcement-access"; import { NewsForm } from "./news-form"; export const metadata = { title: "Schwarzes Brett · Kita-Planer" }; @@ -30,6 +31,7 @@ export default async function AdminNewsPage() { select: { id: true, title: true, + audience: true, createdAt: true, attachments: { select: { @@ -63,8 +65,8 @@ export default async function AdminNewsPage() {

Veröffentliche verbindliche Ankündigungen für deine Kita. Anhänge - werden geschützt gespeichert und nur für eingeloggte Nutzer - derselben Kita ausgeliefert. + werden geschützt gespeichert und nur an die gewählte Empfängergruppe + deiner Kita ausgeliefert.

@@ -127,6 +129,9 @@ export default async function AdminNewsPage() { )} + + {announcementAudienceLabels[announcement.audience]} +

{format(announcement.createdAt, "dd.MM.yyyy HH:mm", { locale: de, diff --git a/src/app/dashboard/erzieher/_components/erzieher-list.tsx b/src/app/dashboard/erzieher/_components/erzieher-list.tsx index 14d2b99..d1c7c98 100644 --- a/src/app/dashboard/erzieher/_components/erzieher-list.tsx +++ b/src/app/dashboard/erzieher/_components/erzieher-list.tsx @@ -1,6 +1,8 @@ "use client"; import { useState, useTransition } from "react"; +import Link from "next/link"; +import { useRouter } from "next/navigation"; import { Plus, Pencil, Search, Trash2 } from "lucide-react"; import { toast } from "sonner"; @@ -29,18 +31,112 @@ import { TableRow, } from "@/components/ui/table"; -import { createEducator, updateEducator, deleteEducator } from "../actions"; +import { + createEducator, + updateEducator, + deleteEducator, + resendEducatorInvitation, +} from "../actions"; type EducatorDto = { id: string; firstName: string; lastName: string; active: boolean; + hasProfile: boolean; + email: string | null; + verified: boolean; + inviteFailed: boolean; }; -export function ErzieherList({ educators }: { educators: EducatorDto[] }) { +function AccessFields({ + prefix, + today, + educator, +}: { + prefix: string; + today: string; + educator?: EducatorDto; +}) { + return ( + <> +

+ + +

+ {educator?.email + ? "Diese Adresse gehört zum verknüpften Account." + : "An diese Adresse senden wir den persönlichen Aktivierungslink."} +

+
+ {!educator?.hasProfile && ( +
+
+ + +
+
+ + +
+

+ Ab diesem Datum werden Arbeitszeiten im Kita-Planer erfasst. + Arbeitstage, Urlaub und vorhandene Überstunden richtest du + anschließend im Personalprofil ein. +

+
+ )} + + ); +} + +export function ErzieherList({ + educators, + today, +}: { + educators: EducatorDto[]; + today: string; +}) { + const router = useRouter(); + const [search, setSearch] = useState(""); + const [formError, setFormError] = useState(""); + const filtered = educators.filter((ed) => + `${ed.firstName} ${ed.lastName} ${ed.email ?? ""}` + .toLocaleLowerCase("de") + .includes(search.toLocaleLowerCase("de")), + ); const [openCreate, setOpenCreate] = useState(false); - const [editingEducator, setEditingEducator] = useState(null); + const [editingEducator, setEditingEducator] = useState( + null, + ); const [educatorToDelete, setEducatorToDelete] = useState( null, ); @@ -51,15 +147,24 @@ export function ErzieherList({ educators }: { educators: EducatorDto[] }) { firstName: formData.get("firstName") as string, lastName: formData.get("lastName") as string, active: formData.get("active") === "on", + email: formData.get("email"), + employmentStart: formData.get("employmentStart"), + trackingStart: formData.get("trackingStart"), }; + setFormError(""); startTransition(async () => { const res = await createEducator(data); if (res.error) { - toast.error(res.error); + setFormError(res.error); } else { - toast.success("ErzieherIn angelegt."); + toast.success(res.message ?? "Fachkraft und Personalprofil angelegt."); + if (res.warning) toast.warning(res.warning, { duration: 12000 }); setOpenCreate(false); + if (res.educatorId) + router.push( + `/dashboard/personal?tab=verwaltung&educator=${res.educatorId}`, + ); } }); }; @@ -70,19 +175,35 @@ export function ErzieherList({ educators }: { educators: EducatorDto[] }) { firstName: formData.get("firstName") as string, lastName: formData.get("lastName") as string, active: formData.get("active") === "on", + email: formData.get("email"), + employmentStart: formData.get("employmentStart"), + trackingStart: formData.get("trackingStart"), }; + setFormError(""); startTransition(async () => { const res = await updateEducator(editingEducator.id, data); if (res.error) { - toast.error(res.error); + setFormError(res.error); } else { - toast.success("Daten aktualisiert."); + toast.success(res.message ?? "Daten aktualisiert."); + if (res.warning) toast.warning(res.warning, { duration: 12000 }); setEditingEducator(null); + router.refresh(); } }); }; + const handleResend = (educator: EducatorDto) => { + startTransition(async () => { + const res = await resendEducatorInvitation(educator.id); + if (res.error) toast.error(res.error); + else if (res.warning) toast.warning(res.warning, { duration: 12000 }); + else toast.success(res.message ?? "Einladung erneuert."); + router.refresh(); + }); + }; + const handleDelete = (educator: EducatorDto) => { startTransition(async () => { const res = await deleteEducator(educator.id); @@ -100,24 +221,44 @@ export function ErzieherList({ educators }: { educators: EducatorDto[] }) {
- + setSearch(e.target.value)} + className="pl-9" + />
- + { + if (!isPending) { + setOpenCreate(open); + setFormError(""); + } + }} + > - -
+ + { + event.preventDefault(); + handleCreate(new FormData(event.currentTarget)); + }} + > Neue(n) ErzieherIn anlegen - Erfasse die Stammdaten des Kita-Personals. + Lege Stammdaten, Personalprofil und App-Zugang gemeinsam an. + Die Fachkraft erhält ihren Aktivierungslink per E-Mail. -
+
@@ -126,14 +267,31 @@ export function ErzieherList({ educators }: { educators: EducatorDto[] }) {
+
-
+ + {formError && ( +

+ {formError} +

+ )} - - + + @@ -153,91 +311,188 @@ export function ErzieherList({ educators }: { educators: EducatorDto[] }) { -
- - - Vorname - Nachname - Status - Aktionen - - - - {educators.length === 0 ? ( +
+ - -
-
- -
-

- Keine Einträge gefunden -

-

- Lege die erste Person im Team an. -

-
- + Vorname + Nachname + E-Mail / App-Zugang + Status + Aktionen - ) : ( - educators.map((ed) => ( - - {ed.firstName} - {ed.lastName} - - - {ed.active ? "Aktiv" : "Inaktiv"} - - - - - + + + {filtered.length === 0 ? ( + + +
+
+ +
+

+ Keine Einträge gefunden +

+

+ Lege die erste Person im Team an. +

+
- )) - )} - -
+ ) : ( + filtered.map((ed) => ( + + + {ed.firstName} + + {ed.lastName} + +

+ {ed.email ?? "Noch keine E-Mail hinterlegt"} +

+ + {ed.verified + ? "Account aktiviert" + : ed.inviteFailed + ? "Mailversand fehlgeschlagen" + : ed.email + ? "Einladung ausstehend" + : "Zugang fehlt"} + + {ed.email && !ed.verified && ( + + )} + + + + {ed.active ? "Aktiv" : "Inaktiv"} + + + + + + + + + )) + )} + + {/* Edit Dialog */} - !open && setEditingEducator(null)}> - -
+ { + if (!open && !isPending) setEditingEducator(null); + }} + > + + { + event.preventDefault(); + handleUpdate(new FormData(event.currentTarget)); + }} + > ErzieherIn bearbeiten {editingEducator && ( -
+
- +
- +
+
- +
-
+ + )} + {formError && ( +

+ {formError} +

)} - - + + diff --git a/src/app/dashboard/erzieher/actions.ts b/src/app/dashboard/erzieher/actions.ts index ceba89d..dfaa8ae 100644 --- a/src/app/dashboard/erzieher/actions.ts +++ b/src/app/dashboard/erzieher/actions.ts @@ -6,74 +6,23 @@ import { z } from "zod"; import { requireRole } from "@/lib/auth-utils"; import { prisma } from "@/lib/prisma"; +import { staffAction } from "../personal/actions"; -const educatorSchema = z.object({ - firstName: z.string().min(1, "Vorname ist erforderlich").max(100).trim(), - lastName: z.string().min(1, "Nachname ist erforderlich").max(100).trim(), - active: z.boolean().default(true), -}); - +// The staff service creates the person, profile, account and mail job in one transaction. export async function createEducator(rawPayload: unknown) { - const session = await requireRole([UserRole.ADMIN]); - const kitaId = session.user.kitaId; - if (!kitaId) { - return { error: "Kein Mandant zugeordnet." }; - } - - const parsed = educatorSchema.safeParse(rawPayload); - if (!parsed.success) { - return { error: "Ungültige Eingabedaten." }; - } - - try { - await prisma.educator.create({ - data: { - kitaId, - firstName: parsed.data.firstName, - lastName: parsed.data.lastName, - active: parsed.data.active, - }, - }); - - revalidatePath("/dashboard/erzieher"); - return { success: true }; - } catch (error) { - console.error("Fehler beim Anlegen:", error); - return { error: "Ein Fehler ist aufgetreten." }; - } + const parsed = z.record(z.string(), z.unknown()).safeParse(rawPayload); + if (!parsed.success) return { error: "Ungültige Eingabedaten." }; + return staffAction("educatorCreate", parsed.data); } export async function updateEducator(id: string, rawPayload: unknown) { - const session = await requireRole([UserRole.ADMIN]); - const kitaId = session.user.kitaId; - if (!kitaId) { - return { error: "Kein Mandant zugeordnet." }; - } - - const parsed = educatorSchema.safeParse(rawPayload); - if (!parsed.success) { - return { error: "Ungültige Eingabedaten." }; - } - - try { - await prisma.educator.update({ - where: { - id, - kitaId, - }, - data: { - firstName: parsed.data.firstName, - lastName: parsed.data.lastName, - active: parsed.data.active, - }, - }); - - revalidatePath("/dashboard/erzieher"); - return { success: true }; - } catch (error) { - console.error("Fehler beim Aktualisieren:", error); - return { error: "Ein Fehler ist aufgetreten." }; - } + const parsed = z.record(z.string(), z.unknown()).safeParse(rawPayload); + if (!parsed.success) return { error: "Ungültige Eingabedaten." }; + return staffAction("educatorUpdate", { ...parsed.data, educatorId: id }); +} + +export async function resendEducatorInvitation(educatorId: string) { + return staffAction("educatorInvite", { educatorId }); } export async function deleteEducator(id: string) { @@ -82,15 +31,23 @@ export async function deleteEducator(id: string) { if (!kitaId) { return { error: "Kein Mandant zugeordnet." }; } - + try { + const profile = await prisma.staffProfile.findFirst({ + where: { educatorId: id, kitaId }, + }); + if (profile) + return { + error: + "Diese Fachkraft hat ein Personalprofil. Bitte auf inaktiv setzen, damit Zeiten und Konten erhalten bleiben.", + }; await prisma.educator.delete({ where: { id, kitaId, }, }); - + revalidatePath("/dashboard/erzieher"); return { success: true }; } catch (error) { diff --git a/src/app/dashboard/erzieher/page.tsx b/src/app/dashboard/erzieher/page.tsx index fa117ef..db5991b 100644 --- a/src/app/dashboard/erzieher/page.tsx +++ b/src/app/dashboard/erzieher/page.tsx @@ -3,6 +3,7 @@ import { UserRole } from "@prisma/client"; import { requireRole } from "@/lib/auth-utils"; import { prisma } from "@/lib/prisma"; +import { todayKey } from "@/lib/staff/calculations"; import { ErzieherList } from "./_components/erzieher-list"; export const metadata = { title: "ErzieherInnen · Kita-Planer" }; @@ -17,6 +18,18 @@ export default async function ErzieherPage() { firstName: true, lastName: true, active: true, + staffProfile: { + select: { + id: true, + user: { select: { email: true, emailVerifiedAt: true } }, + emails: { + where: { inviteToken: { not: null }, skippedAt: null }, + orderBy: { createdAt: "desc" }, + take: 1, + select: { failed: true }, + }, + }, + }, }, orderBy: [{ lastName: "asc" }, { firstName: "asc" }], }); @@ -36,8 +49,8 @@ export default async function ErzieherPage() {

- Stammdaten des Kita-Personals für interne Planung und spätere - Notdienst-Alarmierung. + Stammdaten des Teams und Zugang zu Beschäftigungsprofilen, + Urlaubsansprüchen und Arbeitszeitmodellen.

@@ -51,7 +64,16 @@ export default async function ErzieherPage() {
- + ({ + ...educator, + hasProfile: !!staffProfile, + email: staffProfile?.user?.email ?? null, + verified: !!staffProfile?.user?.emailVerifiedAt, + inviteFailed: !!staffProfile?.emails[0]?.failed, + }))} + /> ); } diff --git a/src/app/dashboard/kalender/_components/admin-termin-modal.tsx b/src/app/dashboard/kalender/_components/admin-termin-modal.tsx index e42c34f..d40688c 100644 --- a/src/app/dashboard/kalender/_components/admin-termin-modal.tsx +++ b/src/app/dashboard/kalender/_components/admin-termin-modal.tsx @@ -2,10 +2,11 @@ import type { ComponentProps, FormEvent } from "react"; import { useEffect, useMemo, useState, useTransition } from "react"; -import { TerminType } from "@prisma/client"; +import { RsvpMode, TerminType } from "@prisma/client"; import { Plus } from "lucide-react"; import { toast } from "sonner"; +import { suggestedRsvpMode } from "@/lib/rsvp"; import { Button } from "@/components/ui/button"; import { Dialog, @@ -28,6 +29,11 @@ type AdminTerminFormState = { startDate: string; endDate: string; allDay: boolean; + requiresRsvp: boolean; + rsvpMode: RsvpMode; + rsvpDeadline: string; + participantInfo: string; + mitbringselListEnabled: boolean; }; const initialFormState: AdminTerminFormState = { @@ -37,6 +43,11 @@ const initialFormState: AdminTerminFormState = { startDate: "", endDate: "", allDay: false, + requiresRsvp: false, + rsvpMode: RsvpMode.FAMILY, + rsvpDeadline: "", + participantInfo: "", + mitbringselListEnabled: false, }; type AdminTerminModalProps = { @@ -51,6 +62,12 @@ type AdminTerminModalProps = { startDate: Date; endDate: Date; allDay: boolean; + requiresRsvp: boolean; + rsvpMode: RsvpMode; + rsvpDeadline: Date | null; + participantInfo: string | null; + mitbringselListEnabled: boolean; + hasRsvpResponses: boolean; }; }; @@ -61,10 +78,12 @@ export function AdminTerminModal({ existingTermin, }: AdminTerminModalProps) { const [open, setOpen] = useState(false); - const [formState, setFormState] = useState(initialFormState); + const [formState, setFormState] = + useState(initialFormState); + const [modeTouched, setModeTouched] = useState(false); + const modeLocked = existingTermin?.hasRsvpResponses ?? false; const [isPending, startTransition] = useTransition(); const minDateTime = useMemo(() => getLocalDateTimeInputValue(new Date()), []); - const minEndDateTime = formState.startDate || minDateTime; // Initialize and reset form fields when modal opens useEffect(() => { @@ -78,10 +97,18 @@ export function AdminTerminModal({ startDate: getLocalDateTimeInputValue(existingTermin.startDate), endDate: getLocalDateTimeInputValue(existingTermin.endDate), allDay: existingTermin.allDay, + requiresRsvp: existingTermin.requiresRsvp, + rsvpMode: existingTermin.rsvpMode, + rsvpDeadline: existingTermin.rsvpDeadline + ? getLocalDateTimeInputValue(existingTermin.rsvpDeadline) + : "", + participantInfo: existingTermin.participantInfo ?? "", + mitbringselListEnabled: existingTermin.mitbringselListEnabled, }); } else { setFormState(initialFormState); } + setModeTouched(false); } }, [open, existingTermin]); @@ -91,7 +118,14 @@ export function AdminTerminModal({ ) => { setFormState((current) => { const next = { ...current, [key]: value }; - if (key === "startDate" && typeof value === "string" && next.endDate && next.endDate < value) { + if (key === "type" && !existingTermin && !modeTouched && !modeLocked) + next.rsvpMode = suggestedRsvpMode(value as TerminType); + if ( + key === "startDate" && + typeof value === "string" && + next.endDate && + next.endDate < value + ) { next.endDate = value; } return next; @@ -122,6 +156,13 @@ export function AdminTerminModal({ startDate: new Date(formState.startDate).toISOString(), endDate: new Date(formState.endDate).toISOString(), allDay: formState.allDay, + requiresRsvp: formState.requiresRsvp, + rsvpMode: formState.rsvpMode, + rsvpDeadline: formState.rsvpDeadline + ? new Date(formState.rsvpDeadline).toISOString() + : null, + participantInfo: formState.participantInfo, + mitbringselListEnabled: formState.mitbringselListEnabled, }; startTransition(async () => { @@ -138,7 +179,7 @@ export function AdminTerminModal({ toast.success( existingTermin ? "Termin wurde erfolgreich aktualisiert!" - : "Termin wurde direkt angelegt!" + : "Termin wurde direkt angelegt!", ); if (!existingTermin) { setFormState(initialFormState); @@ -156,11 +197,13 @@ export function AdminTerminModal({ {triggerLabel} - +
- {existingTermin ? "Termin bearbeiten (Admin)" : "Termin anlegen (Admin)"} + {existingTermin + ? "Termin bearbeiten (Admin)" + : "Termin anlegen (Admin)"} {existingTermin @@ -189,7 +232,9 @@ export function AdminTerminModal({ name="description" placeholder="Details zum Termin..." value={formState.description} - onChange={(event) => updateField("description", event.target.value)} + onChange={(event) => + updateField("description", event.target.value) + } /> @@ -200,18 +245,28 @@ export function AdminTerminModal({ name="type" value={formState.type} className="flex h-10 w-full rounded-lg border border-[var(--hairline)] bg-[var(--surface)] px-3 py-2 text-[13.5px] text-[var(--ink)] ring-offset-[var(--surface)] transition-colors hover:border-[var(--accent-mid)] focus-visible:border-[var(--accent)] focus-visible:outline-none focus-visible:ring-[3px] focus-visible:ring-[var(--focus-ring)]" - onChange={(event) => updateField("type", event.target.value as TerminType)} + onChange={(event) => + updateField("type", event.target.value as TerminType) + } required > - + - + - - + + @@ -225,7 +280,9 @@ export function AdminTerminModal({ type="datetime-local" min={existingTermin ? undefined : minDateTime} value={formState.startDate} - onChange={(event) => updateField("startDate", event.target.value)} + onChange={(event) => + updateField("startDate", event.target.value) + } required /> @@ -235,14 +292,82 @@ export function AdminTerminModal({ id="endDate" name="endDate" type="datetime-local" - min={formState.startDate || (existingTermin ? undefined : minDateTime)} + min={ + formState.startDate || + (existingTermin ? undefined : minDateTime) + } value={formState.endDate} - onChange={(event) => updateField("endDate", event.target.value)} + onChange={(event) => + updateField("endDate", event.target.value) + } required /> + + + {formState.requiresRsvp ? ( +
+ + + {modeLocked ? ( +

+ Die Antwortart ist wegen vorhandener Rückmeldungen gesperrt. +

+ ) : null} + + updateField("rsvpDeadline", e.target.value)} + /> + +