Private, gruppenspezifische Veranstaltungen

Aktuell sind Event-Einträge immer Teil des Kalenders-UI-Elements, das einer Kategorie hinzugefügt werden kann. Es gibt keine Möglichkeit, ein Event auf eine bestimmte Benutzergruppe zu beschränken. Wenn Sie ein Discourse-Setup mit mehreren Communities betreiben, sehen alle Communities alle Events aller anderen Communities. Wenn Sie die Discourse-Events extern auf einer Website über einen API-Aufruf wie

https://example.discourse.org/discourse-post-event/events.ics?user_api_key=[xxxxx]

anzeigen, werden ALLE Events angezeigt.

Es sollte eine Option geben, „interne“ Events zu erstellen, die nur innerhalb einer Benutzergruppe angezeigt werden. Diese Events sollten nicht über die „allgemeine“ ICS-API-Anfrage lesbar sein. Stattdessen sollten sie nur mit einem speziellen, zusätzlichen „Gruppen-API-Schlüssel“ oder einer anderen Art von sicheren Einschränkungen verfügbar sein. Der Anwendungsfall besteht in der Auswahl zwischen „öffentlichen“ Events und Events, die „privat“ sind und nur innerhalb einer bestimmten Benutzergruppe sichtbar und bearbeitbar sind.

1 „Gefällt mir“

Würde es in deinem Fall funktionieren, einen Benutzer zu erstellen, der nur der benötigten Gruppe zugeordnet ist, und die Kalender-Abonnement-URL aus den Einstellungen dieses Benutzers zu generieren? Der Feed würde dann nur die Ereignisse enthalten, die dieser Benutzer sehen kann.

1 „Gefällt mir“

Hmmm, da bin ich mir nicht sicher. Klingt nach einem Workaround, aber nicht wirklich nach einer “Lösung” :smiling_face_with_sunglasses:

Alle Personen in einer Community-spezifischen Gruppe sollten in der Lage sein, Events zu erstellen. Und sie sollten diese auch sehen, wenn sie in die Kategorie “ihrer” Community wechseln. Das funktioniert in unserem aktuellen Setup mit 5 verschiedenen Communities bereits einwandfrei. Wir verwenden folgende Kategorierechte:

  1. eine Kategorie pro Community-Gruppe. Diese hat “global read only” und “community read/create/reply”. Diese Kategorie wird über AP federiert, damit auch Personen ohne Discourse-Konto Events sehen können und damit die Integration des Discourse-Kalenders in Drittsystemen (z. B. WordPress mit ICS-Plugin) möglich ist.
  2. eine variable Anzahl interner Unterkategorien. Diese Unterkategorien haben nur die Rechte “community read/create/reply”. Sie sind ohne die entsprechenden Gruppenrechte unsichtbar.

Die einzigen Lücken sind:

  1. Die aktuelle ics-Anfrage liefert ALLE Events zurück.
  2. Es gibt keinen Weg, nur die Events einer bestimmten Community über ICS/API anzufordern.

Alle Termine, oder alle Termine, auf die der Benutzer, dessen API-Schlüssel verwendet wird, Zugriff hat?

Wie stellst du dir den Prozess vor, bei dem ausgewählt wird, welche Termine in die jeweilige Anfrage aufgenommen werden sollen?

Guter Punkt.

Für API-Schlüssel gibt es zwei Benutzerstufen: „Einzelner Benutzer“ oder „Alle Benutzer“. Die API-Schlüssel, die wir derzeit für die ICS-Anfrage verwenden, haben die Stufe „Alle Benutzer“.

Um dies zu lösen, bräuchten wir wahrscheinlich API-Schlüssel der Stufe „Einzelner Benutzer“. Und der ausgewählte Benutzer sollte nur die Berechtigungsgruppe „Communities“ haben, nichts anderes.

Ich schaue mir das an. Vielleicht könnte das das Problem lösen ….

1 „Gefällt mir“

Einige Testergebnisse:

  • API-Schlüssel mit dem Benutzerlevel „single user“ erstellt
  • Ich habe zunächst die Bereichseinstellungen „granular“ geprüft, konnte aber keine Einschränkung für die „events“-Endpunkte finden. Obwohl „events“ als Abfragegruppe unter Discourse API Docs aufgeführt ist
  • Ich habe stattdessen „read only“ verwendet. Ergebnis: „You are not authorised to view the requested resource.“

curl -kv https://xxx/discourse-post-event/events.ics?user_api_key=xxx liefert keine ics-Datei, wenn ein „single user“-API-Schlüssel verwendet wird. Bei einem Benutzerlevel von „all users“ wird jedoch eine vollständige Liste der Ereignisse zurückgegeben. Ich sehe keinen Weg, wie man „filtern“ kann, um nur die Ereignisse einer bestimmten Benutzergruppe abzurufen.

Ich habe auch unter https:[xxxx]/admin/plugins/discourse-events/settings nach möglicherweise fehlerhaften API-bezogenen Einstellungen gesucht – ohne Ergebnis.

Hat jemand einen Kommentar dazu?