Ja, ich finde es besser, dies zumindest für Version 1 dieses Featuresatzes explizit zu gestalten. Ich bin bisher keinem Anwendungsfall begegnet, bei dem eine automatische Erstellung wirklich erforderlich gewesen wäre, d. h. die Gruppe hätte einfach vom Site-Administrator vor der Bearbeitung beliebiger Ansprüche eingerichtet und konfiguriert werden können.
Vielleicht könnten wir nach der Umsetzung der expliziten Version eine automatische Erstellung als Option einführen?
Im Hinblick auf die Gruppeneinstellungen könnte dies wie folgt aussehen:
Einstellungsabschnitt: Mitgliedschaft (d. h. der bestehende Abschnitt)
Titel der Einstellungsgruppe: Authentifizierungsverwaltung
Einstellungen:
- Dienst: Liste der Authentifizierungsdienste. „Alle“ wäre eine Option. Diese Einstellung würde auch als „aktiviert/deaktiviert“-Status für diesen Featuresatz fungieren. D. h. der Standardwert wäre „Keine“.
- Anspruch: Texteingabe zur Identifizierung des ID-Token-Anspruchs. Die „Beschreibung“ für dieses Feature (vielleicht in einem Beitrag hier auf Meta) würde die unterstützten Formate erläutern, z. B. boolescher Wert, durch Kommas getrennte Zeichenfolge usw.
- Modus: siehe unten
Ja, wenn es eine Einstellung für „streng/umfassend“ gäbe, müssten wir sie prägnant erklären. Ich denke, der richtige Ansatz wäre, sich auf „Hinzufügen“ und „Entfernen“ zu konzentrieren. Man könnte es vielleicht so beschreiben:
Einstellung: „Modus"
Option 1 (umfassend):
- Beschriftung: „Mitglieder hinzufügen"
- Beschreibung: „Ermöglicht das Hinzufügen von Mitgliedern zu dieser Gruppe bei der Authentifizierung"
Option 2 (streng):
- Beschriftung: „Mitglieder hinzufügen und entfernen"
- Beschreibung: „Ermöglicht das Hinzufügen und Entfernen von Mitgliedern bei der Authentifizierung. Dadurch werden manuelle Mitgliedschaftskontrollen deaktiviert."
Der Grund, warum ich daran interessiert bin, die Option „umfassend“ beizubehalten, ist, dass dies bei der Arbeit mit Kunden in dieser Hinsicht in der Vergangenheit der häufigste Anwendungsfall war, d. h.:
-
Der Hauptbedarf besteht darin, den Zugriff auf eine Gruppe abhängig von einem Status in einem externen Dienst zu ermöglichen.
-
Die Notwendigkeit, den Zugriff abhängig vom Status im externen Dienst zu entfernen, ist eher nebensächlich, d. h. Menschen verlieren zwar den Zugriff und sollten entfernt werden, aber dies ist relativ weniger wichtig.
-
Oft besteht der Wunsch, die Möglichkeit zur manuellen Steuerung der Mitgliedschaft in Discourse beizubehalten. Wenn ich den „strengen“ Ansatz implementiert habe, war dies „überraschend“ (d. h. „Warum hat Person X die Mitgliedschaft verloren?“), trotz Erklärungen und obwohl es (technisch) wie vorgesehen funktionierte.
Ja, das ist wichtig, da sich Leute oft fragen werden, „warum“ jemand hinzugefügt oder entfernt wurde, insbesondere im strengen Modus, und wir (d. h. „Discourse") keine Kontrolle über die Richtigkeit der Ansprüche haben, die der externe Authentifizierungsdienst stellt.
Vielleicht eine neue Art von Aktion „Benutzer entfernen“ und „Benutzer hinzufügen“, die den für die Aktion zuständigen Authentifizierungsdienst enthält, d. h. „Benutzer entfernen ([Dienstname])“.