UserStore kann bis jetzt nur put() (anlegen oder Passwort ersetzen), verify(), exists()
und names() — Umbenennen und Löschen gibt es gar nicht. Ein Administrator sieht außerdem keine
fremden Projekte: Store filtert hart auf owner === $this->owner, ein fremdes Projekt kommt als
404 zurück.
Was gebaut werden soll
Server — Routen unter ?r=users, jede nur für Rolle admin (geprüft serverseitig in Auth, nicht im Client):
GET ?r=users — Liste mit Name, Rolle, Anzahl der Projekte, Anlagedatum. Niemals der Hash.
POST ?r=users{username, password, role} — anlegen.
PATCH ?r=users/{name}{username?, role?, password?} — umbenennen, Rolle setzen, Passwort
zurücksetzen.
DELETE ?r=users/{name} — löschen.
Dafür braucht UserStorerename() und remove(). Zwei Dinge hängen daran und müssen mit
entschieden werden:
Beim Umbenennen wandert der Besitz mit. Der Name steht als owner in jeder Projektdatei;
wird er nicht überall mitgezogen, gehört das Projekt niemandem mehr und ist damit für alle
unsichtbar (so ist Store gebaut, Absicht aus #177).
Beim Löschen eines Kontos ist offen, was mit dessen Projekten passiert (siehe Rückfragen).
Laufende Sessions: Sessions liegen als Datei je Login in data/sessions/ und tragen den
Benutzernamen. Wer gelöscht oder umbenannt wird, muss seine Sessions verlieren — sonst arbeitet
ein Tab weiter, dessen Konto es nicht mehr gibt. SessionStore braucht dafür ein destroyAllFor(username).
Fremde Projekte sehen:Store bekommt einen Weg, für einen Administrator ohne den
Besitzer-Filter zu arbeiten. Das ist die Stelle, an der #177 bewusst dichtgemacht wurde — hier
also mit Bedacht und mit einem Test, der belegt, dass es ohne Rolle admin weiterhin 404 gibt.
Client — ein eigener Tab oder Dialog "Users", erreichbar nur für Administratoren: Liste,
Anlegen, Umbenennen, Passwort zurücksetzen, Löschen (mit Rückfrage). Löschen darf nicht das
eigene Konto treffen, und das letzte verbleibende Administratorkonto darf weder gelöscht noch
degradiert werden, sonst sperrt man sich selbst aus.
Tests
Unit: UserStore (rename/remove, Namenskollision), die Regeln "nicht das eigene Konto",
"nicht den letzten Administrator".
API direkt gemessen: ohne Rolle 403 bzw. 404 auf jede users-Route.
e2e: als Administrator anmelden, Konto anlegen, umbenennen, löschen; als normaler Benutzer ist
der Tab nicht da. Dasselbe Aufräumproblem wie in #178 — der Lauf darf keine Konten hinterlassen.
Rückfragen
Was passiert mit den Projekten eines gelöschten Kontos? Mitlöschen, an den löschenden
Administrator übertragen, oder das Löschen verweigern, solange noch Projekte da sind?
Vorschlag: verweigern und den Administrator erst übertragen oder löschen lassen — dann geht
nichts unbemerkt verloren.
Soll ein Administrator fremde Projekte nur sehen oder auch bearbeiten und löschen dürfen?
Vorschlag: sehen und löschen, aber nicht stillschweigend mitbearbeiten.
Eigenes Konto im selben Dialog? Oder gehört "mein Passwort ändern" allein zu #182?
Vorschlag: #182 bleibt der Weg für einen selbst, hier geht es nur um fremde Konten.
Wie sichtbar soll das sein? Eigener Tab in der Leiste (wie "Plugins"), oder ein Eintrag in
einem Konto-Menü in der Toolbar? Ein Tab kostet dauerhaft Platz und nützt nur einem Konto.
Folge von #177 (User Management). **Braucht #180 (Rollen)** — ohne Rolle gibt es niemanden, der
das darf.
## Stand heute
Es gibt genau einen Weg, Konten zu verwalten, und der führt über die Shell auf dem Server:
```
docker exec -u www-data web-php-fpm php /var/www/html/game-maker/tools/make-user.php <name> <pw>
docker exec -u www-data web-php-fpm php /var/www/html/game-maker/tools/make-user.php --list
```
`UserStore` kann bis jetzt nur `put()` (anlegen oder Passwort ersetzen), `verify()`, `exists()`
und `names()` — Umbenennen und Löschen gibt es gar nicht. Ein Administrator sieht außerdem keine
fremden Projekte: `Store` filtert hart auf `owner === $this->owner`, ein fremdes Projekt kommt als
404 zurück.
## Was gebaut werden soll
**Server** — Routen unter `?r=users`, jede nur für Rolle `admin` (geprüft serverseitig in
`Auth`, nicht im Client):
- `GET ?r=users` — Liste mit Name, Rolle, Anzahl der Projekte, Anlagedatum. Niemals der Hash.
- `POST ?r=users` `{username, password, role}` — anlegen.
- `PATCH ?r=users/{name}` `{username?, role?, password?}` — umbenennen, Rolle setzen, Passwort
zurücksetzen.
- `DELETE ?r=users/{name}` — löschen.
Dafür braucht `UserStore` `rename()` und `remove()`. Zwei Dinge hängen daran und müssen mit
entschieden werden:
- **Beim Umbenennen wandert der Besitz mit.** Der Name steht als `owner` in jeder Projektdatei;
wird er nicht überall mitgezogen, gehört das Projekt niemandem mehr und ist damit für alle
unsichtbar (so ist `Store` gebaut, Absicht aus #177).
- **Beim Löschen eines Kontos** ist offen, was mit dessen Projekten passiert (siehe Rückfragen).
- **Laufende Sessions:** Sessions liegen als Datei je Login in `data/sessions/` und tragen den
Benutzernamen. Wer gelöscht oder umbenannt wird, muss seine Sessions verlieren — sonst arbeitet
ein Tab weiter, dessen Konto es nicht mehr gibt. `SessionStore` braucht dafür ein
`destroyAllFor(username)`.
**Fremde Projekte sehen:** `Store` bekommt einen Weg, für einen Administrator ohne den
Besitzer-Filter zu arbeiten. Das ist die Stelle, an der #177 bewusst dichtgemacht wurde — hier
also mit Bedacht und mit einem Test, der belegt, dass es ohne Rolle `admin` weiterhin 404 gibt.
**Client** — ein eigener Tab oder Dialog "Users", erreichbar nur für Administratoren: Liste,
Anlegen, Umbenennen, Passwort zurücksetzen, Löschen (mit Rückfrage). Löschen darf nicht das
eigene Konto treffen, und das letzte verbleibende Administratorkonto darf weder gelöscht noch
degradiert werden, sonst sperrt man sich selbst aus.
**Tests**
- Unit: `UserStore` (rename/remove, Namenskollision), die Regeln "nicht das eigene Konto",
"nicht den letzten Administrator".
- API direkt gemessen: ohne Rolle 403 bzw. 404 auf jede `users`-Route.
- e2e: als Administrator anmelden, Konto anlegen, umbenennen, löschen; als normaler Benutzer ist
der Tab nicht da. Dasselbe Aufräumproblem wie in #178 — der Lauf darf keine Konten hinterlassen.
## Rückfragen
1. **Was passiert mit den Projekten eines gelöschten Kontos?** Mitlöschen, an den löschenden
Administrator übertragen, oder das Löschen verweigern, solange noch Projekte da sind?
Vorschlag: verweigern und den Administrator erst übertragen oder löschen lassen — dann geht
nichts unbemerkt verloren.
2. **Soll ein Administrator fremde Projekte nur sehen oder auch bearbeiten und löschen dürfen?**
Vorschlag: sehen und löschen, aber nicht stillschweigend mitbearbeiten.
3. **Eigenes Konto im selben Dialog?** Oder gehört "mein Passwort ändern" allein zu #182?
Vorschlag: #182 bleibt der Weg für einen selbst, hier geht es nur um fremde Konten.
4. **Wie sichtbar soll das sein?** Eigener Tab in der Leiste (wie "Plugins"), oder ein Eintrag in
einem Konto-Menü in der Toolbar? Ein Tab kostet dauerhaft Platz und nützt nur einem Konto.
Administrator soll nur sehen (kein Löschen oder Bearbeiten)
Weiß nicht was du meinst, passwort ändern muss möglich sein (ohne altes Passwort eingeben)
Nein, ins Menu obenrechts, nach "Project settings" und "clear saved data" => separator und dort "User Management" => öffnet schließbaren Tab. Dort kann man auch gleich "Plugins" reinpacken, dann muss der Tab nicht die ganze Zeit offen sein im Main View
1. Konto Löschen verweigern wenn Projekte vorhanden
2. Administrator soll nur sehen (kein Löschen oder Bearbeiten)
3. Weiß nicht was du meinst, passwort ändern muss möglich sein (ohne altes Passwort eingeben)
4. Nein, ins Menu obenrechts, nach "Project settings" und "clear saved data" => separator und dort "User Management" => öffnet schließbaren Tab. Dort kann man auch gleich "Plugins" reinpacken, dann muss der Tab nicht die ganze Zeit offen sein im Main View
admin
moved this to Next in Development on 2026-09-23 12:54:27 +02:00
admin
removed the question label 2026-09-23 13:17:01 +02:00
Umgesetzt in ceaa44e, zusammen mit den Rollen aus #180.
Menü und Tab
Im Kontomenü oben rechts kommen nach „Clear saved data“ ein Trennstrich, „User management“ (nur Admins) und „Plugins“ (alle).
Beide öffnen denselben schließbaren Tab: oben die Konten, unten die Plugins. Ein normales Konto sieht dort nur die Plugins, der Tab heißt dann „Plugins“. Den festen Plugins-Tab gibt es nicht mehr.
Pro Konto
Rename…, Role, Password… (ohne altes Passwort) und Delete mit Rückfrage, dazu „New user…“.
Unter jedem Konto stehen seine Projekte mit Open. Ein Admin bearbeitet sie wie der Besitzer, gespeichert wird mit dem ursprünglichen Besitzer.
Löschen wird verweigert, solange das Konto Projekte hat (409, zum Beispiel „e2e-tmp2 still owns 1 project“).
Beim Umbenennen wandern die Projekte mit, und alle Sitzungen des Kontos werden beendet.
Eigene Entscheidungen
Auf der eigenen Zeile darf ein Admin nur das Passwort setzen. Umbenennen würde die eigene Sitzung beenden, Selbst-Herabstufen oder Selbst-Löschen würde aussperren.
Der letzte Admin kann nicht herabgestuft oder gelöscht werden.
Beides prüft der Server, nicht nur der Editor (api/lib/AccountRules.php).
Offen: Der Server erlaubt einem Admin, fremde Projekte zu löschen. Im Editor gibt es dafür keinen Knopf, „Open project…“ listet weiter nur die eigenen Projekte. Falls ein Delete pro Projekt in der Kontenliste gewünscht ist, wäre das ein eigenes Issue.
Befund unterwegs: Bei 1280 px Breite ragte „Delete“ über den Spaltenrand und war nicht klickbar. Die Namensspalte ist jetzt flexibel, und Modul 49 hat dafür einen Layout-Check.
Neues e2e-Modul 49 (18 Checks): e2e bekommt 403 und sieht keine Verwaltung. Dazu Anlegen samt abgelehntem kurzem Passwort und vergebenem Namen, Umbenennen samt Projekt und toter alter Sitzung, Rolle, verweigertes Löschen, fremdes Projekt öffnen und speichern, Löschen.
Angepasst: Module 14, 38, 46 und das Scaffold.
Gegenproben greifen: Selbst-Löschen erlaubt → 1 PHP-Check fällt. Spalte 200 px breiter → der Layout-Check fällt. save mit dem Aufrufer als Besitzer → nur der Besitzer-Check fällt (owner: e2e-admin).
Check-Summe 1314 → 1333 (+1 in 38, +18 in 49), gerechnet. CI habe ich nicht abgewartet.
Doku: Wiki Accounts, API, Concepts, Plugins, Architecture, Development (Wiki-Commit 3af598d).
Umgesetzt in ceaa44e, zusammen mit den Rollen aus #180.
**Menü und Tab**
- Im Kontomenü oben rechts kommen nach „Clear saved data“ ein Trennstrich, „User management“ (nur Admins) und „Plugins“ (alle).
- Beide öffnen denselben schließbaren Tab: oben die Konten, unten die Plugins. Ein normales Konto sieht dort nur die Plugins, der Tab heißt dann „Plugins“. Den festen Plugins-Tab gibt es nicht mehr.
**Pro Konto**
- Rename…, Role, Password… (ohne altes Passwort) und Delete mit Rückfrage, dazu „New user…“.
- Unter jedem Konto stehen seine Projekte mit **Open**. Ein Admin bearbeitet sie wie der Besitzer, gespeichert wird mit dem ursprünglichen Besitzer.
- Löschen wird verweigert, solange das Konto Projekte hat (409, zum Beispiel „e2e-tmp2 still owns 1 project“).
- Beim Umbenennen wandern die Projekte mit, und alle Sitzungen des Kontos werden beendet.
**Eigene Entscheidungen**
- Auf der eigenen Zeile darf ein Admin nur das Passwort setzen. Umbenennen würde die eigene Sitzung beenden, Selbst-Herabstufen oder Selbst-Löschen würde aussperren.
- Der letzte Admin kann nicht herabgestuft oder gelöscht werden.
- Beides prüft der Server, nicht nur der Editor (`api/lib/AccountRules.php`).
**Offen:** Der Server erlaubt einem Admin, fremde Projekte zu löschen. Im Editor gibt es dafür keinen Knopf, „Open project…“ listet weiter nur die eigenen Projekte. Falls ein Delete pro Projekt in der Kontenliste gewünscht ist, wäre das ein eigenes Issue.
**Befund unterwegs:** Bei 1280 px Breite ragte „Delete“ über den Spaltenrand und war nicht klickbar. Die Namensspalte ist jetzt flexibel, und Modul 49 hat dafür einen Layout-Check.
**Tests**
```
./check.sh → 148 Files, 2214 Tests, CHECK EXIT 0 (vorher 147 / 2204)
tests/php/accounts.test.php (Container) → ALL PASSED – 51 checks
e2e 1-16,37,38,45,46,49 → ALL PASSED – 581 checks
```
- Neues e2e-Modul **49** (18 Checks): `e2e` bekommt 403 und sieht keine Verwaltung. Dazu Anlegen samt abgelehntem kurzem Passwort und vergebenem Namen, Umbenennen samt Projekt und toter alter Sitzung, Rolle, verweigertes Löschen, fremdes Projekt öffnen und speichern, Löschen.
- Angepasst: Module 14, 38, 46 und das Scaffold.
- Gegenproben greifen: Selbst-Löschen erlaubt → 1 PHP-Check fällt. Spalte 200 px breiter → der Layout-Check fällt. `save` mit dem Aufrufer als Besitzer → nur der Besitzer-Check fällt (`owner: e2e-admin`).
- Check-Summe 1314 → **1333** (+1 in 38, +18 in 49), gerechnet. CI habe ich nicht abgewartet.
Doku: Wiki *Accounts*, *API*, *Concepts*, *Plugins*, *Architecture*, *Development* (Wiki-Commit 3af598d).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Folge von #177 (User Management). Braucht #180 (Rollen) — ohne Rolle gibt es niemanden, der
das darf.
Stand heute
Es gibt genau einen Weg, Konten zu verwalten, und der führt über die Shell auf dem Server:
UserStorekann bis jetzt nurput()(anlegen oder Passwort ersetzen),verify(),exists()und
names()— Umbenennen und Löschen gibt es gar nicht. Ein Administrator sieht außerdem keinefremden Projekte:
Storefiltert hart aufowner === $this->owner, ein fremdes Projekt kommt als404 zurück.
Was gebaut werden soll
Server — Routen unter
?r=users, jede nur für Rolleadmin(geprüft serverseitig inAuth, nicht im Client):GET ?r=users— Liste mit Name, Rolle, Anzahl der Projekte, Anlagedatum. Niemals der Hash.POST ?r=users{username, password, role}— anlegen.PATCH ?r=users/{name}{username?, role?, password?}— umbenennen, Rolle setzen, Passwortzurücksetzen.
DELETE ?r=users/{name}— löschen.Dafür braucht
UserStorerename()undremove(). Zwei Dinge hängen daran und müssen mitentschieden werden:
ownerin jeder Projektdatei;wird er nicht überall mitgezogen, gehört das Projekt niemandem mehr und ist damit für alle
unsichtbar (so ist
Storegebaut, Absicht aus #177).data/sessions/und tragen denBenutzernamen. Wer gelöscht oder umbenannt wird, muss seine Sessions verlieren — sonst arbeitet
ein Tab weiter, dessen Konto es nicht mehr gibt.
SessionStorebraucht dafür eindestroyAllFor(username).Fremde Projekte sehen:
Storebekommt einen Weg, für einen Administrator ohne denBesitzer-Filter zu arbeiten. Das ist die Stelle, an der #177 bewusst dichtgemacht wurde — hier
also mit Bedacht und mit einem Test, der belegt, dass es ohne Rolle
adminweiterhin 404 gibt.Client — ein eigener Tab oder Dialog "Users", erreichbar nur für Administratoren: Liste,
Anlegen, Umbenennen, Passwort zurücksetzen, Löschen (mit Rückfrage). Löschen darf nicht das
eigene Konto treffen, und das letzte verbleibende Administratorkonto darf weder gelöscht noch
degradiert werden, sonst sperrt man sich selbst aus.
Tests
UserStore(rename/remove, Namenskollision), die Regeln "nicht das eigene Konto","nicht den letzten Administrator".
users-Route.der Tab nicht da. Dasselbe Aufräumproblem wie in #178 — der Lauf darf keine Konten hinterlassen.
Rückfragen
Administrator übertragen, oder das Löschen verweigern, solange noch Projekte da sind?
Vorschlag: verweigern und den Administrator erst übertragen oder löschen lassen — dann geht
nichts unbemerkt verloren.
Vorschlag: sehen und löschen, aber nicht stillschweigend mitbearbeiten.
Vorschlag: #182 bleibt der Weg für einen selbst, hier geht es nur um fremde Konten.
einem Konto-Menü in der Toolbar? Ein Tab kostet dauerhaft Platz und nützt nur einem Konto.
Umgesetzt in
ceaa44e, zusammen mit den Rollen aus #180.Menü und Tab
Pro Konto
Eigene Entscheidungen
api/lib/AccountRules.php).Offen: Der Server erlaubt einem Admin, fremde Projekte zu löschen. Im Editor gibt es dafür keinen Knopf, „Open project…“ listet weiter nur die eigenen Projekte. Falls ein Delete pro Projekt in der Kontenliste gewünscht ist, wäre das ein eigenes Issue.
Befund unterwegs: Bei 1280 px Breite ragte „Delete“ über den Spaltenrand und war nicht klickbar. Die Namensspalte ist jetzt flexibel, und Modul 49 hat dafür einen Layout-Check.
Tests
e2ebekommt 403 und sieht keine Verwaltung. Dazu Anlegen samt abgelehntem kurzem Passwort und vergebenem Namen, Umbenennen samt Projekt und toter alter Sitzung, Rolle, verweigertes Löschen, fremdes Projekt öffnen und speichern, Löschen.savemit dem Aufrufer als Besitzer → nur der Besitzer-Check fällt (owner: e2e-admin).Doku: Wiki Accounts, API, Concepts, Plugins, Architecture, Development (Wiki-Commit 3af598d).