Sim, acho que é melhor ser explícito, pelo menos na v1 deste conjunto de recursos. Ainda não encontrei nenhum caso de uso em que a criação automática tenha sido realmente necessária, ou seja, o grupo poderia simplesmente ser configurado e gerenciado pelo administrador do site antes de qualquer reivindicação ser processada.
Talvez pudéssemos migrar para a criação automática como uma opção após implementarmos a versão explícita?
Em termos de Configurações de Grupo, seria algo como:
Seção de Configurações: Membros (ou seja, a seção existente)
Título do Grupo de Configurações: Gerenciamento de Autenticação
Configurações:
- Serviço: Lista de serviços de autenticação. “Todos” seria uma opção. Essa configuração também funcionaria como um estado “habilitado / desabilitado” para este conjunto de recursos. Ou seja, o padrão seria “Nenhum”.
- Reivindicação: campo de texto para identificar a reivindicação do token de ID. A “descrição” para esse recurso (talvez em um post aqui no meta) explicaria os formatos suportados, como booleano, string delimitada por vírgula, etc.
- Modo: ver abaixo
Sim, se houvesse uma configuração estrita/permitida, teríamos que explicá-la de forma concisa. Acho que a maneira de abordar isso seria focar em “adição” e “remoção”. Você poderia descrever algo assim:
Configuração: “Modo”
Opção 1 (permitida):
- Rótulo: “Adicionar Membros”
- Descrição: “Permitir que membros sejam adicionados a este grupo durante a autenticação”
Opção 2 (estrita):
- Rótulo: “Adicionar e Remover Membros”
- Descrição: “Permitir que membros sejam adicionados e removidos durante a autenticação. Isso desabilitará os controles manuais de associação.”
A razão pela qual estou ansioso para manter a opção “permitida” é que, ao trabalhar com clientes nesse tipo de coisa anteriormente, esse é o caso de uso mais comum, ou seja:
-
A principal necessidade é permitir o acesso a um grupo dependendo de um estado em um serviço externo
-
A necessidade de remover o acesso dependendo do estado no serviço externo é mais marginal, ou seja, as pessoas perdem o acesso e devem ser removidas, mas isso é relativamente menos importante
-
Frequentemente há o desejo de manter a capacidade de controlar manualmente a associação no Discourse. Quando implementei a abordagem “estrita”, isso foi “surpreendente” (ou seja, “Por que a pessoa X perdeu a associação?”) apesar das explicações e do funcionamento (tecnicamente) como deveria.
Sim, isso é importante, pois as pessoas frequentemente se perguntarão “por que” alguém foi adicionado ou removido, especialmente no modo estrito, e nós (ou seja, “Discourse”) não teremos controle sobre a veracidade das reivindicações feitas pelo serviço de autenticação externo.
Talvez um novo tipo de ação “Remover Usuário” e “Adicionar Usuário” que inclua o serviço de autenticação responsável pela ação, ou seja, “Remover Usuário ([nome do serviço])”.