Git Token - welche Rechte #10

New Issue

2026-08-18T09:53:19Z

florian.wilde commented

2026-08-18 09:53:19 +00:00

Welche Rechte braucht eine Git Verbindung um alle Funktionen hier in Nebula zu verwenden aber nicht zu viel damit es sicher bleibt.

Angelegt aus Nebula in Nebula.

Welche Rechte braucht eine Git Verbindung um alle Funktionen hier in Nebula zu verwenden aber nicht zu viel damit es sicher bleibt. _Angelegt aus [Nebula](https://nebula.wilde-ste.de/projects/cms2wvhe9000opb01h8c8ajxn) in Nebula._

florian.wilde added the in-arbeit label 2026-08-18 09:56:43 +00:00

florian.wilde started working 2026-08-18 09:56:53 +00:00

florian.wilde commented

2026-08-18 09:58:26 +00:00

🤖 Claude Code hat mit der Umsetzung begonnen.

Branch: feat/10-token-rechte
Verstanden als: Die dokumentierten Token-Rechte stammen aus der Zeit, als Nebula nur gelesen hat. Seit v1.7.0 legt es auch Issues an und schließt sie — die Angaben in README und im Verbindungsdialog reichen dafür nicht mehr. Gesucht ist das kleinstmögliche Rechtebündel je System, nicht das bequemste.
Geplantes Vorgehen:
- Jeden ausgehenden Aufruf je Provider aus lib/git/*.ts erheben und auf das nötige Recht abbilden — aus dem Code, nicht aus dem Gedächtnis
- Nach Funktion aufschlüsseln, damit erkennbar ist, was man weglassen kann: Abgleich allein braucht deutlich weniger als die Issue-Anbindung
- tokenHelp in lib/git/meta.ts nachziehen — der Hinweis steht direkt am Eingabefeld und ist die Stelle, die tatsächlich gelesen wird
- README-Tabelle ersetzen, FEATURES entsprechend ergänzen

Was ich schon sagen kann und was vermutlich unangenehm ist: bei GitLab gibt es keinen schmalen Schreib-Scope für Issues. Wer die Issue-Anbindung dort nutzen will, braucht api — also alles. Wer beim reinen Abgleich bleibt, kommt mit read_api aus. Das werde ich als bewusste Entscheidung darstellen, nicht als Empfehlung, einfach api zu setzen.

Bei GitHub und Gitea lässt sich das dagegen sauber trennen.

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `feat/10-token-rechte` - Verstanden als: Die dokumentierten Token-Rechte stammen aus der Zeit, als Nebula nur *gelesen* hat. Seit v1.7.0 legt es auch Issues an und schließt sie — die Angaben in README und im Verbindungsdialog reichen dafür nicht mehr. Gesucht ist das **kleinstmögliche** Rechtebündel je System, nicht das bequemste. - Geplantes Vorgehen: - Jeden ausgehenden Aufruf je Provider aus `lib/git/*.ts` erheben und auf das nötige Recht abbilden — aus dem Code, nicht aus dem Gedächtnis - Nach **Funktion** aufschlüsseln, damit erkennbar ist, was man weglassen kann: Abgleich allein braucht deutlich weniger als die Issue-Anbindung - `tokenHelp` in `lib/git/meta.ts` nachziehen — der Hinweis steht direkt am Eingabefeld und ist die Stelle, die tatsächlich gelesen wird - README-Tabelle ersetzen, FEATURES entsprechend ergänzen **Was ich schon sagen kann und was vermutlich unangenehm ist:** bei GitLab gibt es *keinen* schmalen Schreib-Scope für Issues. Wer die Issue-Anbindung dort nutzen will, braucht `api` — also alles. Wer beim reinen Abgleich bleibt, kommt mit `read_api` aus. Das werde ich als bewusste Entscheidung darstellen, nicht als Empfehlung, einfach `api` zu setzen. Bei GitHub und Gitea lässt sich das dagegen sauber trennen. Zeiterfassung läuft.

florian.wilde worked for 13 minutes

2026-08-18 10:10:23 +00:00

florian.wilde referenced this issue from a commit

2026-08-18 10:10:59 +00:00

Token-Rechte vollstaendig dokumentiert

florian.wilde referenced a pull request that will close this issue

2026-08-18 10:11:17 +00:00

Feat #10: Token-Rechte vollständig dokumentiert #11

florian.wilde added zu-testen and removed in-arbeit labels 2026-08-18 10:11:24 +00:00

florian.wilde commented

2026-08-18 10:11:42 +00:00

✅ Umsetzung abgeschlossen — bereit zum Testen.

Die Antwort auf die Frage — jeder ausgehende Aufruf aus lib/git/*.ts erhoben und auf das nötige Recht abgebildet:

System	Nur Abgleich	Zusätzlich für die Issue-Anbindung
GitHub	Metadata, Contents, Issues, Pull requests, Actions — je lesend	Issues: Read and write
GitLab	`read_api`	`api`
Gitea / Forgejo	`read:repository`, `read:issue`, `read:user`	`write:issue`

GitLab ist der unangenehme Fall: kein schmaler Schreib-Scope für Issues. Entweder api (alles, was das Konto darf) oder auf die Issue-Anbindung verzichten. Bei read_api läuft der Abgleich vollständig, und geschlossene Issues werden weiterhin erkannt — nur nicht zurückgeschrieben.

Nicht verlangt: Schreibrechte auf Code, Adminrechte, Rechte zum Anlegen von Webhooks.

Was geändert wurde

README: neuer Abschnitt „Welche Rechte der Token braucht“, nach Funktion aufgeschlüsselt statt nach System, mit einer Tabelle, wozu jedes einzelne Recht gut ist
FEATURES 4.2: dieselbe Auskunft im Zusammenhang der Verbindungsverwaltung
lib/git/meta.ts: der Hinweis direkt unter dem Token-Feld war ebenfalls rein lesend formuliert — mitgezogen
meta.test.ts als Wächter: jeder Provider muss createIssue/setIssueState können, also muss auch jeder Hinweis die Rechte dafür nennen

Geänderte Dateien

README.md · FEATURES.md
src/lib/git/meta.ts
src/lib/git/meta.test.ts (neu)

So testest du es

git switch feat/10-token-rechte
npm run docker:db und npm run dev
Git-Verbindungen → Verbindung hinzufügen, oben zwischen GitHub, GitLab und Gitea umschalten
Erwartet: der Hinweis unter Access Token ändert sich je System und nennt jeweils, was zusätzlich nötig ist, wenn Aufgaben als Issue angelegt werden sollen
In der README den Abschnitt „Welche Rechte der Token braucht“ gegenlesen

Aufgewendete Zeit: 00:14
Pull Request: #11

Nach Freigabe: /issue-freigabe 10

✅ **Umsetzung abgeschlossen — bereit zum Testen.**  **Die Antwort auf die Frage** — jeder ausgehende Aufruf aus `lib/git/*.ts` erhoben und auf das nötige Recht abgebildet: | System | Nur Abgleich | Zusätzlich für die Issue-Anbindung | | --- | --- | --- | | GitHub | *Metadata*, *Contents*, *Issues*, *Pull requests*, *Actions* — je lesend | *Issues: Read and write* | | GitLab | `read_api` | `api` | | Gitea / Forgejo | `read:repository`, `read:issue`, `read:user` | `write:issue` | **GitLab ist der unangenehme Fall:** kein schmaler Schreib-Scope für Issues. Entweder `api` (alles, was das Konto darf) oder auf die Issue-Anbindung verzichten. Bei `read_api` läuft der Abgleich vollständig, und geschlossene Issues werden weiterhin erkannt — nur nicht zurückgeschrieben. **Nicht verlangt:** Schreibrechte auf Code, Adminrechte, Rechte zum Anlegen von Webhooks. **Was geändert wurde** - README: neuer Abschnitt „Welche Rechte der Token braucht“, nach Funktion aufgeschlüsselt statt nach System, mit einer Tabelle, wozu jedes einzelne Recht gut ist - FEATURES 4.2: dieselbe Auskunft im Zusammenhang der Verbindungsverwaltung - `lib/git/meta.ts`: der Hinweis direkt unter dem Token-Feld war ebenfalls rein lesend formuliert — mitgezogen - `meta.test.ts` als Wächter: jeder Provider muss `createIssue`/`setIssueState` können, also muss auch jeder Hinweis die Rechte dafür nennen **Geänderte Dateien** - `README.md` · `FEATURES.md` - `src/lib/git/meta.ts` - `src/lib/git/meta.test.ts` *(neu)* **So testest du es** 1. `git switch feat/10-token-rechte` 2. `npm run docker:db` und `npm run dev` 3. **Git-Verbindungen → Verbindung hinzufügen**, oben zwischen GitHub, GitLab und Gitea umschalten 4. Erwartet: der Hinweis unter *Access Token* ändert sich je System und nennt jeweils, was zusätzlich nötig ist, wenn Aufgaben als Issue angelegt werden sollen 5. In der README den Abschnitt „Welche Rechte der Token braucht“ gegenlesen **Aufgewendete Zeit:** 00:14 **Pull Request:** #11 Nach Freigabe: `/issue-freigabe 10`

florian.wilde started working 2026-08-18 10:49:16 +00:00

florian.wilde referenced this issue from a commit

2026-08-18 10:57:11 +00:00

docs(git): jeden ausgehenden Aufruf einzeln mit seinem Recht belegen

florian.wilde worked for 7 minutes

2026-08-18 10:57:15 +00:00

florian.wilde commented

2026-08-18 10:57:40 +00:00

📎 Nachgelegt: jeder Aufruf einzeln belegt.

Rückfrage war, wie Issues und Kommentare entstehen, wenn der Token nur liest. Die Antwort steckte zwar in der Fall-A/Fall-B-Aufteilung, war aber nicht nachprüfbar — deshalb steht sie jetzt Aufruf für Aufruf da.

Was dazugekommen ist

README: je System eine vollständige Tabelle Aufruf → Zweck → benötigtes Recht. 17 Zeilen für GitHub, 13 für GitLab, 12 für Gitea. Mehr ruft Nebula nicht nach draußen.
Belege statt Behauptung: die GitHub-Zuordnung folgt der offiziellen Berechtigungsübersicht — dass /tags und /stats/commit_activity unter Metadata fallen und nicht unter Contents, ist nicht zu erraten. Für GitLab ist mit Quellenangabe belegt, dass es unterhalb von api keinen Schreibzugriff auf Issues gibt.
Abschnitt „Was Nebula nicht tut": keine Kommentare, kein Code, keine Webhooks, keine Labels, keine Adminrechte. Der Schreibzugriff besteht aus genau zwei Aufrufen — POST …/issues und PATCH/PUT …/issues/{nr}.
Hinweis am Eingabefeld: nannte Actions nicht, obwohl der CI-Zustand bei GitHub genau daran hängt. Nachgezogen.
Neuer Wächter schreibzugriffe.test.ts: klopft die drei Clients ab, dass es bei zwei Schreibaufrufen bleibt und beide auf /issues zeigen. Käme ein dritter dazu, wäre die Empfehlung „nimm ein lesendes Token" still falsch — ohne dass irgendwer einen Fehler sähe. Gegengeprobt: ein künstlicher dritter Aufruf lässt den Test fallen.

Geänderte Dateien

README.md — Abschnitt „Welche Rechte der Token braucht" neu gefasst
FEATURES.md — 4.2 mit Verweis auf die Aufruftabellen
src/lib/git/meta.ts — Actions im GitHub-Hinweis
src/lib/git/schreibzugriffe.test.ts (neu)

So testest du es

git switch feat/10-token-rechte und git pull
README lesen: Abschnitt „Welche Rechte der Token braucht" → „Jeder Aufruf einzeln"
Gegenprobe, ob die Tabellen vollständig sind: grep -n "getJson\|getJsonSafe\|sendJson" src/lib/git/gitea.ts — jede Zeile muss sich in der Tabelle wiederfinden
npm run dev → Git-Verbindungen → Verbindung hinzufügen, GitHub wählen: der Hinweis unter Access Token nennt jetzt auch Actions

Geprüft: tsc sauber · 269 Unit-Tests grün (vorher 267) · npm run build durch.

Aufgewendete Zeit: 00:21 (gesamt, beide Abschnitte)
Pull Request: #11

Nach Freigabe: /issue-freigabe 10

📎 **Nachgelegt: jeder Aufruf einzeln belegt.**  Rückfrage war, wie Issues und Kommentare entstehen, wenn der Token nur liest. Die Antwort steckte zwar in der Fall-A/Fall-B-Aufteilung, war aber nicht nachprüfbar — deshalb steht sie jetzt Aufruf für Aufruf da. **Was dazugekommen ist** - **README:** je System eine vollständige Tabelle *Aufruf → Zweck → benötigtes Recht*. 17 Zeilen für GitHub, 13 für GitLab, 12 für Gitea. Mehr ruft Nebula nicht nach draußen. - **Belege statt Behauptung:** die GitHub-Zuordnung folgt der offiziellen [Berechtigungsübersicht](https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens) — dass `/tags` und `/stats/commit_activity` unter *Metadata* fallen und nicht unter *Contents*, ist nicht zu erraten. Für GitLab ist mit Quellenangabe belegt, dass es unterhalb von `api` keinen Schreibzugriff auf Issues gibt. - **Abschnitt „Was Nebula nicht tut":** keine Kommentare, kein Code, keine Webhooks, keine Labels, keine Adminrechte. Der Schreibzugriff besteht aus genau zwei Aufrufen — `POST …/issues` und `PATCH`/`PUT …/issues/{nr}`. - **Hinweis am Eingabefeld:** nannte *Actions* nicht, obwohl der CI-Zustand bei GitHub genau daran hängt. Nachgezogen. - **Neuer Wächter** `schreibzugriffe.test.ts`: klopft die drei Clients ab, dass es bei zwei Schreibaufrufen bleibt und beide auf `/issues` zeigen. Käme ein dritter dazu, wäre die Empfehlung „nimm ein lesendes Token" still falsch — ohne dass irgendwer einen Fehler sähe. Gegengeprobt: ein künstlicher dritter Aufruf lässt den Test fallen. **Geänderte Dateien** - `README.md` — Abschnitt „Welche Rechte der Token braucht" neu gefasst - `FEATURES.md` — 4.2 mit Verweis auf die Aufruftabellen - `src/lib/git/meta.ts` — *Actions* im GitHub-Hinweis - `src/lib/git/schreibzugriffe.test.ts` *(neu)* **So testest du es** 1. `git switch feat/10-token-rechte` und `git pull` 2. README lesen: Abschnitt „Welche Rechte der Token braucht" → „Jeder Aufruf einzeln" 3. Gegenprobe, ob die Tabellen vollständig sind: `grep -n "getJson\|getJsonSafe\|sendJson" src/lib/git/gitea.ts` — jede Zeile muss sich in der Tabelle wiederfinden 4. `npm run dev` → **Git-Verbindungen → Verbindung hinzufügen**, GitHub wählen: der Hinweis unter *Access Token* nennt jetzt auch Actions **Geprüft:** `tsc` sauber · 269 Unit-Tests grün (vorher 267) · `npm run build` durch. **Aufgewendete Zeit:** 00:21 (gesamt, beide Abschnitte) **Pull Request:** #11 Nach Freigabe: `/issue-freigabe 10`

florian.wilde closed this issue

2026-08-18 11:51:07 +00:00

florian.wilde referenced this issue from a commit

2026-08-18 11:51:08 +00:00

Merge #10: Token-Rechte vollstaendig dokumentiert

florian.wilde commented

2026-08-18 11:51:18 +00:00

🚀 Freigegeben und nach main übernommen.

Merge-Commit: 77567c0
Pull Request: #11 (gemergt)
Gesamtaufwand: 00:21

Issue wird geschlossen.

🚀 **Freigegeben und nach `main` übernommen.**  - Merge-Commit: `77567c0` - Pull Request: #11 (gemergt) - Gesamtaufwand: 00:21 Issue wird geschlossen.

florian.wilde removed the zu-testen label 2026-08-18 11:51:20 +00:00

florian.wilde referenced this issue from a commit

2026-08-18 12:46:39 +00:00

chore(release): v1.10.1

florian.wilde referenced this issue

2026-08-18 12:46:50 +00:00

Release v1.10.1 #14

florian.wilde referenced this issue

2026-09-09 22:16:48 +00:00

Release v1.11.0 #26

Sign in to join this conversation.