ah-admin
311153b3c3
- server/: Express-API (Auth, Bootstrap, Tickets, Threads, Benutzerverwaltung, Codes) mit pg-Schema (11 Tabellen), idempotem Seed (50 Wohnungen, 552 Buchungen) - mp-db (PostgreSQL 16, Volume mp_pgdata) + mp-api im Compose-Stack, nginx proxiet /api/ an mp-api; deploy.sh baut API-Image auf dem Server - Frontend: Store laedt /api/bootstrap, Schreibzugriff async, kein localStorage mehr (ausser Theme), Ladebildschirm beim Session-Check, vite-Proxy fuer Dev - Rollenrechte serverseitig: Mieter nur eigene Wohnung (getestet, 403-Verweis) - Mail-Benachrichtigungen komplett serverseitig (server/src/mail.js) - beispieldaten.py schreibt server/seed/generated.json; Verwaltungs-Mail = axel@hocks.eu - E2E live verifiziert: Login, Scoping, Ticket + Zustellung (status=sent), Registrierung, Codes; Testdaten bereinigt; Doku nachgefuehrt
68 lines
3.3 KiB
Markdown
68 lines
3.3 KiB
Markdown
# Hinterstein Immobilien · Mieterportal
|
||
|
||
Mieterportal der **Hinterstein Immobilien** für **50 Wohnungen in 3 Häusern** (Hauptstraße 12 ·
|
||
Ringweg 3 · Am Park 5) – analog zum [Schulportal](https://git.hocks.eu/ah-admin/Schulportal).
|
||
Live-Ziel: `https://mieterportal.hocks.eu`.
|
||
|
||
## Module
|
||
|
||
1. **Dashboard** – persönliche Übersicht (Mieter) bzw. Kennzahlen, Belegung und Einnahmen (Verwaltung)
|
||
2. **Benutzerverwaltung** (nur Verwaltung) – Konten anlegen/pflegen, Registrierungscodes erzeugen
|
||
3. **Mietkonto & Zahlungen** – Buchungsverlauf, offene Forderungen, Nebenkosten; Verwaltung sieht Zahlungsstatus aller 50 Wohnungen
|
||
4. **Schadensmeldungen** – Tickets erfassen, priorisieren und Status pflegen
|
||
5. **Dokumente** – Verträge, Abrechnungen, Hausordnung; zentraler Such- und Filterzugriff
|
||
6. **Nachrichten** – Direktkommunikation Mieter ↔ Verwaltung
|
||
|
||
**Anmeldung erforderlich** – Gruppen: **Verwaltung** und **Mieter** (Registrierung der Mieter per Code auf der Startseite).
|
||
Demo-Zugänge (Passwort jeweils `0815`): `j.hinterstein` (Verwaltung) · `a.berger` (Mieterin) · Demo-Registrierungscode: `MP-2026-0815`.
|
||
|
||
## Architektur (v1.3)
|
||
|
||
- **Frontend:** React-SPA (statisch, nginx-Container `mp-portal`)
|
||
- **API:** Node/Express (`server/`, Container `mp-api`) – Auth, Daten, Rollenrechte,
|
||
serverseitige E-Mail-Benachrichtigungen
|
||
- **Datenbank:** PostgreSQL 16 (Container `mp-db`, Volume `mp_pgdata`) – zentrale
|
||
Datenhaltung für alle Nutzer, kein localStorage mehr (außer Dark-Mode-Theme)
|
||
- Sitzung: HttpOnly-Cookie (8 h), Passwörter als SHA-256-Hash
|
||
|
||
## Entwicklung
|
||
|
||
```bash
|
||
npm install
|
||
npm run dev # http://localhost:3000 (proxyt /api an localhost:3001)
|
||
npm run build # Produktionsbuild nach dist/
|
||
python beispieldaten.py # generiert server/seed/generated.json (Seed wählbar)
|
||
```
|
||
|
||
Projekt-Kontext für Kimi Work: [kimi.md](kimi.md).
|
||
|
||
## Deployment (bewährter Workflow, s. kimi.md Kap. 4)
|
||
|
||
```bash
|
||
./deploy.sh
|
||
```
|
||
|
||
baut das Frontend, lädt Paket (dist + compose + nginx-Template + `server/`) per `pscp`
|
||
auf den Server (Port 38592, Pageant-Key `Z:\Devel\ssh\priv_ionos_hocks_vps.ppk`) und
|
||
startet den Stack neu inkl. API-Image-Build (`docker compose up -d --build`):
|
||
`mp-portal` (nginx), `mp-api` (Node-API), `mp-db` (PostgreSQL). TLS/Subdomain liefert
|
||
der Nginx Proxy Manager (npm_default-Netz). Voraussetzung auf dem Server:
|
||
`portal.env` mit `MAIL_API_TOKEN` + `POSTGRES_PASSWORD` und `.env`-Symlink darauf
|
||
(s. kimi.md Kap. 4).
|
||
|
||
Alternativ lokal ohne Server: `docker build -t mieterportal . && docker run -p 8080:80 mieterportal`.
|
||
|
||
## Mail-Stack & Benachrichtigungen
|
||
|
||
`mail-server/` enthält den aus dem Schulportal übernommenen Aufbau: Postfix-Relay
|
||
(nur intern, kein offenes Relay) + schlanke Python-API. Konfiguration über
|
||
`mail-server/mail.env` (Vorlage: `mail.env.example`), **nicht** im Repo.
|
||
|
||
Auf dem Server läuft der Stack unter `/opt/mp-mail`. Das Portal ist verkabelt:
|
||
Der nginx des `mp-portal`-Containers proxiet ausschließlich `POST /api/mail/send`
|
||
an die Mail-API und authentifiziert sich dabei serverseitig mit dem Token aus
|
||
`portal.env` (nur auf dem Server, gitignored). Die **Node-API** benachrichtigt die
|
||
Verwaltung bei neuen Schadensmeldungen und die jeweilige Gegenstelle bei
|
||
Nachrichten – Versand fire-and-forget, ein Ausfall der Mail-API beeinträchtigt
|
||
das Portal nicht.
|