Tote CCs zurueckholen, Redesign-Beitritte und Problemfaelle

Vier Punkte aus dem Betrieb.

Ein toter CC liess sich nicht zurueckholen. Der Knopf dafuer wurde nie
angezeigt: bei Grund "Im RP gestorben" landete die Seite im Zweig "Bezahlt
reaktivieren", den der Server zu Recht abweist - ein Toter kehrt nur durch
einen Administrator zurueck. Der Dialog dafuer war fertig gebaut und wurde
schlicht nie geoeffnet. Jetzt steht an einem toten CC "Zurueckholen", fuer
Editoren stattdessen der Hinweis, dass das ein Administrator entscheidet.

Der Abgleich eines einzelnen Spielers fragte nur dessen hinterlegte SteamID
ab. Guthaben, das unter einem frueheren Konto gekauft wurde, blieb damit
unsichtbar - obwohl das Konto hinterlegt war und der Sammellauf es beruecksichtigt
hat. Jetzt werden alle Kennungen des Spielers abgefragt.

Ein Beitritt zu einem Gruppen-CC ueber ein Redesign kostete nur das Guthaben.
Damit entstand aus einem Redesign ein zusaetzlicher CC, was die Regel gerade
nicht hergibt: ein Redesign ersetzt einen CC. Jetzt muss angegeben werden,
welcher eigene CC dafuer aufgegeben wird; ein aktiver wird dabei inaktiv
gesetzt, ein bereits inaktiver bleibt unveraendert. Ueber ein CC-Paket kommt
weiterhin ein Platz hinzu, ohne Vorgaenger. Welcher CC aufgegeben wurde, haengt
am Beitritt und bleibt nachvollziehbar.

Faelle, die sich beim Eintragen nicht klaeren lassen - ein Antrag ohne
auffindbares Paket, ein fehlender GExtension-Eintrag, widerspruechliche Angaben
- koennen als Spieler angelegt und dabei als Problem vorgemerkt werden, mit
Notiz. Auch nachtraeglich setzbar und wieder abraeumbar. Die Markierung ist
folgenlos: sie sperrt nichts und veraendert weder Guthaben noch CCs. Die
Uebersicht kennzeichnet betroffene Spieler und laesst sich darauf eingrenzen.

Nebenbei: die Spielerliste gab die Markierung nicht mit aus, aufgefallen beim
Test.

server/prisma/schema.prisma

@@ -123,6 +123,14 @@ model Player {
   createdAt   DateTime @default(now())
   updatedAt   DateTime @updatedAt
 
+  /// Ein Fall, der sich gerade nicht sauber klären lässt: ein Antrag ohne
+  /// auffindbares Paket, ein fehlender GExtension-Eintrag, widersprüchliche
+  /// Angaben. Der Spieler wird trotzdem angelegt, damit die Spur nicht
+  /// verloren geht - geklärt wird, wenn es darauf ankommt.
+  isProblem    Boolean   @default(false)
+  problemNote  String?
+  problemSince DateTime?
+
   /// Von GExtension gemeldeter Verbrauchszähler. Reine Anzeige zum Abgleich,
   /// wird nie automatisch mit dem Ledger verrechnet.
   gextensionUsage    Int?
@@ -137,6 +145,7 @@ model Player {
   memberships  CharacterMember[]
 
   @@index([displayName])
+  @@index([isProblem])
 }
 
 /// Pakete, deren Titel nach CC oder Redesign klingt, sich aber keiner
@@ -223,6 +232,8 @@ model Character {
   ledgerEntries CreditLedger[]
   forumThreads  ForumThread[]
   members       CharacterMember[]
+  /// Beitritte, für die dieser CC aufgegeben wurde.
+  givenUpFor    CharacterMember[] @relation("MemberPredecessor")
 
   createdById Int?
   createdBy   User?    @relation("CharacterCreatedBy", fields: [createdById], references: [id], onDelete: SetNull)
@@ -414,6 +425,12 @@ model CharacterMember {
   paidWith CreditKind?
   note     String?
 
+  /// Der eigene CC, den der Spieler für diesen Platz aufgegeben hat. Nur
+  /// gesetzt, wenn der Beitritt über ein Redesign lief - dann gilt dieselbe
+  /// Regel wie sonst: ein Redesign ersetzt einen CC, es kommt keiner dazu.
+  predecessorId Int?
+  predecessor   Character? @relation("MemberPredecessor", fields: [predecessorId], references: [id], onDelete: SetNull)
+
   createdById Int?
 
   /// Ein Spieler kann demselben CC nicht zweimal angehören.