Aus #179 und #180. Rückfrage 2 in #179 war: „Soll ein Administrator fremde Projekte nur sehen oder auch bearbeiten und löschen dürfen?“ Deine Antwort: „Administrator soll nur sehen (kein Löschen oder Bearbeiten)“. Kurz danach kam in #180 Antwort 4: „admin darf fremde projekte öffnen, ganz normal wie ein user projekt (voll bearbeitbar, keine extra sache bauen)“.
Der Abschluss von #179 hält fest: „Der Server erlaubt einem Admin, fremde Projekte zu löschen. Im Editor gibt es dafür keinen Knopf … Falls ein Delete pro Projekt in der Kontenliste gewünscht ist, wäre das ein eigenes Issue.“ Darauf gab es keine Antwort.
Befund
Store mit seesAll (api/lib/Store.php:23) behandelt für einen Admin jedes Projekt wie ein eigenes. delete() (Zeile 124) läuft über dieselbe Sichtprüfung wie das Laden (Zeile 184).
DELETE ?r=projects/{id} (api/index.php:232) löscht damit auch ein fremdes Projekt, samt Snapshots und Release.
Im Editor gibt es dafür keinen Weg. Löschen bietet nur der Projekt-Picker an (src/editor/ProjectSession.ts:155), und der listet die eigenen Projekte. In der Kontenliste hat jedes Projekt nur Open.
Das Bearbeiten ist mit #180 geklärt. Beim Löschen widersprechen sich die Antwort in #179 und der Server.
Zu klären
A) Löschen bleibt dem Besitzer vorbehalten. Der Server antwortet einem Admin bei DELETE auf ein fremdes Projekt mit 403. Öffnen, Bearbeiten, Snapshots und Release bleiben, wie sie sind.
B) Ein Admin darf löschen, wie „ganz normal wie ein user projekt“ nahelegt. Dann fehlt nur der Knopf: Delete pro Projekt in der Kontenliste, mit Rückfrage.
Vorschlag: A, weil es deiner ausdrücklichen Antwort in #179 entspricht und so nichts unbemerkt verloren geht.
Tests
A: PHP-Checks in tests/php/accounts.test.php (Admin löscht fremdes Projekt → 403, eigenes → 204), Gegenprobe.
B: e2e in Modul 49 mit echtem Klick auf Delete und der Rückfrage.
Aus #179 und #180. Rückfrage 2 in #179 war: „Soll ein Administrator fremde Projekte nur sehen oder auch bearbeiten und löschen dürfen?“ Deine Antwort: „Administrator soll nur sehen (kein Löschen oder Bearbeiten)“. Kurz danach kam in #180 Antwort 4: „admin darf fremde projekte öffnen, ganz normal wie ein user projekt (voll bearbeitbar, keine extra sache bauen)“.
Der Abschluss von #179 hält fest: „Der Server erlaubt einem Admin, fremde Projekte zu löschen. Im Editor gibt es dafür keinen Knopf … Falls ein Delete pro Projekt in der Kontenliste gewünscht ist, wäre das ein eigenes Issue.“ Darauf gab es keine Antwort.
## Befund
- `Store` mit `seesAll` (`api/lib/Store.php:23`) behandelt für einen Admin jedes Projekt wie ein eigenes. `delete()` (Zeile 124) läuft über dieselbe Sichtprüfung wie das Laden (Zeile 184).
- `DELETE ?r=projects/{id}` (`api/index.php:232`) löscht damit auch ein fremdes Projekt, samt Snapshots und Release.
- Im Editor gibt es dafür keinen Weg. Löschen bietet nur der Projekt-Picker an (`src/editor/ProjectSession.ts:155`), und der listet die eigenen Projekte. In der Kontenliste hat jedes Projekt nur **Open**.
- Das Bearbeiten ist mit #180 geklärt. Beim Löschen widersprechen sich die Antwort in #179 und der Server.
## Zu klären
- **A)** Löschen bleibt dem Besitzer vorbehalten. Der Server antwortet einem Admin bei `DELETE` auf ein fremdes Projekt mit 403. Öffnen, Bearbeiten, Snapshots und Release bleiben, wie sie sind.
- **B)** Ein Admin darf löschen, wie „ganz normal wie ein user projekt“ nahelegt. Dann fehlt nur der Knopf: Delete pro Projekt in der Kontenliste, mit Rückfrage.
- Vorschlag: **A**, weil es deiner ausdrücklichen Antwort in #179 entspricht und so nichts unbemerkt verloren geht.
## Tests
- A: PHP-Checks in `tests/php/accounts.test.php` (Admin löscht fremdes Projekt → 403, eigenes → 204), Gegenprobe.
- B: e2e in Modul 49 mit echtem Klick auf Delete und der Rückfrage.
Done in cbda6d6, wiki 442ad12 (API, Accounts, Architecture, Development). Built as decided above: option A, only the owner deletes a project.
What changes
DELETE ?r=projects/{id} answers an administrator 403{"error":"Only its owner may delete a project"} for somebody else's project. That includes a project file without an owner.
Opening, editing, snapshots and release stay open to the administrator as before. For a non-admin a foreign project is still 404.
The editor never had a way to delete a foreign project, the project picker lists only one's own. Nothing changes there.
Consequence: an account that owns projects can no longer be deleted by an administrator by any route. The account has to delete its projects first. The Delete row in the wiki page Accounts says so.
Under the hood
Store::delete checks the owner under the save lock and throws NotOwnerException, on the pattern of StaleRevisionException.
The route in api/index.php turns that into the 403.
e2e 49 deleted the throwaway projects as administrator, in its sweep and in 49i. It now signs in as the owner for that. The sweep only has work when an earlier run broke off halfway, so its owner path is not exercised in a normal run.
Tests
php accounts.test.php ALL PASSED - 56 checks (was 52: 1 turned around, 5 new)
e2e 49 (melektaus-atx) ALL PASSED - 22 checks (was 21), {"deleteByAdmin":403,"deleteByOwner":204}
gate (melektaus-atx) 197 files, 2855 tests, CHECK EXIT 0
live probe (localhost) admin 403, then GET 200 (project still there), owner 204, then 404
Counter-checks work: without the owner check 4 PHP checks fail, and 49i fails with {"deleteByAdmin":204,"deleteByOwner":404}.
The live probe used only the test accounts e2e and e2e-admin and a throwaway project, which is deleted again.
The e2e total of 1603 is counted (1602 + 1). The CI run for cbda6d6 was not waited for.
Done in `cbda6d6`, wiki `442ad12` (*API*, *Accounts*, *Architecture*, *Development*). Built as decided above: option A, only the owner deletes a project.
**What changes**
- `DELETE ?r=projects/{id}` answers an administrator **403** `{"error":"Only its owner may delete a project"}` for somebody else's project. That includes a project file without an owner.
- Opening, editing, snapshots and release stay open to the administrator as before. For a non-admin a foreign project is still **404**.
- The editor never had a way to delete a foreign project, the project picker lists only one's own. Nothing changes there.
- **Consequence:** an account that owns projects can no longer be deleted by an administrator by any route. The account has to delete its projects first. The *Delete* row in the wiki page *Accounts* says so.
**Under the hood**
- `Store::delete` checks the owner under the save lock and throws `NotOwnerException`, on the pattern of `StaleRevisionException`.
- The route in `api/index.php` turns that into the 403.
- e2e 49 deleted the throwaway projects as administrator, in its sweep and in 49i. It now signs in as the owner for that. The sweep only has work when an earlier run broke off halfway, so its owner path is not exercised in a normal run.
**Tests**
```
php accounts.test.php ALL PASSED - 56 checks (was 52: 1 turned around, 5 new)
e2e 49 (melektaus-atx) ALL PASSED - 22 checks (was 21), {"deleteByAdmin":403,"deleteByOwner":204}
gate (melektaus-atx) 197 files, 2855 tests, CHECK EXIT 0
live probe (localhost) admin 403, then GET 200 (project still there), owner 204, then 404
```
- Counter-checks work: without the owner check 4 PHP checks fail, and 49i fails with `{"deleteByAdmin":204,"deleteByOwner":404}`.
- The live probe used only the test accounts `e2e` and `e2e-admin` and a throwaway project, which is deleted again.
- The e2e total of 1603 is counted (1602 + 1). The CI run for `cbda6d6` was not waited for.
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.
Aus #179 und #180. Rückfrage 2 in #179 war: „Soll ein Administrator fremde Projekte nur sehen oder auch bearbeiten und löschen dürfen?“ Deine Antwort: „Administrator soll nur sehen (kein Löschen oder Bearbeiten)“. Kurz danach kam in #180 Antwort 4: „admin darf fremde projekte öffnen, ganz normal wie ein user projekt (voll bearbeitbar, keine extra sache bauen)“.
Der Abschluss von #179 hält fest: „Der Server erlaubt einem Admin, fremde Projekte zu löschen. Im Editor gibt es dafür keinen Knopf … Falls ein Delete pro Projekt in der Kontenliste gewünscht ist, wäre das ein eigenes Issue.“ Darauf gab es keine Antwort.
Befund
StoremitseesAll(api/lib/Store.php:23) behandelt für einen Admin jedes Projekt wie ein eigenes.delete()(Zeile 124) läuft über dieselbe Sichtprüfung wie das Laden (Zeile 184).DELETE ?r=projects/{id}(api/index.php:232) löscht damit auch ein fremdes Projekt, samt Snapshots und Release.src/editor/ProjectSession.ts:155), und der listet die eigenen Projekte. In der Kontenliste hat jedes Projekt nur Open.Zu klären
DELETEauf ein fremdes Projekt mit 403. Öffnen, Bearbeiten, Snapshots und Release bleiben, wie sie sind.Tests
tests/php/accounts.test.php(Admin löscht fremdes Projekt → 403, eigenes → 204), Gegenprobe.Vorschlag: A - löschen darf nur der Besitzer
Done in
cbda6d6, wiki442ad12(API, Accounts, Architecture, Development). Built as decided above: option A, only the owner deletes a project.What changes
DELETE ?r=projects/{id}answers an administrator 403{"error":"Only its owner may delete a project"}for somebody else's project. That includes a project file without an owner.Under the hood
Store::deletechecks the owner under the save lock and throwsNotOwnerException, on the pattern ofStaleRevisionException.api/index.phpturns that into the 403.Tests
{"deleteByAdmin":204,"deleteByOwner":404}.e2eande2e-adminand a throwaway project, which is deleted again.cbda6d6was not waited for.