[Dev] Verständnisprobleme (?) bei Nutzung der API

Hallo zusammen :slight_smile:

ich versuche gerade, für unsere Schule das Anlegen von Talk-Räumen zu automatisieren.
Zunächst habe ich versucht, das über Bash-Skripte und occ talk:room Befehle zu realisieren.
Das klappt im Ansatz auch, aber so richtig cool sind die Skripte nicht, weil ich es nicht hinbekomme, den Status-Quo auszulesen.
Beispiel: Die Zusammensetzung der Gruppen hat sich geändert, es muss ein User aus dem Raum entfernt werden und ein anderer rein.
Rein geht gut, weil ich einfach die Gruppe hinzufüge und occ sich um den Rest kümmert, aber ich bekomme nicht ausgelesen, wer momentan drin ist.

Also habe ich versucht mit der API zu arbeiten.
Ich habe mittlerweile auch verstanden, wie ich mit curl auf diese API zugreifen kann, aber ich bekomme auch hier nicht die Informationen, die ich gerne hätte.
Die Frage ist jetzt, ob ich das einfach noch nicht tief genug durchdrungen habe, oder ob das schlicht nicht geht:

Kann ich über die API (angemeldet über ein APP-Passwort des Users “admin”) herausfinden:

  • welche Gruppenunterhaltungen gibt es derzeit
  • wer ist Teilnehmer dieser Unterhaltungen
  • wer ist Moderator in diesen Unterhaltungen

Mit dem Aufruf

TOKEN="<Token des gewünschten Calls>"
NC_URL="https://meine_nextcloud"
API_BASE="/ocs/v2.php/apps/spreed/api/v4"
API_CALL="/room/${TOKEN}/participants"

curl -u admin:$PASSWORD -X GET "${NC_URL}${API_BASE}${API_CALL}" -H "OCS-APIRequest: true" -H "Accept: application/json"

bekomme ich zum Beispiel nur irgendwelche Infos, wenn der Nutzer “admin” auch in der Unterhaltung Mitglied ist.

Wer kann mir helfen, API-Aufrufe zu finden, der die o.g. Fragen beantworten kann?

Herzliche Grüße
Jesko

Hallo.

Nur damit wir nicht aneinander vorbei reden: Es geht also darum, dass es bestimmte Räume in der spreed App gibt, die im Vorfeld (manuell) erstellt wurden. Jetzt sollen die eingeladenen Personen/Nutzer mit einer externen DB (o.ä.) synchronisiert werden. Korrekt so weit?

Grundsätzlich wirst du einen Moderator brauchen, also einen Nutzer, der in der Lage ist auch andere Nutzer in den Raum einzuladen und auch raus zu kicken. Spricht etwas dagegen, einen “Systemuser” anzulegen, der nur diese Aufgabe hat? Der müsste dann halt in alle Gruppen aufgenommen werden und sinnvollerweise auch keine Benachrichtigungen bekommen :wink:.

Ansonsten kann man mal die Quellen der möglichen Routen anschauen. Da sind alle möglichen Endpunkte definiert. Daraus müsste man ableiten (können), ob der gewünschte Effekt mit API-Aufrufen möglich ist oder nicht.

Hi :slight_smile:

Nicht ganz: Ich möchte erreichen, dass am Ende des Prozesses bestimmte Räume existieren, in denen genau die Personen teilnehmer sind, die in einer (system)-Gruppe Mitglieder sind.

Beispiel: es gibt im AD (und über die LDAP-Kopplung der Nextcloud auch dort) die Gruppe p_fsit. Dort sind 5 Benutzer drin.
Das Skript legt jetzt einen Raum an: FS-IT und trägt dort alle Nutzer aus der Gruppe p_fsit ein.
Außerdem wird ein Nutzer zum Moderator befördert.

Um die Zuordnung hinzubekommen, arbeitet das Skript eine Datei ab, mit dem Inhalt:
Raumname;Mitgliedergruppe;Moderator
also obiges Beispiel (az bin ich):
FS-IT;p_fsit;az

Das klappt auch alles schon (auch ohne “Systemuser”)
Was nicht klappt ist:

  1. Bei Änderungen in der Gruppe p_fsit werden zwar Nutzer hinzugefügt, die vorher nicht drin waren, aber Nutzer, die nicht mehr drin sind, werden nicht gelöscht.
  2. Bei jedem Skriptaufruf wird az neu promoted, so dass der Raum mit unnötigen Meldungen geflutet wird, dass az vom Admin zum Moderator gemacht wurde.

Jetzt würde ich die Skripte jeweils erweitern wollen, so dass sie nur dann den User az promoten, wenn der noch kein Moderator ist UND User demoten, die Moderatoren sind, aber nicht az heißen :slight_smile:

Außerdem wollte ich eine aktuelle Nutzerliste des Raumes mit dem Inhalt von p_fsit abgleichen, um nicht mehr berechtigte Personen zu entfernen.

Ich hatte gehofft, das ginge irgendwie.
Möglicherweise ist deine Idee, einen Systemuser als Moderator in alle Räume einzutragen eine Möglichkeit, das Problem zu umgehen (auch wenn ich es nicht sooo schön finde, wenn da ein User auftaucht, der da eigentlich nicht hingehört).

Falls du nach meinen Ausführungen noch eine bessere Idee hast, gerne :slight_smile:
ansonsten versuch ich mich mal an dem Systemuser.

VG Jesko

Mit der Ausführung wird es für mich zumindest ein wenig klarer, was da gewünscht ist an Verhalten.

Aus dem Bauch heraus würde ich schätzen, dass es schwierig werden könnte, das so hin zu bekommen mittels reiner API-Aufrufe, sofern kein Systemuser eingesetzt wird.

Eine andere Idee (wenn auch potentiell nicht unbedingt einfacher) wäre mal zu schauen, ob es eien Möglichkeit geben könnte, das mittels der entsprechenden PHP-Methoden zu realisieren. Dann könnte man eine kleine App schreiben (also eine NC-App), die die genannte Datei parst und die Nutzer an den entsprechenden Stellen rein/raus bringt und dann auch die Moderationsrechte prüft/anpasst.
Ich gesehe aber, dass das nur aus der Hüfte geschossen war und daher keine Garantie vorhanden ist, dass das auch so klappen würde.

1 Like

Danke mal für den Input. Es kristallisiert sich raus, dass es mit den zur Verfügung stehenden Mitteln nicht so leicht möglich ist, mein Ziel zu erreichen.
Ich verschiebe das mal auf später und dann mal sehen, ob vielleicht eine Kombination aus occ Befehlen und API-Aufrufen mit Hilfe eines Systemusers in allen Räumen eine Option ist…

Grüße Jesko