Join-Requests als separate Tabelle (Option B) #130

Closed
opened 2026-06-27 18:33:33 +02:00 by niboer · 0 comments
Owner

Hintergrund

Im Rahmen von Issue #102 wurde der Bug behoben, dass ein Benutzer seine eigene Beitrittsanfrage genehmigen konnte. Als Sofortmassnahme (Option A) wurde requireGroupMember in auth.ts um den Filter approvedBy: { not: null } ergaenzt und ein zusaetzlicher Self-Approval-Check im PUT-Handler eingebaut.

Option B — Separate Tabelle fuer Join-Requests

Die aktuelle Architektur nutzt GroupMember.approvedBy als Zustandsindikator: null = ausstehend, gesetzt = genehmigt. Das fuehrt zu semantisch uneindeutigen Zustaenden.

Vorgeschlagene Aenderung

  • Neues Prisma-Modell JoinRequest { personId, groupId, createdAt }
  • GroupMember.approvedBy wird required (NOT NULL in der DB)
  • POST /join-request erzeugt einen JoinRequest (kein GroupMember mehr)
  • PUT /join-request + action: 'approve' erzeugt GroupMember mit approvedBy
  • PUT /join-request + action: 'reject'' loescht den JoinRequest
  • DB-Constraint: groupId + personId UNIQUE in JoinRequest

Vorteile

  • Semantisch saubere Trennung: JoinRequest = Anfrage, GroupMember = bestaetigte Mitgliedschaft
  • DB-Level-Schutz: approvedBy kann nie null sein (NOT NULL Constraint)
  • Kein versehentliches Uebersehen von approvedBy: null in WHERE-Klauseln
  • Type-Safety: TypeScript erzwingt approvedBy beim Erstellen eines GroupMember

Nachteile

  • Schema-Migration erforderlich (neue Tabelle, bestehende GroupMember-Records migrieren)
  • Zwei Tabellen statt einer → mehr Code im Handler und in Tests
  • Der POST-Endpunkt muss statt groupMember.create jetzt joinRequest.create aufrufen
  • PUT-Endpunkt muss joinRequest.findUnique statt groupMember.findUnique nutzen
  • Bestehende Seeds und Tests muessen angepasst werden

Status

Nicht umgesetzt. Option A ist aktiv (siehe Commit 3e3d6ab). Diese Issue dient der Evaluation fuer MS-REST ob der Aufwand gerechtfertigt ist.

## Hintergrund Im Rahmen von Issue #102 wurde der Bug behoben, dass ein Benutzer seine eigene Beitrittsanfrage genehmigen konnte. Als Sofortmassnahme (Option A) wurde `requireGroupMember` in `auth.ts` um den Filter `approvedBy: { not: null }` ergaenzt und ein zusaetzlicher Self-Approval-Check im PUT-Handler eingebaut. ## Option B — Separate Tabelle fuer Join-Requests Die aktuelle Architektur nutzt `GroupMember.approvedBy` als Zustandsindikator: `null` = ausstehend, gesetzt = genehmigt. Das fuehrt zu semantisch uneindeutigen Zustaenden. ### Vorgeschlagene Aenderung - Neues Prisma-Modell `JoinRequest { personId, groupId, createdAt }` - `GroupMember.approvedBy` wird `required` (NOT NULL in der DB) - `POST /join-request` erzeugt einen `JoinRequest` (kein `GroupMember` mehr) - `PUT /join-request + action: 'approve'` erzeugt `GroupMember` mit `approvedBy` - `PUT /join-request + action: 'reject''` loescht den `JoinRequest` - DB-Constraint: `groupId` + `personId` UNIQUE in `JoinRequest` ### Vorteile - Semantisch saubere Trennung: `JoinRequest` = Anfrage, `GroupMember` = bestaetigte Mitgliedschaft - DB-Level-Schutz: `approvedBy` kann nie null sein (NOT NULL Constraint) - Kein versehentliches Uebersehen von `approvedBy: null` in WHERE-Klauseln - Type-Safety: TypeScript erzwingt `approvedBy` beim Erstellen eines `GroupMember` ### Nachteile - Schema-Migration erforderlich (neue Tabelle, bestehende `GroupMember`-Records migrieren) - Zwei Tabellen statt einer → mehr Code im Handler und in Tests - Der POST-Endpunkt muss statt `groupMember.create` jetzt `joinRequest.create` aufrufen - PUT-Endpunkt muss `joinRequest.findUnique` statt `groupMember.findUnique` nutzen - Bestehende Seeds und Tests muessen angepasst werden ### Status Nicht umgesetzt. Option A ist aktiv (siehe Commit 3e3d6ab). Diese Issue dient der Evaluation fuer MS-REST ob der Aufwand gerechtfertigt ist.
Sign in to join this conversation.
No description provided.