jhsandClaude Opus 5
2bfc62bcb8
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>
5.4 KiB
name, description, version
| name | description | version |
|---|---|---|
| humhub | HumHub Wiki-Seiten, Posts und Umfragen lesen/erstellen/aktualisieren via REST-API. Use when the user mentions "HumHub", "Space", "Wiki-Seite in HumHub", "Post/Beitrag" or "Umfrage/Poll". | 0.2.0 |
HumHub (humhub.py)
Interagiert mit HumHub (https://humhub.inmedias.it) über die REST-API:
Wiki-Seiten, Posts und Umfragen auflisten, anzeigen, anlegen und aktualisieren — über die
mitgelieferte, self-contained humhub.py.
Ausführen
humhub.py ist ein eigenständiges uv run --script (Inline-Deps: requests,
python-dotenv). Aus dem Skill-Verzeichnis:
./humhub.py <befehl> ...
Perma-Link / Content-ID holen (empfohlener Einstieg)
HumHub-Links der Form …/content/perma?id=NNNN tragen eine Content-ID — nicht
die Wiki-Seiten- oder Post-ID, die die anderen Befehle erwarten. fetch löst das
selbst auf (erkennt WikiPage vs. Post) und braucht keine Vorab-Recherche:
./humhub.py fetch <content-id|perma-url> # Inhalt + Herkunfts-Kopf auf stdout
./humhub.py fetch <content-id|perma-url> --save # ablegen unter resources/humhub-<id>-<slug>.md
./humhub.py fetch <content-id|perma-url> --save --out <dir>
--save schreibt Markdown mit einem Herkunfts-Kopf (Quelle, Titel, Typ, Topics,
Stand, Abrufdatum). Zielverzeichnis ist standardmäßig resources/ im aktuellen
Projekt — dieses gehört üblicherweise in .gitignore (abgerufene Fremdinhalte
werden nicht committet).
Spaces
./humhub.py space-list # Spaces auflisten mit contentcontainer_id
Wiki
./humhub.py wiki-list ["filter"] # Wiki-Seiten auflisten (Titel-Filter optional)
./humhub.py wiki-get <id> # Wiki-Seite anzeigen (Inhalt + URL)
./humhub.py wiki-update <id> [datei|-] [--title ...] [--topics a,b] [--parent-id N]
./humhub.py wiki-create <container_id> "<titel>" [datei|-] [--topics a,b] [--parent-id N]
Posts
./humhub.py post-list <container_id> [--limit N]
./humhub.py post-create <container_id> [datei|-]
./humhub.py post-update <id> [datei|-]
Umfragen
./humhub.py poll-list <container_id> [--limit N]
./humhub.py poll-create <container_id> "<frage>" --answers "A|B|C" \
[--file beschreibung.md] [--anonymous] [--multiple] [--hide-results]
Antwortoptionen mit | trennen, mindestens zwei. Der Beschreibungstext kommt
wie überall aus einer Datei oder -; Markdown ist erlaubt. Ohne --anonymous
ist sichtbar, wer wie gestimmt hat — bei Anmeldungen mit begrenzten Plätzen ist
das der Sinn der Sache.
Zwei Eigenheiten der Polls-API, die zu HTTP 500 "Internal error while save a poll!" führen, wenn man dem Muster der Post-API folgt: die Felder gehören
unter den Yii-Formnamen Poll (nicht data), und die Optionen heißen beim
Anlegen newAnswers (beim Lesen answers). Beim Lesen ist limit Pflicht
und nicht Komfort — ohne Begrenzung antwortet die Instanz ab ~25 Umfragen
ebenfalls mit 500. Ein fehlgeschlagener POST legt nichts an; vor einem zweiten
Versuch trotzdem mit poll-list prüfen.
Kommentare
./humhub.py comment-list <content-id|perma-url> # Kommentare eines Inhalts
./humhub.py comment-create <content-id|perma-url> [datei|-] # Kommentar schreiben
Beide nehmen wie fetch eine Content-ID oder Perma-URL (nicht die Post-/
Wiki-Seiten-ID) und lösen das Zielobjekt selbst auf — funktioniert für Posts
und Wiki-Seiten.
Direktnachrichten
./humhub.py mail-send <empfaenger> "<betreff>" [datei|-]
./humhub.py mail-send https://humhub.inmedias.it/u/serge/ "Betreff" entwurf.md
./humhub.py mail-send jan.stobbe,26 "Betreff" -
./humhub.py mail-reply <konversations-id> [datei|-]
Empfänger sind Benutzername, Profil-URL oder numerische ID; mehrere mit Komma.
mail-reply hängt einen Beitrag an eine bestehende Konversation
(POST /mail/<id>/entry). Die ID steht in der URL der Konversation:
…/mail/mail/index?id=35.
Slug ≠ Benutzername. Zur Profil-URL /u/serge/ gehört der Benutzername
Serge, und get-by-username unterscheidet Groß-/Kleinschreibung. Wer den
Slug einsetzt, bekommt sonst User not found!. mail-send fängt das ab: erst
get-by-username, dann ein Durchlauf der Benutzerliste, der Benutzername und
Slug ohne Rücksicht auf Groß-/Kleinschreibung vergleicht.
Zum Lesen von Konversationen gibt es bewusst keinen Befehl — Nachrichten
anderer gehören nicht ungefragt in einen Modellkontext. Auch mail-reply
holt den Verlauf nicht ab, sondern prüft nur, ob die Konversation erreichbar
ist.
Inhalte (Markdown) aus Datei oder - (stdin) übergeben — nicht als langes
Shell-Argument (Sonderzeichen). container_id akzeptiert eine numerische
Container-ID, einen Space-Slug oder eine Space-URL (resolve_container
löst Slug/URL selbst auf). Passende Container per space-list ermitteln, Seiten
per wiki-list / post-list.
Zugangsdaten
humhub.py bringt keinen Token mit. Jede/r hinterlegt ein eigenes
API-Token als Umgebungsvariable oder in einer dotenv-Datei (Reihenfolge:
~/.config/dokumentierer/.env, dann Datei im Arbeitsverzeichnis, dann bereits
gesetzte Env-Variablen). Siehe .env.example:
HUMHUB_API_TOKEN— REST-API-Token. Nur als berechtigter Benutzer erhältlich unter https://humhub.inmedias.it/rest/admin/index
Die Basis-URL (https://humhub.inmedias.it/api/v1) ist fest im Skript; für eine
andere Instanz BASE_URL oben in humhub.py anpassen.