Sí, creo que es mejor ser explícito, al menos en la versión 1 de este conjunto de funciones. Hasta ahora no he encontrado ningún caso de uso donde la creación automática haya sido realmente necesaria, es decir, donde el grupo no pudiera simplemente configurarse y ser gestionado por el administrador del sitio antes de que se procesara cualquier reclamación.
¿Quizás podríamos pasar a la creación automática como una opción después de implementar la versión explícita?
En cuanto a la Configuración de Grupos, sería algo así:
Sección de Configuración: Membresía (es decir, la sección existente)
Título del Grupo de Configuración: Gestión de Autenticación
Configuraciones:
- Servicio: Lista de servicios de autenticación. “Todos” sería una opción. Esta configuración también funcionaría como un estado “habilitado / deshabilitado” para este conjunto de funciones. Es decir, el valor predeterminado sería “Ninguno”.
- Reclamación (Claim): campo de texto para identificar la reclamación del token de ID. La “descripción” de esta función (quizás en una publicación aquí en meta) explicaría los formatos compatibles, por ejemplo, booleano, cadena delimitada por comas, etc.
- Modo: ver más abajo
Sí, si hubiera una configuración de estricto / permisivo, tendríamos que explicarla de forma concisa. Creo que la mejor manera de abordarlo sería centrarse en la “adición” y la “eliminación”. Podríamos describirlo de la siguiente manera:
Configuración: “Modo”
Opción 1 (permisivo):
- Etiqueta: “Agregar miembros”
- Descripción: “Permitir que se agreguen miembros a este grupo durante la autenticación”
Opción 2 (estricto):
- Etiqueta: “Agregar y eliminar miembros”
- Descripción: “Permitir que los miembros se agreguen y eliminen durante la autenticación. Esto deshabilitará los controles manuales de membresía.”
La razón por la que me interesa mantener la opción “permisiva” es que, al trabajar anteriormente con clientes en este tipo de cosas, ese es el caso de uso más común, es decir:
-
La necesidad principal es permitir el acceso a un grupo dependiendo de un estado en un servicio externo.
-
La necesidad de eliminar el acceso dependiendo del estado en el servicio externo es más marginal; es decir, las personas pierden acceso y deberían ser eliminadas, pero esto es relativamente menos importante.
-
A menudo existe el deseo de conservar la capacidad de controlar manualmente la membresía en Discourse. Cuando he implementado el enfoque “estricto”, esto ha resultado “sorprendente” (es decir, “¿Por qué la persona X perdió la membresía?”) a pesar de las explicaciones y de que funcionara (técnicamente) como debería.
Sí, esto es importante, ya que a menudo la gente se preguntará “por qué” alguien fue agregado o eliminado, especialmente en modo estricto, y nosotros (es decir, “Discourse”) no tendremos control sobre la veracidad de las reclamaciones que hace el servicio de autenticación externo.
Quizás un nuevo tipo de acción “Eliminar usuario” y “Agregar usuario” que incluya el servicio de autenticación responsable de la acción, es decir, “Eliminar usuario ([nombre del servicio])”.