Bernhard Müller
cfc32b3a7d
- Add TariffInviteServiceTest, GlobalExceptionHandlerTest, setup-test.ts - Add compose plans/specs docs - Extend .gitignore with *.xlsx, *.ps1, *.http, *.py, *.docx - Remove stale test data files and scripts from working tree
77 lines
3.9 KiB
Markdown
77 lines
3.9 KiB
Markdown
# Spec: Admin-Übersichten erweitern — Alle Mitgliedschaften & Alle Benutzer
|
|
|
|
## Zusammenfassung
|
|
|
|
Erweitere die beiden Admin-Seiten im EEG Portal, sodass Admins nicht nur ausstehende Anträge, sondern alle Mitgliedschaften und alle Benutzer mit Status-Filtern einsehen können.
|
|
|
|
## Ausgangslage
|
|
|
|
Zwei Admin-Seiten zeigen derzeit nur eingeschränkte Daten:
|
|
|
|
| Seite | Route | Aktueller Inhalt |
|
|
|-------|-------|-----------------|
|
|
| Admin-Mitgliedschaften | `/dashboard/admin-memberships` | Nur PENDING-Anträge mit Genehmigen/Ablehnen |
|
|
| Admin-Benutzerverwaltung | `/dashboard/approvals` | Nur PENDING+verifizierte User mit Freigeben/Ablehnen |
|
|
|
|
## Ziel
|
|
|
|
Admin sieht: (1) Alle Mitgliedschaften mit Status-Filter (Ausstehend / Aktive / Alle), (2) Alle Benutzer mit Status-Übersicht (Ausstehende / Alle).
|
|
|
|
## Anforderungen
|
|
|
|
### Backend
|
|
|
|
1. **Neuer Endpoint `GET /api/community/admin/memberships`** — Gibt alle Mitgliedschaften (PENDING, ACTIVE, INACTIVE) zurück. Gleiche DTO-Struktur wie `PendingMembershipResponse` (inkl. validFrom/validTo).
|
|
2. **Neuer Endpoint `GET /api/admin/users`** — Gibt alle registrierten Benutzer zurück. DTO: `UserProfileResponse` (bereits vorhanden).
|
|
3. **User-Entity erweitern** — `createdAt` (LocalDateTime) Feld hinzufügen für Sortierung nach Registrierungszeitpunkt. Wird in `AuthService.register()` gesetzt. `ddl-auto: update` erstellt die Spalte automatisch.
|
|
4. Bestehende `/pending`-Endpoints bleiben unverändert (Abwärtskompatibilität).
|
|
|
|
### Frontend
|
|
|
|
5. **Admin-Mitgliedschaften** — Tab-Navigation: "Ausstehende Anträge" | "Aktive Mitgliedschaften" | "Alle". Tab "Ausstehende" behält bestehende Karten-Ansicht. Tabs "Aktive" und "Alle" zeigen Tabellen-Ansicht.
|
|
6. **Admin-Benutzerverwaltung** — Tab-Navigation: "Ausstehende Anträge" | "Alle Benutzer". Tab "Ausstehende" behält bestehende Tabelle. Tab "Alle" zeigt Tabelle mit Status-Badges.
|
|
7. **Status-Anzeige (user-friendly)** — Technische Enums werden übersetzt:
|
|
|
|
| Entity | Technischer Status | Anzeige |
|
|
|--------|-------------------|---------|
|
|
| Membership | PENDING | "Ausstehend" |
|
|
| Membership | ACTIVE | "Aktiv" |
|
|
| Membership | INACTIVE | "Inaktiv" |
|
|
| User | PENDING | "Ausstehend" |
|
|
| User | APPROVED | "Freigeschaltet" |
|
|
| User | REJECTED | "Abgelehnt" |
|
|
|
|
8. Client-seitige Filterung (einmal alle Daten laden, Tabs per Signal filtern).
|
|
|
|
### Nicht im Scope
|
|
|
|
- Keine Paginierung (Datenmengen sind klein)
|
|
- Keine Server-seitige Filterung
|
|
- Keine Änderung an bestehenden Admin-Workflows (Genehmigen/Ablehnen)
|
|
- Keine Rollenverwaltung
|
|
|
|
## Technische Details
|
|
|
|
### MembershipService — getAllMemberships()
|
|
|
|
Nutzt `MembershipRepository.findAllWithDetails()` mit JOIN FETCH (gleiche Struktur wie `findPendingWithDetails()`, aber ohne WHERE-Clause auf Status). Anschließend gleiche User-Lookup-Logik wie `getPendingMemberships()`.
|
|
|
|
### PendingMembershipResponse — Erweiterung
|
|
|
|
Das bestehende DTO `PendingMembershipResponse` wird um `validFrom` und `validTo` erweitert. Da es ein Java record ist, müssen beide Felder hinzugefügt werden — der bestehende `getPendingMemberships()`-Code muss entsprechend angepasst werden.
|
|
|
|
### UserMapper — Mapping für UserProfileResponse
|
|
|
|
`UserMapper.mapToDto()` mappt `User` → `UserProfileResponse`. Das `createdAt`-Feld wird nicht ins DTO aufgenommen (nur für Server-seitige Sortierung).
|
|
|
|
## Akzeptanzkriterien
|
|
|
|
- [ ] `GET /api/community/admin/memberships` gibt alle Mitgliedschaften zurück (PENDING, ACTIVE, INACTIVE)
|
|
- [ ] `GET /api/admin/users` gibt alle Benutzer zurück (PENDING, APPROVED, REJECTED)
|
|
- [ ] Admin-Mitgliedschaften-Seite zeigt Tabs "Ausstehende | Aktive | Alle"
|
|
- [ ] Admin-Benutzerverwaltung-Seite zeigt Tabs "Ausstehende | Alle"
|
|
- [ ] Genehmigen/Ablehnen funktioniert weiterhin auf dem "Ausstehende"-Tab
|
|
- [ ] Status-Badges werden korrekt angezeigt (gelb=ausstehend, grün=aktiv/freigeschaltet, rot=inaktiv/abgelehnt)
|
|
- [ ] Bestehende REST-API Tests weiterhin bestehen
|
|
- [ ] Conventional Commits werden verwendet
|