Die API hat eine Direktnachricht an einen anderen als den in `recipient`
genannten Benutzer zugestellt, obwohl die ID über /user verifiziert war.
Welche Kennung sie wirklich erwartet, ist ungeklärt — und löschen lässt
sich eine Fehlzustellung nicht: DELETE /mail/<id> gibt es in dieser
Version nicht, über die Oberfläche kommt man auch nicht dran.
Deshalb drei Änderungen:
- mail-send sendet nur noch mit --send; ohne das Flag löst es den
Empfänger auf und zeigt Namen und ID.
- Nach dem Versand wird die Teilnehmerliste gelesen und gemeldet, wer die
Konversation tatsächlich bekommen hat.
- mail-user-remove nimmt einen Teilnehmer wieder heraus
(DELETE /mail/<id>/user/<userid>) — das einzige Gegenmittel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ohne Versionssprung zieht 'claude plugin marketplace update' den Fix
nicht als neue Fassung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
POST /mail nimmt als recipient ausschliesslich GUIDs an. Mit numerischen
User-IDs antwortet die API "400 Validation failed" und "Du kannst keine
Nachricht ohne Empfaenger senden!" - eine Meldung, die nach einem leeren
Feld klingt, obwohl das Feld gefuellt ist.
resolve_user gibt deshalb die GUID zurueck statt der ID; user_guid holt
sie ueber /user/<id> nach, wenn die Benutzerliste sie nicht mitliefert.
Geprueft gegen humhub.inmedias.it mit Benutzername, Profil-URL und
numerischer ID; der Versand mit GUID ist belegt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
wiki.py mit dokumentierer/wiki.py synchronisiert (purge-Subcommand).
SKILL.md: purge und das bisher undokumentierte upload in die
Befehlsliste, dazu ein Abschnitt zu Seiten mit #get_web_data. Die
Vorlagen werden nicht bei jedem Aufruf ausgefuehrt; wer nach einer
Datenaenderung render aufruft und alte Werte sieht, hat meist den Cache
vor sich und nicht kaputte Daten.
description um den Fall erweitert, damit die Skill bei "Wiki zeigt
veraltete Daten" gefunden wird. version 0.1.0 -> 0.2.0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Übernimmt den Stand aus inmedias.it/dokumentierer (7097383). Beide
Fassungen waren bis hierhin byte-identisch und sollen es bleiben.
`news` liest, legt an und ändert; `versions` listet und legt an,
`create`/`update` nehmen `--version`.
Der Hinweis in SKILL.md, Versionen seien "über redmine.py nicht
abgedeckt", stimmt damit nicht mehr und ist ersetzt - durch zwei
Eigenheiten, die beim Anlegen des Projekts devops aufgefallen sind:
Redmine begrenzt News-Titel auf 60 Zeichen (sonst HTTP 422), und die
Priorität eines Elterntickets wird aus den Unteraufgaben abgeleitet,
überschreibt also einen von Hand gesetzten Wert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mail-send legt immer eine neue Konversation an; fuer eine Antwort braucht es
POST /mail/<id>/entry. Die ID steht in der URL der Konversation.
Holt den Verlauf nicht ab, sondern prueft nur die Erreichbarkeit — fremde
Nachrichten gehoeren nicht ungefragt in einen Modellkontext.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die REST-API kann das Mail-Modul, das Skill bisher nicht — Direktnachrichten
mussten von Hand in der Weboberflaeche geschrieben werden.
Der Stolperstein ist die Empfaengeraufloesung: Profil-Slug und Benutzername
sind nicht dasselbe (zu /u/serge/ gehoert "Serge"), und get-by-username
unterscheidet Gross-/Kleinschreibung. resolve_user() nimmt deshalb ID,
Benutzername oder Profil-URL und faellt auf einen Durchlauf der Benutzerliste
zurueck, der beides case-insensitive vergleicht.
Kein Befehl zum Lesen von Konversationen: fremde Nachrichten gehoeren nicht
ungefragt in einen Modellkontext.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Polls-REST-API ist auf der Instanz aktiv, der Skill kannte sie nicht.
Zwei Abweichungen vom Muster der Post-API, die beide in
HTTP 500 'Internal error while save a poll!' enden:
* Der Controller macht $poll->load(Yii::$app->request->post()) — die Felder
gehoeren unter den Yii-Formnamen 'Poll', nicht unter 'data'.
* Die Optionen heissen beim Anlegen 'newAnswers'; 'answers' ist die Leseform
und wird beim POST ignoriert.
Beim Lesen ist limit Pflicht: ohne Begrenzung antwortet die Instanz ab etwa
25 Umfragen ebenfalls mit 500.
Quelle: humhub/polls, controllers/rest/PollsController.php + models/Poll.php.
Verifiziert an Space inmedias (Umfrage 36).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Self-contained redmine.py (me/projects/issues/show/create/update/comment/
meta) mit Namensaufloesung (Projekt/Tracker/Status/Prioritaet). SKILL.md,
plugin.json, Beispiel-Konfig; Eintrag in marketplace.json und README.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Neues Skill-Plugin, das Texte nach den Leitprinzipien der ISO 24495-1:2023
(Plain Language) schreibt/überarbeitet: zielgruppen- und prozessorientiert
(finden – verstehen – nutzen). Im marketplace.json registriert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Das Repo ist inzwischen oeffentlich lesbar; `/plugin marketplace add` klont
direkt ueber HTTPS. Die insteadOf-Umleitung auf SSH ist dafuer nicht mehr
noetig und steht jetzt nur noch als Rueckfallweg fuer den Fall, dass das Repo
wieder privat gestellt wird.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- fetch <content-id|perma-url> [--save]: löst Perma-Links selbst auf
- space-list + resolve_container: container_id akzeptiert Slug/URL/ID
- SKILL.md entsprechend ergänzt
Gleicht das Plugin an die kanonische humhub.py (dokumentierer) an.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Neues Plugin, das MediaWiki-Seiten/Templates ueber die gevendorte, self-
contained wiki.py (uv run --script; mwclient+python-dotenv) liest, rendert und
schreibt. Instanzen wiki (Prod) und devwiki via -w. Zugangsdaten bleiben lokal
(Umgebungsvariablen bzw. dotenv-Datei) - Beispiel-Vorlage beiliegend. SKILL.md
dokumentiert Nutzung + Regel "Wiki nur via wiki.py/MCP, nicht Maintenance-Skript".
Marketplace-Eintrag ergaenzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>