'(0.0.0.0 und ::)' wurde in einem Schraubraum-Post zu einem Smiley.
IPv6-Adressen, Ports und Pfade vor Klammern in Backticks setzen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
- 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>
skoandClaude Opus 5.5
jhsandClaude Opus 5