Ein Projekt gehört genau einem Konto: Feld owner in data/projects/<id>.json. Store filtert
hart danach — GET ?r=projects zeigt nur die eigenen, und ein fremdes Projekt kommt als 404
zurück, nicht als 403 (Absicht aus #177: wer es nicht hat, soll nicht einmal erfahren, dass es
existiert). Eine Datei ohne owner gehört niemandem und ist für alle unsichtbar.
Gemeinsam sind dagegen schon heute Bilder, Fonts, Sounds und Plugins — die liegen außerhalb
der Projektdateien und werden nicht nach Besitzer getrennt. Wer ein geteiltes Projekt öffnet,
sieht dessen Texturen also ohnehin.
Was gebaut werden soll
Modell — neben owner eine Freigabeliste in der Projektdatei, etwa shared: [{user, access: 'read' | 'write'}]. Der Besitzer bleibt der Besitzer; nur er darf
freigeben, die Freigabe zurücknehmen und das Projekt löschen.
Server
Store liefert ein Projekt aus, wenn der Anfragende Besitzer oder in der Liste steht;
ohne write ist PUT ?r=projects/{id} abzulehnen. Wichtig: das Autosave des Editors schreibt
laufend — bei reinem Lesezugriff muss der Client das gar nicht erst versuchen, sonst läuft eine
Fehlermeldung im Sekundentakt.
GET ?r=projects nimmt die geteilten mit auf und sagt pro Eintrag, wem es gehört und was man
darf.
Routen zum Freigeben und Zurücknehmen, z. B. GET/PUT ?r=projects/{id}/sharing.
Client
Im Projektmenü der Toolbar (src/editor/ProjectSession.ts) steht beim Eintrag, wem das Projekt
gehört — eigene und fremde in einer Liste, fremde erkennbar am Besitzer.
Ein Dialog "Freigeben" mit der Liste der Konten und dem Recht je Konto. Dafür braucht der
Client eine Liste der Kontonamen; die gibt es heute nur für Administratoren (#179). Also
entweder eine schmale Route, die nur Namen liefert, oder Freigabe per Eintippen des Namens.
Ist ein Projekt nur lesbar, muss das sichtbar sein und das Autosave ausgeschaltet bleiben.
Tests
Unit: die reine Regel "wer darf was mit diesem Dokument" als eigene Funktion, ohne Server.
API direkt gemessen: fremdes Projekt ohne Freigabe 404, mit read lesbar und nicht schreibbar,
mit write beides; nach dem Zurücknehmen wieder 404.
e2e: der Lauf müsste sich als zwei verschiedene Konten anmelden. Das kann Modul 45 heute nicht
— dort kommt die Session per Cookie aus tools/lib/auth.mjs, das genau ein Konto kennt. Der
Harness braucht dafür einen zweiten Login, das ist eigener Bau.
Rückfragen
Reichen read und write, oder soll es nur "geteilt = darf alles außer löschen" geben?
Zwei Stufen sind ehrlicher, kosten aber die ganze Nur-Lese-Behandlung im Editor (Autosave,
ausgegraute Knöpfe). Vorschlag: mit zwei Stufen bauen.
Wie wird ein Konto ausgewählt? Namen eintippen (kein neues Recht nötig) oder eine Liste
aller Konten anbieten (jeder sieht dann, wer existiert). Vorschlag: eintippen, solange es
keine Benutzerverwaltung gibt.
Gleichzeitiges Arbeiten: Zwei Leute mit write im selben Projekt kollidieren über die
Revision (PUT antwortet 409). Reicht es, wenn der Zweite eine klare Meldung und den Weg
"neu laden" bekommt, oder erwartest du mehr?
Soll ein Projekt auch ganz übergeben werden können (Besitzer wechseln)? Das wäre ein
kleiner Zusatz an derselben Stelle und würde in #179 beim Löschen eines Kontos helfen.
Folge von #177 (User Management).
## Stand heute
Ein Projekt gehört genau einem Konto: Feld `owner` in `data/projects/<id>.json`. `Store` filtert
hart danach — `GET ?r=projects` zeigt nur die eigenen, und ein fremdes Projekt kommt als **404**
zurück, nicht als 403 (Absicht aus #177: wer es nicht hat, soll nicht einmal erfahren, dass es
existiert). Eine Datei ohne `owner` gehört niemandem und ist für alle unsichtbar.
Gemeinsam sind dagegen schon heute **Bilder, Fonts, Sounds und Plugins** — die liegen außerhalb
der Projektdateien und werden nicht nach Besitzer getrennt. Wer ein geteiltes Projekt öffnet,
sieht dessen Texturen also ohnehin.
## Was gebaut werden soll
**Modell** — neben `owner` eine Freigabeliste in der Projektdatei, etwa
`shared: [{user, access: 'read' | 'write'}]`. Der Besitzer bleibt der Besitzer; nur er darf
freigeben, die Freigabe zurücknehmen und das Projekt löschen.
**Server**
- `Store` liefert ein Projekt aus, wenn der Anfragende Besitzer **oder** in der Liste steht;
ohne `write` ist `PUT ?r=projects/{id}` abzulehnen. Wichtig: das Autosave des Editors schreibt
laufend — bei reinem Lesezugriff muss der Client das gar nicht erst versuchen, sonst läuft eine
Fehlermeldung im Sekundentakt.
- `GET ?r=projects` nimmt die geteilten mit auf und sagt pro Eintrag, wem es gehört und was man
darf.
- Routen zum Freigeben und Zurücknehmen, z. B. `GET/PUT ?r=projects/{id}/sharing`.
**Client**
- Im Projektmenü der Toolbar (`src/editor/ProjectSession.ts`) steht beim Eintrag, wem das Projekt
gehört — eigene und fremde in einer Liste, fremde erkennbar am Besitzer.
- Ein Dialog "Freigeben" mit der Liste der Konten und dem Recht je Konto. Dafür braucht der
Client eine Liste der Kontonamen; die gibt es heute nur für Administratoren (#179). Also
entweder eine schmale Route, die nur Namen liefert, oder Freigabe per Eintippen des Namens.
- Ist ein Projekt nur lesbar, muss das sichtbar sein und das Autosave ausgeschaltet bleiben.
**Tests**
- Unit: die reine Regel "wer darf was mit diesem Dokument" als eigene Funktion, ohne Server.
- API direkt gemessen: fremdes Projekt ohne Freigabe 404, mit `read` lesbar und nicht schreibbar,
mit `write` beides; nach dem Zurücknehmen wieder 404.
- e2e: der Lauf müsste sich als zwei verschiedene Konten anmelden. Das kann Modul 45 heute nicht
— dort kommt die Session per Cookie aus `tools/lib/auth.mjs`, das genau ein Konto kennt. Der
Harness braucht dafür einen zweiten Login, das ist eigener Bau.
## Rückfragen
1. **Reichen `read` und `write`,** oder soll es nur "geteilt = darf alles außer löschen" geben?
Zwei Stufen sind ehrlicher, kosten aber die ganze Nur-Lese-Behandlung im Editor (Autosave,
ausgegraute Knöpfe). Vorschlag: mit zwei Stufen bauen.
2. **Wie wird ein Konto ausgewählt?** Namen eintippen (kein neues Recht nötig) oder eine Liste
aller Konten anbieten (jeder sieht dann, wer existiert). Vorschlag: eintippen, solange es
keine Benutzerverwaltung gibt.
3. **Gleichzeitiges Arbeiten:** Zwei Leute mit `write` im selben Projekt kollidieren über die
Revision (`PUT` antwortet 409). Reicht es, wenn der Zweite eine klare Meldung und den Weg
"neu laden" bekommt, oder erwartest du mehr?
4. **Soll ein Projekt auch ganz übergeben werden können** (Besitzer wechseln)? Das wäre ein
kleiner Zusatz an derselben Stelle und würde in #179 beim Löschen eines Kontos helfen.
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).
Stand heute
Ein Projekt gehört genau einem Konto: Feld
ownerindata/projects/<id>.json.Storefilterthart danach —
GET ?r=projectszeigt nur die eigenen, und ein fremdes Projekt kommt als 404zurück, nicht als 403 (Absicht aus #177: wer es nicht hat, soll nicht einmal erfahren, dass es
existiert). Eine Datei ohne
ownergehört niemandem und ist für alle unsichtbar.Gemeinsam sind dagegen schon heute Bilder, Fonts, Sounds und Plugins — die liegen außerhalb
der Projektdateien und werden nicht nach Besitzer getrennt. Wer ein geteiltes Projekt öffnet,
sieht dessen Texturen also ohnehin.
Was gebaut werden soll
Modell — neben
ownereine Freigabeliste in der Projektdatei, etwashared: [{user, access: 'read' | 'write'}]. Der Besitzer bleibt der Besitzer; nur er darffreigeben, die Freigabe zurücknehmen und das Projekt löschen.
Server
Storeliefert ein Projekt aus, wenn der Anfragende Besitzer oder in der Liste steht;ohne
writeistPUT ?r=projects/{id}abzulehnen. Wichtig: das Autosave des Editors schreibtlaufend — bei reinem Lesezugriff muss der Client das gar nicht erst versuchen, sonst läuft eine
Fehlermeldung im Sekundentakt.
GET ?r=projectsnimmt die geteilten mit auf und sagt pro Eintrag, wem es gehört und was mandarf.
GET/PUT ?r=projects/{id}/sharing.Client
src/editor/ProjectSession.ts) steht beim Eintrag, wem das Projektgehört — eigene und fremde in einer Liste, fremde erkennbar am Besitzer.
Client eine Liste der Kontonamen; die gibt es heute nur für Administratoren (#179). Also
entweder eine schmale Route, die nur Namen liefert, oder Freigabe per Eintippen des Namens.
Tests
readlesbar und nicht schreibbar,mit
writebeides; nach dem Zurücknehmen wieder 404.— dort kommt die Session per Cookie aus
tools/lib/auth.mjs, das genau ein Konto kennt. DerHarness braucht dafür einen zweiten Login, das ist eigener Bau.
Rückfragen
readundwrite, oder soll es nur "geteilt = darf alles außer löschen" geben?Zwei Stufen sind ehrlicher, kosten aber die ganze Nur-Lese-Behandlung im Editor (Autosave,
ausgegraute Knöpfe). Vorschlag: mit zwei Stufen bauen.
aller Konten anbieten (jeder sieht dann, wer existiert). Vorschlag: eintippen, solange es
keine Benutzerverwaltung gibt.
writeim selben Projekt kollidieren über dieRevision (
PUTantwortet 409). Reicht es, wenn der Zweite eine klare Meldung und den Weg"neu laden" bekommt, oder erwartest du mehr?
kleiner Zusatz an derselben Stelle und würde in #179 beim Löschen eines Kontos helfen.