feat: Add initial SaaS application structure with .htaccess, index.php, and environment setup scripts
- Create .htaccess for Apache front-controller routing - Add README.md for public directory with project overview - Implement index.php as the main entry point with a preview of SaaS modules - Introduce PowerShell scripts to check prerequisites and prepare environment
This commit is contained in:
@@ -1,33 +1,52 @@
|
||||
# Implementation Foundation
|
||||
# SaaS First Zielbild
|
||||
|
||||
Das neue Zielprojekt liegt in `saas-app/`, damit der bisherige PHP-Bestand
|
||||
unangetastet als Referenz bestehen bleibt.
|
||||
Dieses Repository wird schrittweise von der Legacy-PHP-Anwendung auf eine
|
||||
mandantenfaehige SaaS-Struktur umgestellt. Das neue Zielprojekt liegt in
|
||||
`saas-app/`. Der Root-Bestand bleibt nur noch als Referenz fuer die bestehende
|
||||
Fachlogik erhalten.
|
||||
|
||||
Foundation-Stand:
|
||||
## Was in die SaaS-Version gehoert
|
||||
|
||||
- Laravel-nahe Ordnerstruktur ohne externe Downloads
|
||||
- Tenant-Resolution-Skelett ueber Host/Subdomain
|
||||
- Request-Context-Platzhalter
|
||||
- Grundrouten fuer Landing, Login und Dashboard
|
||||
- erste SQL-Migrationsskizzen fuer:
|
||||
- `tenants`
|
||||
- `users`
|
||||
- `tenant_users`
|
||||
- `roles`
|
||||
- `tenant_user_roles`
|
||||
- Blade-Layouts als Platzhalter fuer SSR-Ansatz auf Webspace
|
||||
Der fachliche Kern der bisherigen Anwendung ist klein und wird in der neuen
|
||||
Version gebuendelt:
|
||||
|
||||
Naechste Programmierphase:
|
||||
- Dashboard mit Kontostand und aktueller Uebersicht
|
||||
- Mitgliederverwaltung pro Mandant
|
||||
- Einzahlungen und Kaffee-Striche als Ledger-Buchungen
|
||||
- Hinweise, FAQ und einfache Inhalte
|
||||
- Export- und Import-Funktionen fuer den operativen Betrieb
|
||||
- Mandanten- und Rollenverwaltung
|
||||
|
||||
1. Identity-/Tenant-Agent auf `saas-app/app` und Auth-/Tenant-Module
|
||||
2. Ledger-/Core-Agent auf Mitglieder, Striche, Einzahlungen und Dashboard
|
||||
3. spaeter Operations-Agent fuer Importe, Mail, Umfragen und Exporte
|
||||
## Was bewusst entfallen kann
|
||||
|
||||
Blocker ausserhalb des Repos:
|
||||
Diese Bereiche sind fuer den ersten SaaS-Stand nicht zwingend notwendig und
|
||||
koennen spaeter nachgezogen oder ganz entfallen:
|
||||
|
||||
- `php` lokal nicht installiert
|
||||
- `composer` lokal nicht installiert
|
||||
- echtes Laravel-Scaffolding daher noch nicht moeglich
|
||||
- Jahresauswertung als Sonderprozess
|
||||
- CSV-Sonderlogiken aus der alten Webanwendung
|
||||
- manuelle Mail-Sammelaktionen ohne Workflow-Einbindung
|
||||
- Umfrage-Module, sofern sie fachlich nicht mehr benoetigt werden
|
||||
- alte PHP-Einzeldateien im Root, sobald die SaaS-Variante produktiv ist
|
||||
|
||||
Sobald Tooling vorhanden ist, soll dieses Geruest in ein vollstaendiges
|
||||
Laravel-Projekt ueberfuehrt werden.
|
||||
## Migrationspfad
|
||||
|
||||
1. Legacy-Fachlogik aus dem Root als Referenz verstehen.
|
||||
2. Kernbereiche in `saas-app/` neu umsetzen.
|
||||
3. Datenmodell auf Mandanten, Benutzer, Mitglieder, Buchungen und Inhalte
|
||||
normalisieren.
|
||||
4. Root-Anwendung nur noch fuer die Uebergangsphase vorhalten.
|
||||
5. Nach erfolgreichem Cutover alte Root-Seiten deaktivieren oder archivieren.
|
||||
|
||||
## Technische Leitplanken
|
||||
|
||||
- `saas-app/` ist die Zielstruktur.
|
||||
- Der Betrieb ist auf klassisches PHP-Hosting ausgerichtet.
|
||||
- Cron-Jobs ersetzen dauerhafte Worker.
|
||||
- OIDC ist der bevorzugte SSO-Pfad.
|
||||
- Blade-Views und SSR sind fuer einfache Hosting-Setups vorgesehen.
|
||||
|
||||
## Derzeitiger Stand
|
||||
|
||||
Das Zielgeruest ist bewusst schlank gehalten. Es beschreibt die Architektur und
|
||||
die Aufteilung der Module, ersetzt aber noch kein voll installiertes Laravel-
|
||||
Projekt mit lauffaehiger Runtime.
|
||||
|
||||
@@ -0,0 +1,87 @@
|
||||
# Installationshandbuch
|
||||
|
||||
Diese Anleitung beschreibt den vorgesehenen Weg fuer die SaaS-Version in
|
||||
`saas-app/`. Sie ist auf Webspace-Betrieb ohne Docker und ohne dauerhafte
|
||||
Worker ausgelegt.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- PHP 8.2 oder neuer
|
||||
- Composer
|
||||
- SQL Server oder eine kompatible Datenbank fuer das Zielsystem
|
||||
- Webserver mit Document-Root auf `public/` des Zielprojekts
|
||||
- Cron-Zugang
|
||||
- optional: SMTP-Zugang fuer Mails
|
||||
- optional: OIDC-Provider fuer SSO
|
||||
|
||||
## Installation lokal
|
||||
|
||||
1. Repository klonen.
|
||||
2. In `saas-app/` wechseln.
|
||||
3. Abhaengigkeiten mit Composer installieren.
|
||||
4. `.env` aus `.env.example` ableiten.
|
||||
5. Datenbankzugang, URL, Mail und Tenancy-Werte eintragen.
|
||||
6. Migrations ausfuehren.
|
||||
7. Einen ersten Mandanten anlegen.
|
||||
8. Einen ersten Benutzer und eine Mitgliedszuordnung anlegen.
|
||||
|
||||
## Wichtige Umgebungswerte
|
||||
|
||||
Die wichtigsten Werte liegen in `saas-app/.env.example` und muessen fuer die
|
||||
eigene Umgebung angepasst werden:
|
||||
|
||||
- `APP_URL`
|
||||
- `DB_HOST`, `DB_DATABASE`, `DB_USERNAME`, `DB_PASSWORD`
|
||||
- `TENANCY_MODE`
|
||||
- `TENANCY_CENTRAL_DOMAINS`
|
||||
- `TENANCY_FALLBACK_TENANT`
|
||||
- `OIDC_ENABLED`
|
||||
- Mail-Zugangsdaten
|
||||
|
||||
## Webspace-Deployment
|
||||
|
||||
1. Den Inhalt von `saas-app/` auf den Zielserver hochladen.
|
||||
2. Das Document-Root auf `public/` zeigen lassen.
|
||||
3. Schreibrechte fuer `storage/`, Cache und Queue-Tabellen sicherstellen.
|
||||
4. `.env` serverseitig hinterlegen.
|
||||
5. Die Anwendung einmal per Browser aufrufen und die Grundseiten pruefen.
|
||||
|
||||
## Cron- und Batch-Betrieb
|
||||
|
||||
Die Zielarchitektur nutzt Cron statt dauerhafter Worker.
|
||||
|
||||
Typische Aufgaben:
|
||||
|
||||
- Queue-Jobs verarbeiten
|
||||
- Import-Jobs abarbeiten
|
||||
- Export-Jobs erzeugen
|
||||
- Benachrichtigungen versenden
|
||||
- Aufraeum- und Statusjobs ausfuehren
|
||||
|
||||
Empfehlung: pro Aufgabe einen klar benannten Cron-Eintrag anlegen und die
|
||||
Ausgabe in Logdateien schreiben.
|
||||
|
||||
## Migration aus dem Legacy-System
|
||||
|
||||
Wenn Daten aus der alten Root-Anwendung uebernommen werden sollen, folgt die
|
||||
Reihenfolge:
|
||||
|
||||
1. Mitglieder und Rollen migrieren.
|
||||
2. Einzahlungen und Kaffeebuchungen uebernehmen.
|
||||
3. Hinweise, FAQ und Inhaltsseiten importieren.
|
||||
4. Mandanten-Zuordnung pruefen.
|
||||
5. Danach alte Root-Seiten nur noch lesend oder gar nicht mehr betreiben.
|
||||
|
||||
## Betriebscheck
|
||||
|
||||
Nach dem Setup sollten diese Punkte funktionieren:
|
||||
|
||||
- Login oder SSO-Startseite
|
||||
- Dashboard pro Mandant
|
||||
- Mitgliederliste
|
||||
- Buchungen und Kontostand
|
||||
- Hinweise und Content
|
||||
- Import- und Export-Status
|
||||
|
||||
Wenn einer dieser Bereiche fehlt, liegt meist entweder ein Tenancy-Fehler, ein
|
||||
DB-Problem oder eine unvollstaendige Deployment-Konfiguration vor.
|
||||
@@ -0,0 +1,48 @@
|
||||
# Legacy Zu SaaS Mapping
|
||||
|
||||
Diese Uebersicht verbindet die bisherige Root-Anwendung mit der neuen
|
||||
SaaS-Zielstruktur in `saas-app/`.
|
||||
|
||||
## Kernmodule
|
||||
|
||||
| Legacy-Datei | Bisherige Aufgabe | SaaS-Zielmodul |
|
||||
| --- | --- | --- |
|
||||
| `legacy-app/index.php` | persoenliches Dashboard, Kontostand, letzte Buchungen, Schnellaktion fuer Striche | Dashboard, Ledger, Payments |
|
||||
| `legacy-app/stricheintragen.php` | Sammelerfassung von Kaffee-Strichen | Ledger |
|
||||
| `legacy-app/einzahlung.php` | Sammelerfassung von Einzahlungen | Payments |
|
||||
| `legacy-app/kaffeeliste.php` | operative Gesamtuebersicht aller Mitglieder | Members, Ledger |
|
||||
| `legacy-app/mitarbeiterverwalten.php` | Mitgliederpflege, Aktivstatus, Admin-Rolle | Members, Tenants |
|
||||
| `legacy-app/letzteneintraege.php` | Korrektur und Loeschung letzter Buchungen | Ledger |
|
||||
| `legacy-app/teilnehmerauswertung.php` | Detailauswertung pro Person | Dashboard, Members, Exports |
|
||||
| `legacy-app/namenanpassen.php` | Pflege des Anzeigenamens | Members, Identity |
|
||||
| `legacy-app/hinweise.php` | Pflege globaler Hinweise | Content |
|
||||
| `legacy-app/faq.php` | statische Hilfeseite | Content |
|
||||
|
||||
## Zusatzmodule
|
||||
|
||||
| Legacy-Datei | Einordnung | SaaS-Strategie |
|
||||
| --- | --- | --- |
|
||||
| `legacy-app/csvupload.php` | operativer CSV-Sonderimport | optionales Import-Modul |
|
||||
| `legacy-app/exportKaffeeliste.php` | PDF-Export fuer Papierprozess | optionales Export-Modul |
|
||||
| `legacy-app/mailversenden.php` | Sammelbenachrichtigungen | Notifications |
|
||||
| `legacy-app/jahresauswertung.php` | Sonderprozess | spaeter oder Entfall |
|
||||
| `legacy-app/umfrage.php` | Zusatzfunktion | optionales Survey-Modul |
|
||||
| `legacy-app/umfrageergebnisse.php` | Zusatzfunktion | optionales Survey-Modul |
|
||||
| `legacy-app/mailausgebe.php` | Hilfs-/Debugseite | Entfall |
|
||||
|
||||
## Datenmodell
|
||||
|
||||
| Legacy-Tabelle | SaaS-Ziel |
|
||||
| --- | --- |
|
||||
| `kl_Mitarbeiter` | `users`, `tenant_users`, `members` |
|
||||
| `kl_Kaffeeverbrauch` | `coffee_entries`, `ledger_entries` |
|
||||
| `kl_Einzahlungen` | `payment_entries`, `ledger_entries` |
|
||||
| `kl_hinweise` | `announcements` |
|
||||
| `kl_config` | tenantbezogene Einstellungen und Feature-Flags |
|
||||
|
||||
## Prioritaet Fuer Die Umsetzung
|
||||
|
||||
1. Dashboard, Members, Ledger und Payments funktional schliessen.
|
||||
2. Content und Hinweise tenantfaehig machen.
|
||||
3. Importe, Exporte und Notifications als Backoffice-Module ergaenzen.
|
||||
4. Surveys und Sonderprozesse nur bei echtem Bedarf uebernehmen.
|
||||
Reference in New Issue
Block a user