I login locali sono disabilitati (sono configurati i login con Facebook e Google)
Il personale deve approvare tutti i nuovi account utente
Abbiamo una grande lista di distribuzione email e vorremmo “pre-approvare” tutti gli indirizzi email presenti in questa lista. Se una persona visita il sito e tenta di registrarsi o accedere con un account Facebook o Google associato a un’email nella nostra lista di pre-approvazione, non dovrà attendere l’approvazione da parte di un membro dello staff e potrà iniziare immediatamente a utilizzare il sito.
Idealmente, vorremmo anche poter preconfigurare l’iscrizione ai gruppi per ogni indirizzo email.
È possibile farlo? Sono benvenute soluzioni che richiedono l’utilizzo dell’API di Discourse.
Temo che questo non funzioni affatto!
Principalmente perché gli inviti non funzionano senza che siano abilitati gli accessi locali. Quindi, probabilmente dovrai affidarti a un plugin altamente personalizzato che gestisca tutto ciò o a un sistema di autenticazione esterno per soddisfare le tue esigenze.
Penso che se importi gli indirizzi tramite uno script di importazione, accadrà la cosa giusta. Dovrai assicurarti che quegli utenti non siano contrassegnati come attivi, a meno che tu non voglia rischiare di inondarli di notifiche e riepiloghi.
Questo dovrebbe essere abbastanza semplice da fare dalla console. Penso che possa essere realizzato anche tramite l’API se sei ospitato da qualche parte.
“Grande” significa circa 5.000 — abbastanza da non volerlo inserire manualmente nell’interfaccia utente da qualche parte.
@pfaffman puoi chiarire un po’ come potrei creare gli utenti tramite l’API? Sembra che ‘password’ sia un campo obbligatorio per la creazione degli utenti, il che presumo non possa essere fatto se ho disattivato l’accesso locale: POST /users
Per espandere un po’ il caso d’uso, per altri che potrebbero considerare qualcosa di simile: vogliamo incoraggiare gli utenti ad accedere con il loro account social — molte delle persone che stiamo cercando di coinvolgere in Discourse non sono esperte di tecnologia e vogliamo che sappiano di non dover gestire un altro nome utente e password.
Tuttavia, la funzione attuale di invito tramite email in Discourse richiede all’utente di scegliere una password, il che compromette il nostro obiettivo di mantenere le cose semplici per i nostri utenti.
Forse esiste un modo diverso per raggiungere il nostro obiettivo? Non sono contrario ad abilitare l’accesso locale se necessario, ma voglio che gli utenti invitati vedano chiaramente che possono accedere con i social e non abbiano bisogno di una password.
Grazie a tutti! Sono davvero entusiasta di vedere più persone che usano Discourse.
Permettere loro di non creare una password e richiedere loro di comunicare l’indirizzo email usato per l’accesso tramite social non è la stessa cosa. Possono comunque evitare di avere una password se usano l’accesso tramite social. Spesso mi rifiuto di accedere con il mio account Gmail (anche se meno frequentemente ora) e mia moglie lo fa quasi sempre. Inoltre, l’accesso tramite email è molto comodo e significa che non serve mai una password. Ma sto divagando.
Se l’API richiede una password, generane semplicemente una casuale. Avere una password che non conosci e di cui non hai bisogno è praticamente equivalente a non averne affatto.
Devo ammettere che non mi ero reso conto, solo dopo un’attenta analisi, che il campo password è opzionale per gli utenti che accettano inviti via email. Hai ragione nel sostenere che gli utenti dovrebbero poter scegliere se utilizzare un indirizzo email diverso e creare una password. Mi sentirei molto più tranquillo se l’interfaccia utente rendesse più chiaro che la password è opzionale, specialmente quando il login tramite social è abilitato sul sito. Con l’interfaccia attuale, qualcuno dovrebbe proprio non voler creare una password per scoprire che non è strettamente obbligatoria, a mio parere. Suppongo che dovrei mettermi al lavoro e creare una PR per migliorare l’esperienza utente
Ho dato un’occhiata al codice di esempio, grazie! Per quanto riguarda il mio caso, ho dovuto ricorrere a questo workaround per effettuare le chiamate API appropriate: Using the API to create a user on an SSO only system - #13 by DylannCordel - anche così, non credo che questo soddisfi il caso d’uso che avevo in mente, poiché attiva un’email di attivazione per l’utente, cosa che speravo di evitare per offrire un’esperienza “funziona subito” e senza interruzioni, qualora l’utente decidesse in futuro di accedere al sito.
Ho anche sperimentato un po’ con questa soluzione: How to manually add user in discourse? - #10 - penso che potrebbe funzionare per inserire manualmente gli account utente che desidero, ma alla fine non sono sicuro che valga la pena rischiare di modificare direttamente l’ambiente all’interno del container per apportare queste modifiche.
Quindi, tutto sommato, penso che il flusso di lavoro che speravo non sia effettivamente supportato o previsto, e dovrò accontentarmi di questa situazione fino a quando l’interfaccia utente non verrà migliorata (forse) in un secondo momento.
I login tramite social network saltano la password, poiché l’autenticazione è gestita da Facebook, Twitter, Google, ecc.
Gli inviti rendono la password temporaneamente opzionale, ma devi seguire nuovamente il link dell’invito per “accedere”. Credo che abbiamo reso questo processo così complesso da renderlo di fatto inutilizzabile. Dovresti richiedere un reset della password via email per accedere, il che richiede comunque di impostare una password.
È una storia lunga, ma gli inviti sono progettati per far entrare le persone e rispondere il prima possibile con il minimo sforzo, ma NON sono pensati per permettere di saltare per sempre l’impostazione di una password.
Invia un invito via email a un utente (perché questa opzione sia disponibile, l’accesso locale deve essere abilitato).
Quando l’utente clicca sull’invito, può lasciare la password vuota e accedere immediatamente.
La prossima volta che visita il sito e deve effettuare l’accesso, può usare un account social associato a quell’email.
È giusto dire che forse questa procedura non dovrebbe funzionare e che il mio precedente commento sull’interfaccia poco chiara sia in realtà una funzionalità e non un difetto, pensato per scoraggiare l’uso di questo workaround. Detto questo, sembra comunque un percorso accettabile per un utente invitato via email che, alla fine, non voglia creare una password e preferisca gli altri vantaggi dell’accesso tramite social (ad esempio, l’importazione della propria immagine del profilo).
Comprendo perfettamente il punto precedente secondo cui alcuni utenti preferiscono attivamente una password all’accesso tramite social, e sono convinto che non si debba disabilitare questa opzione per chi la desidera. Tuttavia, spero ancora di trovare un percorso semplice e chiaro per invitare o comunque configurare utenti che preferiscono non avere una password.
