diff --git a/docs/Bedarfsanalyse/Bedarfsanalyse-Gespräch-27.08.2026.md b/docs/Bedarfsanalyse/Bedarfsanalyse-Gespräch-27.08.2026.md new file mode 100644 index 0000000..5c03cf9 --- /dev/null +++ b/docs/Bedarfsanalyse/Bedarfsanalyse-Gespräch-27.08.2026.md @@ -0,0 +1,44 @@ +Bedarfanalyse Gespräche 27.08.2026 mit Sarah (Perspektivwerk) und Corinna (Produktionsschule) + +1) Das technische Umfeld in dem der Kalender genau stattfinden wird, ist noch nicht genau definiert. Es könnte als Komponente in Contao integriert werden, oder als unabhängiges eigenständiges tool mit eigener Runtime, Datenbank(Model) und Backend implementiert werden + +2) Damit Besucher ser Seiten Perspektivwerk (PW) und Produktionsschule (PS) nicht verwirrt sind, sollte nur dessen dezidierte Kalenderinstanz angezeigt werden. Kein Umschalten zwischen beiden möglich. Aber technisch sollten beide Kalender von der gleichen technischen Basis ausgeliefert werden. + +3) Im Backend soll wärend der Konfiguration des Kalenders eine Demo dessen live angezeigt werden, damit Änderungen ander Konfiguration sofort sichtbar sind. + +4) PS: einer der Termintypen heißt Probearbeiten, dieser + - 4.1) setzt vorraus das bereits die Einführungsveranstaltung absolviert wurde. Das wird geprüft durch eine entsprechende Checkbox und ein Eingabefeld in dem der Termin der Einführungsveranstaltung eingegeben werden muss. + - 4.2) Mehrfachanmeldungen sollen erkannt werden. Dazu wird, wenn Anmeldung bestätigt, der Anmeldename und die Email in einer History gespeichert. In der History kann geschaut werden, ob die Person bereits früher angemeldet war. + - 4.3) Das eine Person sich für mehrere Termine angemeldet hat wird in der Bestätigungsmail für einen zu buchenden Termin erwähnt und diese genannt. + +5) Alle Prozesse und Funktionen des Kalenders sollen durch technische Tests abgedeckt sein. Zb. Unit-Tests und Integration-tests. + +6) Jeder Termin hat eine definierte Auslastung/Kapazität (1-100). Wenn die angegebene Anzahl erreicht ist, wird der Termin als nicht weiter buchbar geführt. + +7) Im Kalender ist die Dauer eines Termins klar visuell erkennbar. Termine die nur bis max 4h dauern werden nicht weiter visuell hervorgehoben, aber ist ein Termin länger ist ein sichtbarer Balken für den Termin über den ganzen Tag zu sehen. Und Termine die über mehrere Tage gehen, haben einen sichtbaren Balken der sich über alle Tage ersteckt. + +8) Es ist zu prüfen, ob Bestätigungen nicht nur via E-Mail versendet werden können sondern auch via Signal Messanger. + +9) In der Terminbuchung soll keine freitext Nachricht ausfüllbar sein, kein entsprechendes Feld existieren. + +10) Es soll jeweils für PS und PW einen eigenen abonnierbaren ical Kalender geben, der immer aktuell alle bestätigten Termine enthält. Sobalt ein neuer Termin bestätigt ist, wird der ical Kalender entsprechend aktualisiert. + +11) Aktuell ist keine Benutzerverwaltung angedacht. Jeder der den Backend-Link hat, kann Termine eintragen/bearbeiten/löschen. + +12) Stornierung von Terminen durch Klienten soll aktuell einfach nur dadurch funktionieren, das diese sich bei der durchführenden Person melden können (Kontakt in Bestätigungsmail enthalten). Diese kann die angemeldete Person dann aus der Veranstaltung löschen. + +13) Klienten erhalten zwei Tage vor Beginn der Veranstaltung eine Errinerungsmail + +14) Für Klienten soll es einfach möglich sein mehrere Termine nacheinander zu buchen, dazu sollen die eingegebenen Anmeldedaten im Browser gespeicehrt bleiben, und angewendet werden, wenn ein weitere Termin gebucht wird. + +15) Ein Termin kann ein vor Ort oder ein Telefonischer Termin sein. + +16) BEi der Anmeldung für einen Termin ist die Angabe einer Telefonnummer verbindlich + +17) Exportfunktion im Backend: je für PS und PW sollen alle bestätigten Teilnehmer aller Termine eines definierbaren Zeitraums als Liste ausgegeben werden können. + +Bekannte Kalender Parameter welche durch Datenbank, Fontend und Backend abgedeckt sein müssen: + +- Wird der Kalender des PS oder PW angezeigt +- historische Teilnehmer an Terminen (name, email, Veranstaltungs-ID) +- Termindaten: ID, Name, Start, Ende, PS oder PW, Kapazität, Anmeldebedingungen (Einführungsveranstaltung besucht), durchführende Person (Benutzerliste mit Name + Email), Format (vor Ort oder Telefonisch) diff --git a/docs/IST-terminbuchung-mockup/10_produktbeschreibung.md b/docs/IST-terminbuchung-mockup/10_produktbeschreibung.md new file mode 100644 index 0000000..d5dbf20 --- /dev/null +++ b/docs/IST-terminbuchung-mockup/10_produktbeschreibung.md @@ -0,0 +1,26 @@ +# Produktbeschreibung – Terminbuchungskalender (Mockup) + +## Zweck dieses Dokuments + +Dieses Dokument beschreibt den gegenwärtigen Stand des Terminbuchungskalenders. Es ist die fachliche Ausgangsbasis. Technische Einbettung und Auslieferung sind ausdrücklich nicht Teil des beschriebenen Produkts. + +## Produktgegenstand + +Der Produktgegenstand ist ein eigenständiger, im Browser laufender Kalender für Terminangebote. Er soll Besuchenden ermöglichen, verfügbare Termine eines Projekts zu finden, einen passenden Slot auszuwählen und eine Terminanfrage vorzubereiten. + +Das Mockup kennt die Projekte `perspektivwerk` und `produktionsschule`. Eine Instanz des Kalenders ist jeweils genau einem Projekt zugeordnet. Eine Auswahl zwischen Projekten innerhalb derselben Kalenderansicht ist gegenwärtig nicht vorhanden. + +## Aktueller Nutzen + +Das Mockup macht die geplante Nutzerführung erfahrbar: + +- freie und belegte Tage sind im Monatskalender unterscheidbar, +- die Auswahl eines Tages zeigt dessen Slots, +- freie Slots führen zu einem Eingabedialog für eine Terminanfrage, +- der Dialog veranschaulicht die für eine spätere Anfrage denkbaren Angaben und die Datenschutzbestätigung. + +## Abgrenzung des aktuellen Mockups + +Das Mockup ist kein produktives Buchungssystem. Es reserviert keine Termine, speichert keine Eingaben und versendet keine E-Mails. Eine angezeigte Bestätigung ist ausschließlich eine lokale Erfolgsmeldung im Browser. + +Nicht Teil dieses Produktstands sind insbesondere Mitarbeitendenverwaltung, Terminpflege, Kalenderabonnements, ICS-Dateien, E-Mail-Bestätigungen, Stornierungen und eine serverseitige Schnittstelle. diff --git a/docs/IST-terminbuchung-mockup/20_funktionsstand.md b/docs/IST-terminbuchung-mockup/20_funktionsstand.md new file mode 100644 index 0000000..8f97006 --- /dev/null +++ b/docs/IST-terminbuchung-mockup/20_funktionsstand.md @@ -0,0 +1,39 @@ +# Funktionsstand – Terminbuchungskalender (Mockup) + +## Kalenderansicht + +Der Kalender zeigt einen Monat als Raster von Montag bis Sonntag. Die Monatsansicht lässt sich mit Schaltflächen vor- und zurückblättern. Der anfänglich gezeigte Monat richtet sich nach dem ersten vorhandenen Beispiel-Slot des konfigurierten Projekts. + +Tage mit mindestens einem freien Slot werden grün hervorgehoben und mit „frei“ beschriftet. Tage, an denen ausschließlich belegte Beispiel-Slots liegen, werden grau markiert und mit „belegt“ beschriftet. Tage ohne Slots bleiben neutral. Eine Legende erläutert die beiden Zustände. + +Jeder Tag ist über die Tastatur erreichbar. Für Screenreader enthält die Tagesauswahl ein Datum und – soweit vorhanden – den Verfügbarkeitszustand. + +## Slot-Auswahl + +Nach Auswahl eines Tages mit potentiell buchbaren Slots erscheint darunter eine Liste der Slots. Jeder Eintrag enthält Startzeit, Titel und Status. Belegte Slots sind als deaktivierte Schaltflächen dargestellt und können nicht ausgewählt werden. Freie Slots öffnen den Dialog zur Terminanfrage. + +## Dialog zur Terminanfrage + +Für einen freien Slot öffnet sich ein Dialog. Er zeigt Projekt, Datum, Uhrzeit und Terminart. Der Dialog enthält derzeit folgende Eingabefelder: + +- Vor- und Nachname – Pflichtfeld, +- E-Mail-Adresse – Pflichtfeld, +- Telefonnummer – freiwillig, +- Alter – freiwillig, +- Nachricht – freiwillig, +- Ansprechperson bei Agentur für Arbeit oder Jobcenter – freiwillig, +- Bestätigung des dargestellten Datenschutzhinweises – Pflichtfeld. + +Die Eingaben werden lokal validiert. Der Absende-Button wird erst nach Zustimmung zum Datenschutzhinweis aktiv. Beim Absenden prüft das Mockup die Felder, schließt den Eingabedialog und zeigt eine lokale Bestätigung an. + +## Nicht vorhandene Funktionalität + +Ein Absenden löst keine reale Aktion aus. Es gibt keine Speicherung, keine Slot-Reservierung, keine Double-Opt-in-E-Mail, keine Frist, keine Benachrichtigung und keine Sperrung gegen parallele Buchungen. + +## Checkpoints + +- [ ] Es ist entschieden, welche Terminstatus Besuchende sehen dürfen. +- [ ] Es ist bestätigt, welche Daten tatsächlich erhoben werden dürfen und müssen. +- [ ] Es ist entschieden, ob die dargestellte Zustimmung vor der Anfrage erforderlich ist und wie sie formuliert wird. +- [ ] Der künftige Ablauf nach dem Absenden ist fachlich festgelegt. +- [ ] Die Anforderungen für Stornierung, Umbuchung und Fehlerfälle sind dokumentiert. diff --git a/docs/IST-terminbuchung-mockup/30_technischer-stand.md b/docs/IST-terminbuchung-mockup/30_technischer-stand.md new file mode 100644 index 0000000..5dc9f4d --- /dev/null +++ b/docs/IST-terminbuchung-mockup/30_technischer-stand.md @@ -0,0 +1,40 @@ +# Technischer Stand – Terminbuchungskalender (Mockup) + +## Komponentenform + +Der Kalender ist eine browsernative JavaScript-Komponente als ES-Modul. Sie wird an einem Element mit dem Attribut `data-sufw-booking` initialisiert. Das Attribut `data-project` legt das Projekt fest; ein anderer oder fehlender Wert wird derzeit als `perspektivwerk` behandelt. + +Die Darstellung ist mit eigenem CSS umgesetzt. Die Klassen beginnen mit `sufw-booking`, damit die Stile möglichst wenig mit ihrer Umgebung kollidieren. + +## Zustandsverwaltung + +Der Zustand existiert ausschließlich im Arbeitsspeicher des Browsers: + +- ausgewähltes Projekt, +- aktuell dargestellter Monat, +- ausgewählter Tag, +- lokal geöffneter Dialog und dessen Formulareingaben. + +Eine erneute Initialisierung oder ein Neuladen der Seite setzt diesen Zustand zurück. + +## Datenquelle + +Slots sind als statisches JavaScript-Array im Mockup hinterlegt. Jeder Slot enthält eine Kennung, ein Projekt, ein Datum, eine Startzeit, einen Titel und einen Status. Die Komponente filtert diese Daten nach Projekt und Datum. + +Es gibt keine Netzwerkanfrage, keine Datenbankverbindung und keine serverseitige Geschäftslogik. + +## Eingabeverarbeitung + +Die Formularvalidierung findet vollständig im Browser statt. Sie prüft insbesondere Pflichtangaben, ein einfaches E-Mail-Format, optionale Telefon- und Altersangaben sowie Längenbegrenzungen. Die Slotdaten werden bei der HTML-Ausgabe maskiert. Die Formulareingaben werden nicht gespeichert oder weitergegeben. + +## Zugänglichkeit und Browserverhalten + +Die Komponente verwendet semantische Schaltflächen, Beschriftungen, `aria-live`-Bereiche, Statusinformationen und einen Dialog. Browser ohne Unterstützung für `dialog.showModal()` erhalten eine einfache offene Dialogvariante. Eine vollständige Prüfung mit Hilfstechnologien ist noch nicht erfolgt. + +## Checkpoints + +- [ ] Die künftige Datenquelle für Slots ist entschieden. +- [ ] Die serverseitigen Zustände und Regeln für Reservierung und Buchung sind definiert. +- [ ] Die Schnittstelle zwischen Oberfläche und Backend ist dokumentiert. +- [ ] Die Barrierefreiheit ist mit Tastatur, Screenreader und mobilen Geräten geprüft. +- [ ] Die Browserunterstützung des Endprodukts ist festgelegt. diff --git a/docs/IST-terminbuchung-mockup/40_datenmodell.md b/docs/IST-terminbuchung-mockup/40_datenmodell.md new file mode 100644 index 0000000..d745279 --- /dev/null +++ b/docs/IST-terminbuchung-mockup/40_datenmodell.md @@ -0,0 +1,30 @@ +# Datenmodell – Terminbuchungskalender (Mockup) + +## Gegenwärtiges Mockup-Datenmodell + +Das Mockup besitzt kein persistentes Datenmodell. Es verwendet nur flüchtige Beispielobjekte für Slots. Ein Beispiel-Slot enthält: + +- `id`: technisch eindeutige Beispielkennung, +- `project`: `perspektivwerk` oder `produktionsschule`, +- `date`: Datum im Format `YYYY-MM-DD`, +- `start`: Startzeit im Format `HH:MM`, +- `title`: sichtbare Bezeichnung der Terminart, +- `status`: `available` oder `booked`. + +Die Slots sind die einzige dauerhafte Information im Quellcode. Sie sind Testdaten und keine tatsächlichen Verfügbarkeiten. + +## Flüchtige Anfragedaten + +Der Anfrage-Dialog verarbeitet Name, E-Mail-Adresse, Telefonnummer, Alter, Nachricht, Ansprechperson und Zustimmungsstatus nur im Browser. Diese Werte werden weder als Buchung noch als Anfrageobjekt angelegt und nach dem Schließen des Dialogs verworfen. + +## Fachlich noch nicht modelliert + +Das Mockup enthält keine Entitäten für Buchung, Reservierung, Bestätigung, Stornierung, Terminraum, Mitarbeitende, Kalenderfeed, E-Mail oder Löschfristen. Auch Beziehungen zwischen Terminarten, Dauer, Ressourcen und Verfügbarkeitsregeln sind nicht modelliert. + +## Checkpoints + +- [ ] Es ist definiert, was einen buchbaren Slot fachlich eindeutig identifiziert. +- [ ] Es ist entschieden, welche Buchungszustände benötigt werden. +- [ ] Es ist festgelegt, welche Daten zu einer Anfrage gespeichert werden dürfen. +- [ ] Es ist geklärt, ob Räume, Mitarbeitende oder weitere Ressourcen modelliert werden müssen. +- [ ] Es existiert ein fachlich bestätigtes Datenmodell einschließlich Aufbewahrungs- und Löschregeln. diff --git a/docs/IST-terminbuchung-mockup/50_benutzerrollen.md b/docs/IST-terminbuchung-mockup/50_benutzerrollen.md new file mode 100644 index 0000000..eaf40cf --- /dev/null +++ b/docs/IST-terminbuchung-mockup/50_benutzerrollen.md @@ -0,0 +1,23 @@ +# Benutzerrollen – Terminbuchungskalender (Mockup) + +## Aktive Rolle im Mockup: Besuchende + +Das Mockup bildet ausschließlich die Rolle einer besuchenden Person ab. Diese Person kann einen Kalender ansehen, einen Tag wählen, freie und belegte Slots unterscheiden und für einen freien Slot eine lokale Terminanfrage simulieren. + +Die Rolle ist nicht authentifiziert. Es gibt keine Kontoerstellung, keine Anmeldung und keine Rechteprüfung. + +## Konfiguration statt Rolle: Projektzuordnung + +Die Projektwerte `perspektivwerk` und `produktionsschule` sind keine Benutzerrollen. Sie bestimmen nur, welche Beispiel-Slots eine Kalenderinstanz anzeigt. + +## Nicht vorhandene Rollen + +Das Mockup enthält keine Funktionen für Mitarbeitende, Koordination, Terminverwaltung, Datenschutzbearbeitung oder Administration. Es zeigt daher auch keine internen Buchungsdaten und erlaubt keine Änderung von Slots. + +## Checkpoints + +- [ ] Die tatsächlichen Benutzergruppen des Endprodukts sind benannt. +- [ ] Für jede Benutzergruppe sind erlaubte Aktionen und sichtbare Daten festgelegt. +- [ ] Es ist entschieden, ob Mitarbeitende ausschließlich lesend oder auch verwaltend arbeiten. +- [ ] Es ist geregelt, wer Datenschutzanfragen bearbeiten darf. +- [ ] Das Berechtigungsmodell ist vor einer produktiven Buchungsfunktion fachlich und technisch bestätigt. diff --git a/docs/IST-terminbuchung-mockup/60_datenschutz-sicherheit.md b/docs/IST-terminbuchung-mockup/60_datenschutz-sicherheit.md new file mode 100644 index 0000000..cb04597 --- /dev/null +++ b/docs/IST-terminbuchung-mockup/60_datenschutz-sicherheit.md @@ -0,0 +1,28 @@ +# Datenschutz und Sicherheit – Terminbuchungskalender (Mockup) + +## Datenschutzstatus des Mockups + +Das Mockup speichert und überträgt keine personenbezogenen Daten. Formularangaben werden nur für die unmittelbare Browservalidierung verarbeitet. Nach dem Schließen des Dialogs besteht im Mockup keine Buchung und keine dauerhafte Aufzeichnung der Eingaben. + +Der sichtbare Hinweis auf Art. 13 DSGVO ist gegenwärtig ein Platzhalter für die geplante Nutzerführung. Er stellt weder eine geprüfte Datenschutzerklärung noch eine dokumentierte Rechtsgrundlage dar. + +## Sicherheitsstatus des Mockups + +Es gibt keine API und damit keine serverseitige Eingabeverarbeitung, Authentifizierung, Autorisierung oder Datenbankabfrage. Das Mockup kann daher weder produktive Zugriffskontrollen noch Schutzmaßnahmen gegen Mehrfachbuchung, Bot-Anfragen oder E-Mail-Missbrauch demonstrieren. + +Die Ausgabe der statischen Slotdaten in dynamisch erzeugtes HTML erfolgt maskiert. Dies ist eine lokale Schutzmaßnahme, ersetzt aber keine vollständige Eingabevalidierung und Ausgabekodierung im Endprodukt. + +## Anforderungen vor produktivem Einsatz + +Sobald personenbezogene Daten verarbeitet werden, müssen Zweck, Rechtsgrundlage, Datenminimierung, Speicherfrist, Löschprozess, Betroffenenrechte, Berechtigungskonzept und technische Schutzmaßnahmen fachlich und rechtlich abgestimmt sein. + +Die endgültige Lösung benötigt außerdem serverseitige Validierung, CSRF-Schutz, Rate Limits, einen datenschutzgerechten Bot-Schutz, geschützte Protokollierung und kontrollierte Fehlermeldungen. E-Mail-Bestätigungen, Tokens und Kalenderdaten dürfen nicht allein im Browser umgesetzt werden. + +## Checkpoints + +- [ ] Die Datenschutzinformation nach Art. 13 DSGVO ist fachlich und rechtlich abgestimmt. +- [ ] Rechtsgrundlage, Zweck und minimal erforderliche Eingabedaten sind bestätigt. +- [ ] Speicherfristen und Löschkonzept sind definiert. +- [ ] Zugriffs- und Berechtigungskonzept für Buchungsdaten ist bestätigt. +- [ ] Sicherheitsanforderungen für API, E-Mail und Missbrauchsschutz sind definiert. +- [ ] Vor Produktivsetzung ist eine gesonderte Sicherheitsanalyse durchgeführt.