89 lines
9.1 KiB
Markdown
89 lines
9.1 KiB
Markdown
# Papa-Kind-Treff – Projektkontext
|
||
|
||
Stand: 2026-08-07
|
||
|
||
## Kurzbeschreibung
|
||
Papa-Kind-Treff ist eine PHP-basierte Plattform für Väter. Kernbereiche sind lokale Events, Termine und Treffen, ein Community-Forum, Mitgliederprofile mit optionalen Kinderinfos und ein Moderations-/Adminbereich.
|
||
|
||
## Wichtige Produktentscheidungen
|
||
- Die Hauptnavigation ist bewusst knapp gehalten: `Home`, `Event Suche`, `Community`.
|
||
- `Events` ist der Primärbegriff im Produkt.
|
||
- `Termine` und `Treffen` werden ergänzend in SEO- und Erklärungstexten genutzt.
|
||
- Die Community ist hierarchisch aufgebaut: Kategorien -> Boards -> Threads -> Posts.
|
||
- Moderation ist vom normalen Community-Frontend getrennt.
|
||
- Standortfunktionen sind relevant für lokale Events, Termine und Treffen.
|
||
- Die bestehende `events`-Logik bleibt zunächst aktiv, wird aber künftig von einer allgemeineren Listing-/Ort-/Termin-Struktur abgelöst.
|
||
- Seiten-Admins erhalten eine eigene System-Sektion für globale Betriebs- und Diensteschalter.
|
||
|
||
## Konto / Mitgliederbereich
|
||
- Das Profilmenü oben rechts enthält nur `Profil`, für berechtigte Nutzer zusätzlich `Admin-Einstellungen`, sowie `Abmelden`.
|
||
- Der Profilbereich enthält persönliche Angaben, Kinder, eigene Events, eigene Orte und Veranstaltungen, Cookie-/Kontoeinstellungen sowie Community-Informationen.
|
||
- Der Admin-Bereich ist getrennt vom Profilbereich und enthält abhängig von der Berechtigung Profil-Levels, Kategorien, System-Einstellungen sowie Community-Moderation und Listing-Freigaben.
|
||
- Die Admin-Unterbereiche bleiben im selben Dashboard-Layout. Listing-Freigaben zeigen ausschließlich noch nicht veröffentlichte Orte und Veranstaltungen inklusive direkter Bearbeitung; Community-Moderation zeigt nur offene Bewerbungen und Meldungen; Rollen und System-Levels liegen im User Management, die Community-Migration liegt unter System.
|
||
- Bestehende Direktlinks zu `Kategorien`, `Profil-Levels` und `System` werden automatisch in den Admin-Bereich eingeordnet.
|
||
- Kinder können angelegt, bearbeitet und gelöscht werden.
|
||
- Wenn ein Geburtsdatum gesetzt ist, wird das Alter automatisch berechnet und später bei Bedarf aktualisiert.
|
||
- Die Konto-E-Mail wird app-seitig verschlüsselt gespeichert und über einen separaten HMAC-Lookup-Hash adressiert.
|
||
- Profiladresse kann per Suche oder Browser-Standort übernommen werden.
|
||
- Der Bereich `Events` ist wieder auf echte eigene Events und Event-Teilnahmen begrenzt.
|
||
- Der Bereich `Events` bietet zusätzlich einen manuellen ICS-Export und einen persönlichen abonnierbaren Kalender-Feed für alle eigenen Events und Event-Teilnahmen.
|
||
- Der Bereich `Events` ist im UI in `Meine Events`, `Kalendersynchronisation` und `Abgelaufene Events` getrennt, damit aktive Events, Kalender-Themen und Vergangenes sauber getrennt bleiben.
|
||
- In `Meine Events` sitzt der Button `Neues Event anlegen` jetzt direkt in der oberen Tab-Zeile; die bisherige Teilnahme-Box heißt `Angemeldete Events` und enthält zusätzlich einen direkten Link zur `Event Suche`.
|
||
- Orte und Veranstaltungen sind vorerst in einen separaten Mitgliederbereichspunkt `Orte & Veranstaltungen` verschoben.
|
||
- In `Orte & Veranstaltungen` können Nutzer dauerhafte Orte und zeitlich begrenzte Veranstaltungen neu anlegen.
|
||
- Neue Orte und Veranstaltungen bleiben bis zur Freigabe im Status `wartet auf Freigabe` und werden erst danach systemweit veröffentlicht.
|
||
- Noch nicht veröffentlichte Orts- und Veranstaltungsvorschläge können vom Ersteller im Mitgliederbereich direkt weiterbearbeitet werden.
|
||
- Änderungs- und Löschwünsche für veröffentlichte Orte und Veranstaltungen laufen immer über eine begründete Moderationsanfrage.
|
||
- Vorschläge für neue Orte und Veranstaltungen dürfen schon vor der Freigabe als Ortsvorschlag für Events genutzt werden, solange sie noch offen geprüft werden.
|
||
- Dubletten bei Orten und Veranstaltungen sollen serverseitig mindestens über Namen und Adresse abgefangen werden.
|
||
- Die Eingabe im Bereich `Events` soll so einfach wie möglich bleiben und zeigt deshalb nur die für echte Termine relevanten Felder.
|
||
- Eigene Events nutzen jetzt als Pflichtfelder nur noch Titel, Datum und `Mit Kindern`; die Beschreibung ist optional.
|
||
- Für die Event-Location gibt es jetzt die Auswahl `Ort aus Datenbank`, `Veranstaltung aus Datenbank` oder `Benutzerdefiniert`.
|
||
- Bei `Ort` oder `Veranstaltung` werden Adresse und Kategorie direkt aus dem gewählten Datenbank-Eintrag übernommen.
|
||
- Die Auswahl für Datenbank-Locations läuft im Event-Formular jetzt über ein echtes Auswahlfeld statt über Freitext; `Ort aus Datenbank` zeigt nur Orte, `Veranstaltung aus Datenbank` nur aktuell laufende Veranstaltungen im gültigen Zeitraum.
|
||
- Im Formular für eigene Events sind `Gültig bis` und `Wiederholung` ausgeblendet.
|
||
- Bei eigener Event-Location aus der Datenbank werden Adresse und Kategorie nur als Info angezeigt und nicht direkt bearbeitet.
|
||
- Aus dem Formular für eigene Events kann direkt in das Anlegen eines neuen Orts oder einer neuen Veranstaltung gewechselt werden.
|
||
- Nach diesem Zwischenschritt kehrt der Nutzer wieder in sein Event zurück; die bisherige Event-Eingabe bleibt erhalten und der neu angelegte Ort bzw. die neue Veranstaltung wird direkt ausgewählt.
|
||
- Bei `Veranstaltung aus Datenbank` muss das Event-Datum innerhalb des hinterlegten Gültigkeitszeitraums dieser Veranstaltungs-Quelle liegen.
|
||
- Kategorien werden im Mitgliederbereich per Sucheingabe mit bestehenden Vorschlägen und automatischer Neuanlage gepflegt.
|
||
- Eigene Events unterstützen optionalen Beschreibungstext, Ja/Nein-Angabe `Mit Kindern`, optionale Platzzahl, optionales Bild sowie eine Location aus Datenbank oder benutzerdefinierte Adresse.
|
||
- `Profil-Levels` ist ein Owner-Bereich für Community-Level und die Übersicht der System-Level.
|
||
- Community-Level sind jetzt über `system_settings.community_levels_json` editierbar und enthalten aktuell die Rechte `Hilfreiche Antworten hervorheben` und `Bewerbung als Forum-Admin`.
|
||
- In `Profil-Levels` kann der Owner zusätzlich Benutzer suchen und Community-Punkte manuell mit Begründung erhöhen.
|
||
- In `Profil-Levels` gibt es zusätzlich eine Liste von Nutzern, die in den letzten 30 Tagen mindestens den Rang `Säule der Väter-Community` erreicht haben.
|
||
- System-Level bleiben getrennt als Rollen `Forum-Admin`, `Site-Admin` und `SiteOwner`.
|
||
- `Forum-Admin` kann Kategorien bereits bestätigen und zusammenführen sowie Orte und Veranstaltungen freigeben.
|
||
- `SiteOwner` und `Site-Admin` erben diese Freigaberechte vollständig mit.
|
||
- Die Vergabe von System-Leveln läuft im Bereich `Community-Admin` jetzt über eine Benutzersuche statt über rohe Benutzer-IDs; `Site-Admins` bleiben auf die bestehende Rollenlogik begrenzt.
|
||
- Kategorien liegen nicht mehr unter `System`, sondern in einem eigenen Mitgliederbereichspunkt `Kategorien`; dort werden nur neue Kategorien angezeigt und per Vorschlagsfeld mit bestehenden Kategorien aus der Datenbank zusammengeführt.
|
||
- Neue Kategorien bleiben dort sichtbar, bis sie von einem Berechtigten bestätigt oder mit einer bestehenden Kategorie zusammengeführt werden.
|
||
- Im Bereich `Kategorien` gibt es zusätzlich eine Suche über bestehende Kategorien, damit sie gezielt gefunden und zusammengeführt werden können.
|
||
- Beim Zusammenführen wird die nicht zu behaltende Kategorie anschließend vollständig entfernt und die Ansicht danach frisch neu geladen.
|
||
- Zusammengeführte Kategorien werden zusätzlich intern als Redirect gesperrt, damit Standard-Seed oder spätere Eingaben sie nicht erneut auswählbar machen.
|
||
- Beim Zusammenführen kann explizit festgelegt werden, welche der beiden Kategorien erhalten bleibt.
|
||
- Community-Level können zusätzlich die Rechte für Kategorien sowie für die Freigabe von Orten und Veranstaltungen tragen.
|
||
- Bestehende gespeicherte Community-Level erhalten diese beiden Rechte im Fallback automatisch ab 750 Punkten, solange sie nicht explizit anders gespeichert wurden.
|
||
|
||
## Technischer Rahmen
|
||
- eigener Front-Controller in `public/index.php`
|
||
- Templates unter `partials/`
|
||
- Geschäftslogik unter `src/App/`
|
||
- Globales Frontend vor allem über `public/assets/js/app.js` und `public/assets/css/app.css`
|
||
|
||
## Neue Ausbaustufe: Termin-/Ort-System
|
||
- Neue Tabellenbasis: `listing_places`, `listings`, `listing_occurrences`, `listing_prices`, `listing_benefits`, `listing_categories`
|
||
- Ziel: spätere Unterscheidung zwischen eigenem Event, Partner-Angebot, allgemeinem Ort und redaktionellem Termin
|
||
- Google ist noch nicht aktiv integriert; das System wird nur vorbereitend über Settings und Datenfelder darauf ausgelegt
|
||
|
||
## Vorgemerkte To-dos
|
||
- Kalender-Integration großer Anbieter soll später zusätzlich zum ICS-Feed kommen, zuerst vor allem für Google und Microsoft/Outlook.
|
||
- Zielbild dafür ist keine Rücksynchronisierung, sondern ein nutzerseitiges OAuth-Login über Papa-Kind-Treff und danach eine direkte Kalender-Verknüpfung oder Event-Synchronisierung beim jeweiligen Anbieter.
|
||
|
||
## Pflegehinweis
|
||
Bei Änderungen immer auch die parallelen Dateien in `Internal/en/` prüfen und inhaltlich gleichziehen.
|
||
|
||
## Dokumentationsprinzip
|
||
- `Internal/de/` und `Internal/en/` werden bewusst parallel gepflegt.
|
||
- Die Root-`README.md` dient als Start-Doku für neue Chats und muss bei grundlegenden Änderungen ebenfalls mitgeprüft werden.
|