Sì, penso che sia meglio essere espliciti, almeno per la versione 1 di questa serie di funzionalità. Non ho ancora incontrato un caso d’uso in cui la creazione automatica fosse realmente necessaria, ovvero in cui il gruppo non potesse semplicemente essere configurato dall’amministratore del sito prima di gestire qualsiasi rivendicazione.
Forse potremmo passare alla creazione automatica come opzione dopo aver implementato la versione esplicita?
Per quanto riguarda le Impostazioni del Gruppo, sarebbe qualcosa del genere:
Sezione Impostazioni: Membri (ovvero la sezione esistente)
Titolo del Gruppo di Impostazioni: Gestione Autenticazione
Impostazioni:
- Servizio: Elenco dei servizi di autenticazione. “Tutti” sarebbe un’opzione. Questa impostazione fungerebbe anche da stato “abilitato/disabilitato” per questa serie di funzionalità. Cioè, l’impostazione predefinita sarebbe “Nessuno”.
- Rivendicazione (Claim): campo di testo per identificare la rivendicazione del token ID. La “descrizione” per questa funzionalità (forse in un post qui su Meta) spiegherebbe i formati supportati, ad esempio booleano, stringa delimitata da virgole, ecc.
- Modalità: vedi sotto
Sì, se ci fosse un’impostazione rigorosa/permissiva dovremmo spiegarla in modo conciso. Penso che l’approccio migliore sia concentrarsi su “aggiunta” e “rimozione”. Potresti descriverla più o meno così:
Impostazione: “Modalità”
Opzione 1 (permissiva):
- Etichetta: “Aggiungi Membri”
- Descrizione: “Consenti l’aggiunta di membri a questo gruppo durante l’autenticazione”
Opzione 2 (rigorosa):
- Etichetta: “Aggiungi e Rimuovi Membri”
- Descrizione: “Consenti l’aggiunta e la rimozione di membri durante l’autenticazione. Questo disabiliterà i controlli manuali dell’iscrizione.”
Il motivo per cui tengo molto a mantenere l’opzione “permissiva” è che, lavorando in passato con clienti su questo tipo di cose, questo è il caso d’uso più comune, ovvero:
-
La necessità principale è consentire l’accesso a un gruppo in base a uno stato in un servizio esterno
-
La necessità di rimuovere l’accesso in base allo stato nel servizio esterno è più marginale, ovvero le persone perdono l’accesso e dovrebbero essere rimosse, ma questo è relativamente meno importante
-
Spesso c’è il desiderio di mantenere la possibilità di controllare manualmente l’iscrizione su Discourse. Quando ho implementato l’approccio “rigoroso”, questo è stato “sorprendente” (ovvero “Perché la persona X ha perso l’iscrizione?”) nonostante le spiegazioni e il funzionamento (tecnico) corretto.
Sì, è importante, poiché spesso ci si chiederà “perché” qualcuno è stato aggiunto o rimosso, specialmente in modalità rigorosa, e noi (cioè “Discourse”) non avremo il controllo sulla veridicità delle rivendicazioni fatte dal servizio di autenticazione esterno.
Forse un nuovo tipo di azione “Rimuovi Utente” e “Aggiungi Utente” che includa il servizio di autenticazione responsabile dell’azione, ovvero “Rimuovi Utente ([nome servizio])”.