iris/iris-plugins
1
0
Fork 0
Code Issues 17 Pull requests Projects Releases Packages Wiki Activity Actions

Einstellungen: eigener Forgejo als Default, Repos per Picker #224

New issue
Closed
opened 2026-10-22 17:13:46 +00:00 by alf · 7 comments
alf commented 2026-10-22 17:13:46 +00:00
Owner
Copy link

Ziel

Das Einstellungs-Panel (web/settings.html + panel_api.py) verlangt heute von Hand: Forgejo-Adresse, Plugin-Repo, Registry-Repo, Token.

  1. Eigener Forgejo als Default: Jede Iris-Installation bringt einen eigenen Forgejo mit (iris/Iris#112: Mac = Homebrew + launchd, nur 127.0.0.1; Linux = Docker-Service). Der ist per Default „fix und fertig“ eingetragen — Adresse automatisch, Zugang = die Admin-Basic-Anmeldung (automatisch, nie angezeigt, nie in der Konfigurationsdatei gespeichert). Manuelle Eingabe (Adresse, Token) bleibt als zweite Quelle „Manueller Server“ erhalten (heutiges Verhalten, z. B. für forgejo.lewerken.duckdns.org).
  2. Repos per Picker: Plugin-Repo und Registry-Repo sind Picker statt Textfelder — die Repos, die der gewählte Zugriff sieht (GET /api/v1/user/repos inkl. Org-Repos, paginiert), plus manuelle Eingabe als Fallback und „neues Repo anlegen“ (damit ein frischer eigener Forgejo iris-plugins/registry direkt im Panel bekommt).
  3. Skill: einstellungen() nutzt den eigenen Forgejo, wenn die Konfiguration auf ihn zeigt (server-Feld, oder die Adresse stimmt überein, oder sie ist leer) — der Zugang kommt zur Laufzeit per Basic; es steht kein Token in der Datei.

Erkennung des eigenen Forgejo

  • Umgebungsvariablen IRIS_FORGEJO_URL / IRIS_FORGEJO_USER / IRIS_FORGEJO_PASSWORD,
  • sonst Datei $IRIS_APP_SUPPORT/forgejo-admin.json (Mac: ~/Library/Application Support/Iris, 0600, von der App geschrieben; ein optionales url-Feld hat Vorrang vor ROOT_URL aus forgejo/custom/conf/app.ini, Rückfall http://127.0.0.1:3300). Auf dem Linux-Server spiegelt der Server dieselbe Datei in das App-Support-Verzeichnis, das server und beide Hermes-Container teilen (iris/iris-linux-server#90) — so kommt der Zugang in Panel und Skill ohne Umgebungsvariablen.

Zugang: Basic statt Token (Entscheidung 2026-10-22)

Forgejo 16+ liefert bei der Token-Anlage kein Klartext zurück (nur die SHA1), und genau diese SHA1 lehnt die API für alle Routen mit 403 ab, während Git sie akzeptiert (an 16.0.6 gemessen, git ls-remote ok / /user/repos 403). Für den eigenen, ausschließlich intern erreichbaren Forgejo ist die Admin-Basic der robuste Weg: sie gilt für API und Git auf jeder Version, und die Konfigurationsdatei bleibt ohne Geheimnis (server: eigener_forgejo + Adresse; das Passwort kommt zur Laufzeit aus Datei bzw. Variablen und verlässt das Modul nur als Authorization-Header). Manueller Server: wie bisher mit Token (im Web-UI angelegtes Klartext-Token funktioniert auf allen Versionen).

Konfig-Format (vorwärtskompatibel zu iris-plugins#113)

Neues Feld server: eigener_forgejo | leer = manuell. #113 (iris-forgejo, eigene Instanzen/Profile) baut darauf auf; die Instanzen-Profile selbst sind nicht Teil dieses Issues.

Abnahme

  • Panel: eigener Forgejo verfügbar → automatisch ausgewählt, Adresse + Erreichbarkeits-Badge, kein Token-Feld; „Eigener Forgejo eintragen“ speichert server+Adresse; Picker listet die Repos; „neues Repo anlegen“ legt ein privates Repo an; Verbindungstest prüft Server/Repo/Registry gegen die Admin-Anmeldung.
  • Manueller Server: wie heute (Textfelder) + Picker; Verbindungstest unverändert.
  • config-status: eigener Forgejo eingetragen/erkannt → configured (ohne Netz, nur lokale Erkennung).
  • Tests: Fake-Forgejo mit Basic (/version, /user/repos paginiert + Repo-Anlage, Admin-Repo-Details) + einstellungen()-Fallback; alle bestehenden Tests grün (insgesamt 206).
  • Reale Belege: eigener-Weg auf dem Linux-Dev-Server (iris-server, Drop-Zone); Picker auf dem Mac gegen den öffentlichen Forgejo.
  • Version 0.1.14, Changelog, Anleitung erste-schritte.md/einschraenkungen.md.
## Ziel Das Einstellungs-Panel (`web/settings.html` + `panel_api.py`) verlangt heute von Hand: Forgejo-Adresse, Plugin-Repo, Registry-Repo, Token. 1. **Eigener Forgejo als Default:** Jede Iris-Installation bringt einen eigenen Forgejo mit (iris/Iris#112: Mac = Homebrew + launchd, nur 127.0.0.1; Linux = Docker-Service). Der ist per Default „fix und fertig“ eingetragen — Adresse automatisch, **Zugang = die Admin-Basic-Anmeldung** (automatisch, nie angezeigt, nie in der Konfigurationsdatei gespeichert). Manuelle Eingabe (Adresse, Token) bleibt als zweite Quelle „Manueller Server“ erhalten (heutiges Verhalten, z. B. für `forgejo.lewerken.duckdns.org`). 2. **Repos per Picker:** Plugin-Repo und Registry-Repo sind Picker statt Textfelder — die Repos, die der gewählte Zugriff sieht (`GET /api/v1/user/repos` inkl. Org-Repos, paginiert), plus manuelle Eingabe als Fallback und „neues Repo anlegen“ (damit ein frischer eigener Forgejo `iris-plugins`/`registry` direkt im Panel bekommt). 3. **Skill:** `einstellungen()` nutzt den eigenen Forgejo, wenn die Konfiguration auf ihn zeigt (`server`-Feld, oder die Adresse stimmt überein, oder sie ist leer) — der Zugang kommt zur Laufzeit per Basic; es steht kein Token in der Datei. ## Erkennung des eigenen Forgejo - Umgebungsvariablen `IRIS_FORGEJO_URL` / `IRIS_FORGEJO_USER` / `IRIS_FORGEJO_PASSWORD`, - sonst Datei `$IRIS_APP_SUPPORT/forgejo-admin.json` (Mac: `~/Library/Application Support/Iris`, 0600, von der App geschrieben; ein optionales `url`-Feld hat Vorrang vor `ROOT_URL` aus `forgejo/custom/conf/app.ini`, Rückfall `http://127.0.0.1:3300`). Auf dem **Linux-Server spiegelt der Server dieselbe Datei** in das App-Support-Verzeichnis, das `server` und beide Hermes-Container teilen (iris/iris-linux-server#90) — so kommt der Zugang in Panel **und** Skill ohne Umgebungsvariablen. ## Zugang: Basic statt Token (Entscheidung 2026-10-22) Forgejo **16+** liefert bei der Token-Anlage kein Klartext zurück (nur die SHA1), und genau diese SHA1 lehnt die API für **alle** Routen mit 403 ab, während Git sie akzeptiert (an 16.0.6 gemessen, git ls-remote ok / `/user/repos` 403). Für den eigenen, ausschließlich intern erreichbaren Forgejo ist die **Admin-Basic** der robuste Weg: sie gilt für API **und** Git auf jeder Version, und die Konfigurationsdatei bleibt ohne Geheimnis (`server: eigener_forgejo` + Adresse; das Passwort kommt zur Laufzeit aus Datei bzw. Variablen und verlässt das Modul nur als `Authorization`-Header). Manueller Server: wie bisher mit Token (im Web-UI angelegtes Klartext-Token funktioniert auf allen Versionen). ## Konfig-Format (vorwärtskompatibel zu iris-plugins#113) Neues Feld `server`: `eigener_forgejo` | leer = manuell. #113 (`iris-forgejo`, eigene Instanzen/Profile) baut darauf auf; die Instanzen-Profile selbst sind **nicht** Teil dieses Issues. ## Abnahme - Panel: eigener Forgejo verfügbar → automatisch ausgewählt, Adresse + Erreichbarkeits-Badge, kein Token-Feld; „Eigener Forgejo eintragen“ speichert `server`+Adresse; Picker listet die Repos; „neues Repo anlegen“ legt ein privates Repo an; Verbindungstest prüft Server/Repo/Registry gegen die Admin-Anmeldung. - Manueller Server: wie heute (Textfelder) + Picker; Verbindungstest unverändert. - `config-status`: eigener Forgejo eingetragen/erkannt → `configured` (ohne Netz, nur lokale Erkennung). - Tests: Fake-Forgejo mit Basic (`/version`, `/user/repos` paginiert + Repo-Anlage, Admin-Repo-Details) + `einstellungen()`-Fallback; alle bestehenden Tests grün (insgesamt 206). - Reale Belege: eigener-Weg auf dem Linux-Dev-Server (iris-server, Drop-Zone); Picker auf dem Mac gegen den öffentlichen Forgejo. - Version 0.1.14, Changelog, Anleitung `erste-schritte.md`/`einschraenkungen.md`.
alf commented 2026-10-22 18:57:41 +00:00
Author
Owner
Copy link

PR #226 gemergt: feat(iris-plugin-dev): eigener Forgejo fix und fertig, Repos per Picker (0.1.14) (#224)
#226

Commits:

  • feat(iris-plugin-dev): eigener Forgejo fix und fertig, Repos per Picker (0.1.14) (#224)

Befund

Das Panel verlangte von Hand Adresse, zwei Repos und ein Token. Dabei bringt jede Iris-Installation ihren eigenen Forgejo mit (iris/Iris#112) — und auf Forgejo 16+ taugt das Token-Muster des App-Vault-Logins nicht mehr für API-Aufrufe: die Anlage liefert nur die SHA1 zurück (kein Klartext), und genau diese SHA1 lehnt die API für alle Routen mit 403 ab, während Git sie akzeptiert (an 16.0.6 gemessen: git ls-remote ok, /user/repos 403; mit Basic 200 überall). Die App bleibt davon im Alltag unberührt (Tages-Sync ist reines Git); neuangelegte Tokens wären auf 16 API-unbrauchbar.

Geändert

  • pd_eigener.py (neu): Erkennung des eigenen Forgejo ($IRIS_APP_SUPPORT/forgejo-admin.json — Mac: von der App, Linux: gespiegelt vom Server, iris/iris-linux-server#90 — oder IRIS_FORGEJO_*-Variablen; Adresse aus url-Feld / ROOT_URL / Standard) und Basic-Authentifizierung dafür: erreichbar, repos (paginiert /user/repos), repo_anlegen, git_kopf. Das Admin-Passwort verlässt das Modul nur als Authorization-Header.
  • pd_forgejo.py: einstellungen() kennt das server-Feld (eigener_forgejo = Basic zur Laufzeit, kein Token in der Datei; alte Token-Konfigurationen auf der eigenen Adresse heilen automatisch um, Konfigurationen fremder Server bleiben unberührt, explizite Env-Varialen suppressen den Fallback). Forgejo.anfrage()/git()/_authentifizierung(): modusabhängiger Authorization-Header (Basic/Token) inkl. korrektem Schwärzen des jeweiligen Geheimnisses.
  • panel_api.py: neue Befehle eigener-einrichten, repos (Picker, paginiert), repo-anlegen; status meldet den eigenen Forgejo (verfuegbar/erreichbar); test prüft im Eigenfall Server/Repo/Registry gegen die Admin-Anmeldung; save speichert server und setzt die eigene Adresse aus dem System.
  • web/settings.html: Quellenwahl (eigener Forgejo mit Badge / manueller Server), beide Repos per Picker + „anderes“-Feld + „neues Repo anlegen“, angepasste Hinweise.
  • Doku/Store: erste-schritte.md (Quellenwahl + Picker), einschraenkungen.md (neue Meldung), store/description.md + store-page.json + store/changelog.md 0.1.14, plugin.json 0.1.14 mit neuen panel_api-Befehlen.
  • Tests: test_eigener.py (neu, 19) — Erkennung, Basic (Repos-Paginierung, 401/409, Passwort-Schwärzung, Erreichbarkeit), einstellungen()-Fallback (Basic statt tot-erkanntem Token, fremde Konfiguration unberührt, Env-Suppression, Fehlermeldungen). Fake-Forgejo (test_forgejo/helfer) nimmt Basic an den Eigen-Routen; Testumgebungen hermetisch (IRIS_APP_SUPPORT/IRIS_FORGEJO_* gepatcht). Panel-Tests um Eigenfall erweitert; Manifest-Test auf die neuen Befehle.

Geprüft

  • python3 -I -m unittest discover -s tests: 206 passed (lokal, Mac).
  • Paket build-irisplugin.sh baut; Inhalt geprüft (neue/aktualisierte Dateien drin, PLAN.md/tests/store draußen); Privatheitsscan: nur die seit 0.1.13 erlaubte öffentliche Forgejo-Domain, sonst keine Hostnamen/Pfade/Zugangsdaten.
  • Live-Probe auf dem echten eigenen Forgejo der Iris (iris-server, 16.0.6, Basic vs. sha1-Token) — die Entscheidungsgrundlage oben; alle Wegwerf-Tokens gelöscht.
  • forgejo-admin.json-Reader gegen beide realen Formate (Mac-App-Datei ohne url-Feld; Linux-Spiegel mit url) abgedeckt.

Nicht geprüft

  • Nicht deployt: Paket liegt auf ~/Desktop und wartet auf die Drop-Zone von iris-server (nächster Schritt, zusammen mit dem frisch gemergten linux-server-Stand #90/PR 92); Panel-Render auf dem Linux-Server und der Picker gegen den öffentlichen Forgejo auf dem Mac fehlen noch.
  • Mac ohne eigenen Forgejo (der steht dort nicht): der Fallback-Weg „manueller Server“ ist nur per Test abgedeckt, nicht im echten Mac-Panel.
  • hermes-Nutzung der einstellungen()-Basic-Anmeldung im Hermes-Container (Datei-Leseweg über den gemeinsamen Mount) — vom Code aus korrekt, nicht in einem echten Skill-Lauf gemessen.

Grenzen / Offen

  • hermes/Skill auf einem Mac ohne eigenen Forgejo + manueller Server: wie bisher Token-basiert — auf einem 16er Forgejo außerhalb der Iris könnte ein per Web-UI angelegtes Klartext-Token API- und Git-fähig sein; ein von der API angelegtes wäre es für die API nicht (bekanntes Forgejo-16-Verhalten, hier unbehebbar, daher der Basic-Default nur für den eigenen Forgejo).
  • Das server-Feld ist vorwärtskompatibel zu iris-plugins#113 (iris-forgejo: mehrere Profile) gehalten, baut dort aber nichts auf.
PR #226 gemergt: feat(iris-plugin-dev): eigener Forgejo fix und fertig, Repos per Picker (0.1.14) (#224) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/226 Commits: - feat(iris-plugin-dev): eigener Forgejo fix und fertig, Repos per Picker (0.1.14) (#224) --- ## Befund Das Panel verlangte von Hand Adresse, zwei Repos und ein Token. Dabei bringt jede Iris-Installation ihren eigenen Forgejo mit (iris/Iris#112) — und auf **Forgejo 16+** taugt das Token-Muster des App-Vault-Logins nicht mehr für API-Aufrufe: die Anlage liefert nur die SHA1 zurück (kein Klartext), und genau diese SHA1 lehnt die API für alle Routen mit 403 ab, während Git sie akzeptiert (an 16.0.6 gemessen: `git ls-remote` ok, `/user/repos` 403; mit Basic 200 überall). Die App bleibt davon im Alltag unberührt (Tages-Sync ist reines Git); neuangelegte Tokens wären auf 16 API-unbrauchbar. ## Geändert - **`pd_eigener.py` (neu):** Erkennung des eigenen Forgejo (`$IRIS_APP_SUPPORT/forgejo-admin.json` — Mac: von der App, Linux: gespiegelt vom Server, iris/iris-linux-server#90 — oder `IRIS_FORGEJO_*`-Variablen; Adresse aus `url`-Feld / `ROOT_URL` / Standard) und **Basic-Authentifizierung** dafür: `erreichbar`, `repos` (paginiert `/user/repos`), `repo_anlegen`, `git_kopf`. Das Admin-Passwort verlässt das Modul nur als `Authorization`-Header. - **`pd_forgejo.py`:** `einstellungen()` kennt das `server`-Feld (`eigener_forgejo` = Basic zur Laufzeit, kein Token in der Datei; alte Token-Konfigurationen auf der eigenen Adresse heilen automatisch um, Konfigurationen fremder Server bleiben unberührt, explizite Env-Varialen suppressen den Fallback). `Forgejo.anfrage()`/`git()`/`_authentifizierung()`: modusabhängiger `Authorization`-Header (Basic/Token) inkl. korrektem Schwärzen des jeweiligen Geheimnisses. - **`panel_api.py`:** neue Befehle `eigener-einrichten`, `repos` (Picker, paginiert), `repo-anlegen`; `status` meldet den eigenen Forgejo (`verfuegbar`/`erreichbar`); `test` prüft im Eigenfall Server/Repo/Registry gegen die Admin-Anmeldung; `save` speichert `server` und setzt die eigene Adresse aus dem System. - **`web/settings.html`:** Quellenwahl (eigener Forgejo mit Badge / manueller Server), beide Repos per Picker + „anderes“-Feld + „neues Repo anlegen“, angepasste Hinweise. - **Doku/Store:** `erste-schritte.md` (Quellenwahl + Picker), `einschraenkungen.md` (neue Meldung), `store/description.md` + `store-page.json` + `store/changelog.md` 0.1.14, `plugin.json` 0.1.14 mit neuen `panel_api`-Befehlen. - **Tests:** `test_eigener.py` (neu, 19) — Erkennung, Basic (Repos-Paginierung, 401/409, Passwort-Schwärzung, Erreichbarkeit), `einstellungen()`-Fallback (Basic statt tot-erkanntem Token, fremde Konfiguration unberührt, Env-Suppression, Fehlermeldungen). Fake-Forgejo (test_forgejo/helfer) nimmt Basic an den Eigen-Routen; Testumgebungen hermetisch (`IRIS_APP_SUPPORT`/`IRIS_FORGEJO_*` gepatcht). Panel-Tests um Eigenfall erweitert; Manifest-Test auf die neuen Befehle. ## Geprüft - `python3 -I -m unittest discover -s tests`: **206 passed** (lokal, Mac). - Paket `build-irisplugin.sh` baut; Inhalt geprüft (neue/aktualisierte Dateien drin, `PLAN.md`/`tests`/`store` draußen); Privatheitsscan: nur die seit 0.1.13 erlaubte öffentliche Forgejo-Domain, sonst keine Hostnamen/Pfade/Zugangsdaten. - Live-Probe auf dem echten eigenen Forgejo der Iris (iris-server, 16.0.6, Basic vs. sha1-Token) — die Entscheidungsgrundlage oben; alle Wegwerf-Tokens gelöscht. - `forgejo-admin.json`-Reader gegen beide realen Formate (Mac-App-Datei ohne `url`-Feld; Linux-Spiegel mit `url`) abgedeckt. ## Nicht geprüft - **Nicht deployt:** Paket liegt auf `~/Desktop` und wartet auf die Drop-Zone von `iris-server` (nächster Schritt, zusammen mit dem frisch gemergten linux-server-Stand #90/PR 92); Panel-Render auf dem Linux-Server und der Picker gegen den **öffentlichen** Forgejo auf dem Mac fehlen noch. - Mac ohne eigenen Forgejo (der steht dort nicht): der Fallback-Weg „manueller Server“ ist nur per Test abgedeckt, nicht im echten Mac-Panel. - `hermes`-Nutzung der `einstellungen()`-Basic-Anmeldung **im** Hermes-Container (Datei-Leseweg über den gemeinsamen Mount) — vom Code aus korrekt, nicht in einem echten Skill-Lauf gemessen. ## Grenzen / Offen - `hermes`/Skill auf einem **Mac ohne** eigenen Forgejo + manueller Server: wie bisher Token-basiert — auf einem 16er Forgejo außerhalb der Iris könnte ein per Web-UI angelegtes Klartext-Token API- und Git-fähig sein; ein von der API angelegtes wäre es für die API nicht (bekanntes Forgejo-16-Verhalten, hier unbehebbar, daher der Basic-Default nur für den **eigenen** Forgejo). - Das `server`-Feld ist vorwärtskompatibel zu iris-plugins#113 (`iris-forgejo`: mehrere Profile) gehalten, baut dort aber nichts auf.
alf commented 2026-10-22 19:27:23 +00:00
Author
Owner
Copy link

PR #227 gemergt: fix(iris-plugin-dev): Picker und Repo-Anlage nennen das fehlende Recht „Benutzer“ am Token (0.1.15, #224)
#227

Commits:

  • fix(iris-plugin-dev): Picker und Repo-Anlage nennen das fehlende Recht „Benutzer“ am Token (0.1.15, #224)

Stand (0.1.15)

Befund: Bei der Live-Verifikation von 0.1.14 auf alf@iris-server zeigte sich: Das gespeicherte Token der öffentlichen Forgejo-Installation (Rechte Repository + Issue) bekommt auf GET /user/repos — also genau dem Picker — 403 [read:user], gemessen gegen den echten Forgejo 15. Auf POST /user/repos (Probe mit ungültigem Namen, nichts wurde angelegt) verlangt derselbe Forgejo write:user. Forgejo 15+ prüft API-Rechte also pro Token, und die Repo-Liste sowie die Repo-Anlage hängen unter der Kategorie „Benutzer“ — ein Token nach der bisherigen Anleitung (Repository + Issue) listet und legt nichts auf.

Geändert:

  • panel_api.py: Der Picker (repos), „Neues Repo anlegen“ (repo-anlegen) und der Verbindungstest (neuer Schritt Picker, GET /user/repos?limit=1) nennen bei 403 das fehlende Recht „Benutzer“ mit konkretem Hinweis (Einstellungen → Anwendungen, am Token nachtragen; Forgejo 15+).
  • web/settings.html, docs/erste-schritte.md, Store-Text: Das Token braucht Repository, Issue und Benutzer (jeweils Lesen + Schreiben), ohne Admin-Rechte.
  • Eigener Forgejo (Basic): unberührt — Basic hat keine Scope-Semantik; am eigenen Forgejo arbeitet der Picker ohne jedes Token-Recht.
  • Tests: Fake-Erweiterung um den Token ohne-benutzer und die /user/repos-Route; neue Tests für den Picker-Schritt und die Picker-Fehlermeldung.

Geprüft:

  • 209 Unit-Tests grün (vorher 206, 3 neu).
  • Paket 0.1.15 gebaut, Datenschutz-Scan des Pakets sauber.
  • Live (iris-server): Picker gegen den eigenen Forgejo 16.0.6 mit Basic listet korrekt (iris-vault); gegen die öffentliche Forgejo 15 bestätigt der 403 mit [read:user] das Befund-Muster.
  • GET /user/repos 403 read:user und POST /user/repos 403 write:user beide am echten Forgejo 15 gemessen.

Nicht geprüft:

  • Das neue Paket ist noch nicht in der Drop-Zone von alf@iris-server installiert und visuell im Browser geprüft (nächster Schritt nach dem Merge).
  • Das gespeicherte Token der öffentlichen Forgejo hat das Recht „Benutzer“ noch nicht — bis Alf es in der Forgejo-UI nachträgt, zeigt der Picker dort rot; das Textfeld „oder anderer“ und die eigentliche Arbeit (Issues, Branches, PRs, Git) funktionieren mit den vorhandenen Rechten weiter.
PR #227 gemergt: fix(iris-plugin-dev): Picker und Repo-Anlage nennen das fehlende Recht „Benutzer“ am Token (0.1.15, #224) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/227 Commits: - fix(iris-plugin-dev): Picker und Repo-Anlage nennen das fehlende Recht „Benutzer“ am Token (0.1.15, #224) --- ## Stand (0.1.15) **Befund:** Bei der Live-Verifikation von 0.1.14 auf `alf@iris-server` zeigte sich: Das gespeicherte Token der öffentlichen Forgejo-Installation (Rechte Repository + Issue) bekommt auf `GET /user/repos` — also genau dem Picker — **403 [read:user]**, gemessen gegen den echten Forgejo 15. Auf `POST /user/repos` (Probe mit ungültigem Namen, nichts wurde angelegt) verlangt derselbe Forgejo **write:user**. Forgejo 15+ prüft API-Rechte also pro Token, und die Repo-Liste sowie die Repo-Anlage hängen unter der Kategorie „Benutzer“ — ein Token nach der bisherigen Anleitung (Repository + Issue) listet und legt nichts auf. **Geändert:** - `panel_api.py`: Der Picker (`repos`), „Neues Repo anlegen“ (`repo-anlegen`) und der Verbindungstest (neuer Schritt **Picker**, `GET /user/repos?limit=1`) nennen bei 403 das fehlende Recht „Benutzer“ mit konkretem Hinweis (Einstellungen → Anwendungen, am Token nachtragen; Forgejo 15+). - `web/settings.html`, `docs/erste-schritte.md`, Store-Text: Das Token braucht **Repository**, **Issue** und **Benutzer** (jeweils Lesen + Schreiben), ohne Admin-Rechte. - Eigener Forgejo (Basic): unberührt — Basic hat keine Scope-Semantik; am eigenen Forgejo arbeitet der Picker ohne jedes Token-Recht. - Tests: Fake-Erweiterung um den Token `ohne-benutzer` und die `/user/repos`-Route; neue Tests für den Picker-Schritt und die Picker-Fehlermeldung. **Geprüft:** - 209 Unit-Tests grün (vorher 206, 3 neu). - Paket 0.1.15 gebaut, Datenschutz-Scan des Pakets sauber. - Live (iris-server): Picker gegen den eigenen Forgejo 16.0.6 mit Basic listet korrekt (`iris-vault`); gegen die öffentliche Forgejo 15 bestätigt der 403 mit `[read:user]` das Befund-Muster. - `GET /user/repos` 403 read:user und `POST /user/repos` 403 write:user beide am echten Forgejo 15 gemessen. **Nicht geprüft:** - Das neue Paket ist noch nicht in der Drop-Zone von `alf@iris-server` installiert und visuell im Browser geprüft (nächster Schritt nach dem Merge). - Das gespeicherte Token der öffentlichen Forgejo hat das Recht „Benutzer“ noch nicht — bis Alf es in der Forgejo-UI nachträgt, zeigt der Picker dort rot; das Textfeld „oder anderer“ und die eigentliche Arbeit (Issues, Branches, PRs, Git) funktionieren mit den vorhandenen Rechten weiter.
alf commented 2026-10-22 20:07:30 +00:00
Author
Owner
Copy link

PR #228 gemergt: chore(iris-plugin-dev): Store-Seite aus store-page.json neu erzeugt (0.1.15) (#224)
#228

Commits:

  • chore(iris-plugin-dev): Store-Seite aus store-page.json neu erzeugt (0.1.15) (#224)
PR #228 gemergt: chore(iris-plugin-dev): Store-Seite aus store-page.json neu erzeugt (0.1.15) (#224) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/228 Commits: - chore(iris-plugin-dev): Store-Seite aus store-page.json neu erzeugt (0.1.15) (#224)
alf commented 2026-10-22 21:31:20 +00:00
Author
Owner
Copy link

PR #229 gemergt: fix(iris-plugin-dev): eigener Forgejo im Sharing-Modus — CA-Vertrauen und urllib-Handler-Kontext (0.1.16, #224)
#229

Commits:

  • fix(iris-plugin-dev): eigener Forgejo im Sharing-Modus — CA-Vertrauen und urllib-Handler-Kontext (0.1.16, #224)

Befund

Das Mac-Panel zeigte „Der eigene Forgejo unter http://forgejo:3300 … nicht erreichbar“:

  1. Die Mac-Datei ~/Library/Application Support/Iris/forgejo-admin.json enthielt eine Kopie des Linux-Spiegels (3 Felder inkl. url: http://forgejo:3300 — interne Docker-Adresse, auf dem Mac nicht auflösbar — und das Admin-Passwort des Linux-Servers). Byte-Layout exakt der json.dumps(indent=2)-Ausgabe des Linux-Writers; die App selbst schreibt 2 Felder (Swift-JSONEncoder), das Plugin nur Lesezugriff — die Kopie kam von außen, der Schreiber ist nicht identifiziert (Mac-/Linux-Shell-Historie, eigene Session, Plugin-Quellen, Backup geprüft; 20:54 lokal geschrieben, Linux-Gegenstück 18:59 UTC).
  2. Brisant: die App hält das Passwort nicht im Speicher (jeder loadSecrets()-Aufruf liest die Datei) — der Vault-Sync der App lief bereits mit den falschen Zugangsdaten, und die App hatte keine Recovery-Fähigkeit mehr über die Datei.

Recovery (Mac): Passwort des Admins per forgejo admin user change-password (das exakte CLI-Muster der App) auf ein frisches 32-Byte-token_urlsafe-Passwort gesetzt, Datei im App-Format (2 Felder, 0600, atomisch) neu geschrieben; die kaputte Kopie bleibt als forgejo-admin.json.corrupt-2026-10-22 daneben. Verifiziert: neues Passwort 200 auf 127.0.0.1 und 192.168.178.94, altes Passwort 401 auf beiden (also nirgendwo mehr gültig).

Was geändert wurde

  • pd_netz.py: _kontext() lädt die CA der Installation ($IRIS_APP_SUPPORT/forgejo-tls/ca.crt, Sharing-Modus = selbst signiert) in den ssl-Kontext; ohne die Datei bleibt der System-Truststore (Linux: reines HTTP, unverändert). https_open versorgt den Handler immer mit dem frisch gebauten Kontext — self._context or … hätte nie gegriffen, weil urllib.request.HTTPSHandler in neueren Pythons immer einen CA-freien Default-Kontext trägt (gemessen: 192 System-CAs, eigene nie geladen).
  • tests/test_netz.py: 2 neue Tests mit echten openssl-Zertifikaten (Temp-Verzeichnis, IRIS_APP_SUPPORT dorthin): mit CA aus dem App-Support verifiziert (200), ohne CA-Datei muss der Request scheitern. Die Zertifikate tragen die vollen Erweiterungen wie die echten (authorityKeyIdentifier, keyUsage/keyCertSign) — OpenSSL 3.x verifiziert streng und verwirft beides (beide Versagensformen im Testlauf beobachtet).
  • plugin.json 0.1.16 + Changelog; store/changelog.md, docs/erste-schritte.md (Sharing-Modus funktioniert von selbst), PLAN.md (0.1.16 + Lesson).

Geprüft

  • 211 Tests grün (python3 -m unittest discover -s tests).
  • Live auf dem Mac: pd_eigener.eigener_server() → https://192.168.178.94:3300, erreichbar = True (Admin-Basic über TLS mit der App-CA), repos() = ['iris-admin/iris-vault'] — der Picker-Pfad des Panels, exakt wie vom Panel aufgerufen.
  • curl --cacert forgejo-tls/ca.crt gegen den eigenen Forgejo: TLS-Verifizierung ok (OpenSSL 4 CLI); altes Passwort 401 / neues 200 auf beiden Hostnamen.

Nicht geprüft

  • Ob das Panel im geöffneten Fenster jetzt grün zeigt (Nutzer-Blick; der zugrunde liegende Pfad ist live verifiziert).
  • Wer um 20:54 die Linux-Kopie auf den Mac gelegt hat (offen — beim Nutzer erfragt); ein erneutes Übertünchen der Datei würde den Fehler wiederholen.
  • Dass der iOS-Client nach dem 19:17er Zertifikats-Neuausstellung der App (CA neu, forgejo-tls/) weiter verbindet — das ist App-interne Sache und wurde nicht angefasst.
  • Der 18:59-UTC-Password-Reset auf dem Linux-Server (Secret-Store hatte die Schlüssel offenbar verloren) wurde nicht weiter rückverfolgt: Der Server ist intern konsistent (Datei = Secret-Store = DB nach jedem ensure_setup), und das Plugin liest die Datei je Aufruf, also selbstheilend.
  • Öffentlichung steht aus (nur auf ausdrückliches Wort); bis dahin ist 0.1.16 nur lokal installiert.
PR #229 gemergt: fix(iris-plugin-dev): eigener Forgejo im Sharing-Modus — CA-Vertrauen und urllib-Handler-Kontext (0.1.16, #224) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/229 Commits: - fix(iris-plugin-dev): eigener Forgejo im Sharing-Modus — CA-Vertrauen und urllib-Handler-Kontext (0.1.16, #224) --- ## Befund Das Mac-Panel zeigte „Der eigene Forgejo unter http://forgejo:3300 … nicht erreichbar“: 1. Die Mac-Datei `~/Library/Application Support/Iris/forgejo-admin.json` enthielt eine **Kopie des Linux-Spiegels** (3 Felder inkl. `url: http://forgejo:3300` — interne Docker-Adresse, auf dem Mac nicht auflösbar — und das Admin-Passwort des Linux-Servers). Byte-Layout exakt der `json.dumps(indent=2)`-Ausgabe des Linux-Writers; die App selbst schreibt 2 Felder (Swift-JSONEncoder), das Plugin nur Lesezugriff — die Kopie kam von außen, **der Schreiber ist nicht identifiziert** (Mac-/Linux-Shell-Historie, eigene Session, Plugin-Quellen, Backup geprüft; 20:54 lokal geschrieben, Linux-Gegenstück 18:59 UTC). 2. Brisant: die App hält das Passwort **nicht im Speicher** (jeder `loadSecrets()`-Aufruf liest die Datei) — der Vault-Sync der App lief bereits mit den falschen Zugangsdaten, und die App hatte keine Recovery-Fähigkeit mehr über die Datei. **Recovery (Mac):** Passwort des Admins per `forgejo admin user change-password` (das exakte CLI-Muster der App) auf ein frisches 32-Byte-`token_urlsafe`-Passwort gesetzt, Datei im App-Format (2 Felder, 0600, atomisch) neu geschrieben; die kaputte Kopie bleibt als `forgejo-admin.json.corrupt-2026-10-22` daneben. Verifiziert: neues Passwort 200 auf 127.0.0.1 **und** 192.168.178.94, altes Passwort 401 auf beiden (also nirgendwo mehr gültig). ## Was geändert wurde - `pd_netz.py`: `_kontext()` lädt die CA der Installation (`$IRIS_APP_SUPPORT/forgejo-tls/ca.crt`, Sharing-Modus = selbst signiert) in den `ssl`-Kontext; ohne die Datei bleibt der System-Truststore (Linux: reines HTTP, unverändert). `https_open` versorgt den Handler **immer** mit dem frisch gebauten Kontext — `self._context or …` hätte nie gegriffen, weil `urllib.request.HTTPSHandler` in neueren Pythons immer einen CA-freien Default-Kontext trägt (gemessen: 192 System-CAs, eigene nie geladen). - `tests/test_netz.py`: 2 neue Tests mit echten openssl-Zertifikaten (Temp-Verzeichnis, `IRIS_APP_SUPPORT` dorthin): mit CA aus dem App-Support verifiziert (200), ohne CA-Datei muss der Request scheitern. Die Zertifikate tragen die vollen Erweiterungen wie die echten (`authorityKeyIdentifier`, `keyUsage`/`keyCertSign`) — OpenSSL 3.x verifiziert streng und verwirft beides (beide Versagensformen im Testlauf beobachtet). - `plugin.json` 0.1.16 + Changelog; `store/changelog.md`, `docs/erste-schritte.md` (Sharing-Modus funktioniert von selbst), `PLAN.md` (0.1.16 + Lesson). ## Geprüft - 211 Tests grün (`python3 -m unittest discover -s tests`). - Live auf dem Mac: `pd_eigener.eigener_server()` → `https://192.168.178.94:3300`, `erreichbar` = True (Admin-Basic über TLS mit der App-CA), `repos()` = `['iris-admin/iris-vault']` — der Picker-Pfad des Panels, exakt wie vom Panel aufgerufen. - `curl --cacert forgejo-tls/ca.crt` gegen den eigenen Forgejo: TLS-Verifizierung ok (OpenSSL 4 CLI); altes Passwort 401 / neues 200 auf beiden Hostnamen. ## Nicht geprüft - Ob das Panel im geöffneten Fenster jetzt grün zeigt (Nutzer-Blick; der zugrunde liegende Pfad ist live verifiziert). - Wer um 20:54 die Linux-Kopie auf den Mac gelegt hat (offen — beim Nutzer erfragt); ein erneutes Übertünchen der Datei würde den Fehler wiederholen. - Dass der iOS-Client nach dem 19:17er Zertifikats-Neuausstellung der App (CA neu, `forgejo-tls/`) weiter verbindet — das ist App-interne Sache und wurde nicht angefasst. - Der 18:59-UTC-Password-Reset auf dem **Linux**-Server (Secret-Store hatte die Schlüssel offenbar verloren) wurde nicht weiter rückverfolgt: Der Server ist intern konsistent (Datei = Secret-Store = DB nach jedem `ensure_setup`), und das Plugin liest die Datei je Aufruf, also selbstheilend. - **Öffentlichung** steht aus (nur auf ausdrückliches Wort); bis dahin ist 0.1.16 nur lokal installiert.
alf commented 2026-10-22 22:20:54 +00:00
Author
Owner
Copy link

PR #232 gemergt: fix(iris-plugin-dev): Picker-Feld-Ids angleichen, Repo-Liste paginieren (0.1.17, #224)
#232

Commits:

  • fix(iris-plugin-dev): Picker-Feld-Ids angleichen, Repo-Liste paginieren (0.1.17, #224)

Stand 0.1.17 (iris-plugin-dev)

Befund

Im Einstellungs-Fenster wirkte „Neues Repo anlegen“ tot, der Picker stand im Zustand „Anderes …“ mit der Konsolenmeldung „null is not an object (evaluating 'andere.value')“.
Wurzel: Die HTML-Felder heißen repoAndere/registryAndere, das JavaScript sprach sie aber als $(selectId + "Andere") → repoSelectAndere/registrySelectAndere = null an. Stand das Standard-Repo (iris/iris-plugins) nicht in der geladenen Liste, warf fuelleSelect auf andere.value = standard; der Knopf liest $(selectId + "Andere").value unbedingterweise → Fehler in der ersten Zeile des Handlers.
Auslöser-Szenario: der eigene Forgejo — eine frische Instanz hat nur iris-admin/iris-vault, damit stehen beide Standards im „Anderes …“-Zweig.

Geändert

  • web/settings.html: HTML-Ids an das JS-Muster angleichen (repoSelectAndere/registrySelectAndere, 4 Stellen); ladeRepos paginiert jetzt die gesamte Repository-Liste (ob_mehr/seite lagen seit 0.1.14 im Backend, das JS nutzte sie nicht).
  • tests/test_settings_html.py (neu): Alle $("…")-Referenzen und alle <select id>+Andere müssen ein Element treffen.
  • 0.1.17: plugin.json-Changelog, store/changelog.md, PLAN.md (Versionszeile + Lessons Learned).

Geprüft

  • 213 Tests OK (pinned Python 3.14.7).
  • Backend unter dem pinned Runtime auf dem Mac: status → eigener Forgejo https://192.168.178.94:3300 erreichbar (0,17 s), repos → ['iris-admin/iris-vault'] — exakt das Auslöser-Szenario.
  • Öffentliche Forgejo (konfigurierter Zugriff): 36 Repos, 1 Seite → die Paginierung bricht nach einem Request ab.
  • Installierte Kopie (Mac) synchronisiert: web/settings.html + plugin.json (0.1.17), Diff gegen das Repo leer.

Nicht geprüft

  • Das Panel im echten WebView (Nutzerseite): ob Picker und Knopf nach dem Neu-Öffnen fehlerfrei füllen/legen — dazu muss Alf das Fenster erneut öffnen.
  • Die Paginierung mit mehr als 50 Repos (keine Installation mit so vielen vorhanden).

Grenzen / Offen

  • Beim eigenen Forgejo existieren die Standards nicht: Der Picker zeigt „Anderes …“ mit dem Standard vorbelegt. Beim ersten „Neues Repo anlegen“-Klick lehnt das Backend den Slash-Namen (korrekterweise) mit „Ungültiger Reponame: ein Name ohne Slash …“ ab — ohne Slash eingeben (z. B. iris-plugins → entsteht iris-admin/iris-plugins).
  • Das Issue bleibt offen, bis Alf „Issue schließen“ sagt.
PR #232 gemergt: fix(iris-plugin-dev): Picker-Feld-Ids angleichen, Repo-Liste paginieren (0.1.17, #224) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/232 Commits: - fix(iris-plugin-dev): Picker-Feld-Ids angleichen, Repo-Liste paginieren (0.1.17, #224) --- # Stand 0.1.17 (iris-plugin-dev) ## Befund Im Einstellungs-Fenster wirkte „Neues Repo anlegen“ tot, der Picker stand im Zustand „Anderes …“ mit der Konsolenmeldung „null is not an object (evaluating 'andere.value')“. Wurzel: Die HTML-Felder heißen `repoAndere`/`registryAndere`, das JavaScript sprach sie aber als `$(selectId + "Andere")` → `repoSelectAndere`/`registrySelectAndere` = null an. Stand das Standard-Repo (`iris/iris-plugins`) nicht in der geladenen Liste, warf `fuelleSelect` auf `andere.value = standard`; der Knopf liest `$(selectId + "Andere").value` unbedingterweise → Fehler in der ersten Zeile des Handlers. Auslöser-Szenario: der eigene Forgejo — eine frische Instanz hat nur `iris-admin/iris-vault`, damit stehen beide Standards im „Anderes …“-Zweig. ## Geändert - `web/settings.html`: HTML-Ids an das JS-Muster angleichen (`repoSelectAndere`/`registrySelectAndere`, 4 Stellen); `ladeRepos` paginiert jetzt die gesamte Repository-Liste (`ob_mehr`/`seite` lagen seit 0.1.14 im Backend, das JS nutzte sie nicht). - `tests/test_settings_html.py` (neu): Alle `$("…")`-Referenzen und alle `<select id>+Andere` müssen ein Element treffen. - 0.1.17: `plugin.json`-Changelog, `store/changelog.md`, `PLAN.md` (Versionszeile + Lessons Learned). ## Geprüft - 213 Tests OK (pinned Python 3.14.7). - Backend unter dem pinned Runtime auf dem Mac: `status` → eigener Forgejo `https://192.168.178.94:3300` erreichbar (0,17 s), `repos` → `['iris-admin/iris-vault']` — exakt das Auslöser-Szenario. - Öffentliche Forgejo (konfigurierter Zugriff): 36 Repos, 1 Seite → die Paginierung bricht nach einem Request ab. - Installierte Kopie (Mac) synchronisiert: `web/settings.html` + `plugin.json` (0.1.17), Diff gegen das Repo leer. ## Nicht geprüft - Das Panel im echten WebView (Nutzerseite): ob Picker und Knopf nach dem Neu-Öffnen fehlerfrei füllen/legen — dazu muss Alf das Fenster erneut öffnen. - Die Paginierung mit mehr als 50 Repos (keine Installation mit so vielen vorhanden). ## Grenzen / Offen - Beim eigenen Forgejo existieren die Standards nicht: Der Picker zeigt „Anderes …“ mit dem Standard vorbelegt. Beim ersten „Neues Repo anlegen“-Klick lehnt das Backend den Slash-Namen (korrekterweise) mit „Ungültiger Reponame: ein Name ohne Slash …“ ab — ohne Slash eingeben (z. B. `iris-plugins` → entsteht `iris-admin/iris-plugins`). - Das Issue bleibt offen, bis Alf „Issue schließen“ sagt.
alf commented 2026-10-26 20:19:40 +00:00
Author
Owner
Copy link

PR #300 gemergt: fix(iris-plugin-dev): Tippfehler in der Status-Anzeige des Einstellungs-Fensters (0.1.18, #224)
#300

Commits:

  • fix(iris-plugin-dev): Tippfehler in der Status-Anzeige des Einstellungs-Fensters (0.1.18, #224)

Stand 0.1.18 — Fehler im Einstellungs-Fenster behoben

Befund (Meldung beim ersten Einsatz): „Eigener Forgejo eintragen“ tat nichts, „Speichern“ im manuellen Modus zeigte „Can't find variable: gespeicherterEigener“. Ursache: In web/settings.html (zeigeStatus) hieß die Variable gespeichertEigener, die Zeile danach schrieb gespeicherterEigener — ein Tippfehler seit 0.1.14. zeigeStatus läuft nach Laden, Speichern und „Eigener Forgejo eintragen“; es brach jedes Mal ab (die Server-Seite von „eintragen“ lief durch, nur die Anzeige danach brach).

Geändert: Variablenname korrigiert. Neuer Test StatusAnzeigeTests: führt das Skript der Seite in Node mit Attrappen-Oberfläche aus und ruft die Anzeige für drei Zustände auf (ohne eigenen Forgejo, gespeichert eigener, eigener verfügbar aber manuell). Mit dem alten Tippfehler ist er rot, mit der Korrektur grün. Version 0.1.18, Änderungstext, store/changelog.md, Lessons Learned in PLAN.md.

Geprüft: Gesamte Testsuite des Plugins (233 Tests) grün; Gegenprobe mit dem alten Fehler schlägt fehl.

Nicht geprüft: Das echte Fenster in Iris von Hand (Knöpfe „Eigener Forgejo eintragen“, „Speichern“, „Verbindung testen“) — Issue bleibt status/zu-testen. Der Test läuft nur, wo node installiert ist.

Offen: In deinem Screenshot meldet „Verbindung testen“ zusätzlich: „Rechte des Tokens: Das Token hat Admin-Rechte. Ein eigenes Token nur mit Repository- und Issue-Schreibrecht ist sicherer.“ Das ist ein Hinweis, kein Fehler — das gespeicherte Token ist zu mächtig, nicht kaputt.

PR #300 gemergt: fix(iris-plugin-dev): Tippfehler in der Status-Anzeige des Einstellungs-Fensters (0.1.18, #224) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/300 Commits: - fix(iris-plugin-dev): Tippfehler in der Status-Anzeige des Einstellungs-Fensters (0.1.18, #224) --- **Stand 0.1.18 — Fehler im Einstellungs-Fenster behoben** **Befund (Meldung beim ersten Einsatz):** „Eigener Forgejo eintragen“ tat nichts, „Speichern“ im manuellen Modus zeigte „Can't find variable: gespeicherterEigener“. Ursache: In `web/settings.html` (`zeigeStatus`) hieß die Variable `gespeichertEigener`, die Zeile danach schrieb `gespeicherterEigener` — ein Tippfehler seit 0.1.14. `zeigeStatus` läuft nach Laden, Speichern und „Eigener Forgejo eintragen“; es brach jedes Mal ab (die Server-Seite von „eintragen“ lief durch, nur die Anzeige danach brach). **Geändert:** Variablenname korrigiert. Neuer Test `StatusAnzeigeTests`: führt das Skript der Seite in Node mit Attrappen-Oberfläche aus und ruft die Anzeige für drei Zustände auf (ohne eigenen Forgejo, gespeichert eigener, eigener verfügbar aber manuell). Mit dem alten Tippfehler ist er rot, mit der Korrektur grün. Version 0.1.18, Änderungstext, `store/changelog.md`, Lessons Learned in `PLAN.md`. **Geprüft:** Gesamte Testsuite des Plugins (233 Tests) grün; Gegenprobe mit dem alten Fehler schlägt fehl. **Nicht geprüft:** Das echte Fenster in Iris von Hand (Knöpfe „Eigener Forgejo eintragen“, „Speichern“, „Verbindung testen“) — Issue bleibt `status/zu-testen`. Der Test läuft nur, wo `node` installiert ist. **Offen:** In deinem Screenshot meldet „Verbindung testen“ zusätzlich: „Rechte des Tokens: Das Token hat Admin-Rechte. Ein eigenes Token nur mit Repository- und Issue-Schreibrecht ist sicherer.“ Das ist ein Hinweis, kein Fehler — das gespeicherte Token ist zu mächtig, nicht kaputt.
alf commented 2026-10-26 20:19:52 +00:00
Author
Owner
Copy link

Veröffentlicht: Plugin „Plugins entwickeln“ (iris-plugin-dev) 0.1.18

  • Was draußen ist: Version 0.1.18 in der Registry (plugin-registry, nach dem Pull geprüft); Paket packages/iris-plugin-dev/iris-plugin-dev-0.1.18.irisplugin.
  • Was Nutzer bekommen: Das Einstellungs-Fenster funktioniert wieder — „Eigener Forgejo eintragen“ und „Speichern“ brachen seit 0.1.14 an einem falsch geschriebenen Variablennamen ab.
  • Offen: Von Hand im echten Fenster nicht ausprobiert (bleibt status/zu-testen). Der Hinweis „Token hat Admin-Rechte“ im Verbindungstest ist eine Warnung, kein Fehler.
**Veröffentlicht: Plugin „Plugins entwickeln“ (`iris-plugin-dev`) 0.1.18** - Was draußen ist: Version 0.1.18 in der Registry (`plugin-registry`, nach dem Pull geprüft); Paket `packages/iris-plugin-dev/iris-plugin-dev-0.1.18.irisplugin`. - Was Nutzer bekommen: Das Einstellungs-Fenster funktioniert wieder — „Eigener Forgejo eintragen“ und „Speichern“ brachen seit 0.1.14 an einem falsch geschriebenen Variablennamen ab. - Offen: Von Hand im echten Fenster nicht ausprobiert (bleibt `status/zu-testen`). Der Hinweis „Token hat Admin-Rechte“ im Verbindungstest ist eine Warnung, kein Fehler.
alf closed this issue 2026-10-27 10:47:18 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
  
herkunft/alpha-feedback
Aus Rückmeldungen der Alpha-Tester

  
status
blockiert
 Wartet auf etwas anderes

  
status
zu-testen
 Gebaut, aber noch nicht im echten Einsatz geprüft

  
typ
bug
 Fehler

  
typ
docs
 Dokumentation

  
typ
enhancement
 Verbesserung einer vorhandenen Funktion

  
typ
feature
 Neue Funktion

  
typ
idea
 Idee, noch nicht entschieden

No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
iris/iris-plugins#224
No description provided.