Bernhard Müller cfc32b3a7d chore: cleanup test data and add missing test files

- 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

2026-07-24 11:48:56 +02:00

3.9 KiB

Raw Blame History

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

Neuer Endpoint GET /api/community/admin/memberships — Gibt alle Mitgliedschaften (PENDING, ACTIVE, INACTIVE) zurück. Gleiche DTO-Struktur wie PendingMembershipResponse (inkl. validFrom/validTo).
Neuer Endpoint GET /api/admin/users — Gibt alle registrierten Benutzer zurück. DTO: UserProfileResponse (bereits vorhanden).
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.
Bestehende /pending-Endpoints bleiben unverändert (Abwärtskompatibilität).

Frontend

Admin-Mitgliedschaften — Tab-Navigation: "Ausstehende Anträge" | "Aktive Mitgliedschaften" | "Alle". Tab "Ausstehende" behält bestehende Karten-Ansicht. Tabs "Aktive" und "Alle" zeigen Tabellen-Ansicht.
Admin-Benutzerverwaltung — Tab-Navigation: "Ausstehende Anträge" | "Alle Benutzer". Tab "Ausstehende" behält bestehende Tabelle. Tab "Alle" zeigt Tabelle mit Status-Badges.
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"

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

3.9 KiB Raw Blame History