Ho fornito un po’ di contesto sul caso d’uso in Restrict exposure of full name to certain groups. Stiamo utilizzando Discourse per facilitare la discussione sulla scuola pubblica locale; la base di utenti target è composta principalmente da genitori e altri membri della comunità locale. Vogliamo trovare un equilibrio:
Da un lato, rendere il sito aperto alla navigazione anonima (in modo che i motori di ricerca possano indicizzarlo, sia accessibile anche ai non membri, sia aperto/trasparente per principio, …).
Dall’altro lato, evitare di rendere inutilmente disponibili informazioni di identificazione personale a crawler e visitatori occasionali non membri — vogliamo consentire alle persone di condividere i propri nomi all’interno della comunità e vogliamo affrontare la reticenza che molte persone hanno nel farlo.
Originariamente, sembrava che la disattivazione di “Mostra nome nei post” e l’attivazione di “Nascondi profili utente al pubblico” avrebbero impedito la fuga di nomi agli utenti anonimi — ma poi ci siamo resi conto che non è così. (E avevamo già promesso alle persone tramite TOS e FAQ che lo avremmo fatto. )
Negare l’accesso ai nomi completi solo agli utenti anonimi avrebbe risolto il problema. Ma, poiché è altrettanto facile vincolare l’accesso all’appartenenza a un gruppo, penso che tanto vale farlo — il che apre la possibilità, sul nostro sito, di limitare l’accesso a >=TL1, il che è ancora meglio. (Attualmente, richiediamo un invito per l’iscrizione, ma vogliamo eliminarlo.)
Esaminando questo problema/argomento, ho visto altri riferimenti a richieste uguali o simili, ad esempio, “vogliamo solo che questo o quel gruppo possa vedere i nomi”… quindi questo risolverebbe anche quei casi.
Una domanda per te (che potresti persino considerare una domanda di prodotto!):
L’impostazione enable_names intende significare “Non mostrare nomi completi agli utenti.” o piuttosto “Questo sito non utilizza nomi completi, punto.”?
Ho la sensazione (dal codice stesso e da argomenti/problemi come questo) che ci sia una mancanza di chiarezza sottostante su questo punto — e alcune persone l’hanno inteso in un modo e altre nell’altro.
D’accordo. Gli amministratori dovrebbero poter accedere al Nome Completo senza dover attivare e disattivare l’interruttore. Ci sono motivi particolarmente importanti (almeno per il nostro forum) per nascondere i nomi reali.
Grazie a tutti coloro che hanno contribuito a questa discussione. Vorrei solo chiedere rispettosamente se questo problema verrà risolto in una prossima release o, almeno, riconosciuto come una regressione nota.
Disabilitare l’opzione per abilitare i nomi attualmente interrompe funzionalità chiave di amministrazione in un modo che sembra non intenzionale, e la mancanza di chiarezza sul fatto che questo sia intenzionale o un bug rende difficile per noi pianificare di conseguenza. Per quelli di noi che gestiscono siti di produzione dove i nomi utente sono preferiti ai nomi completi, questa limitazione introduce reali attriti e comportamenti inattesi.
Capisco che le priorità debbano essere bilanciate, ma sarebbe incredibilmente utile ricevere un aggiornamento dal team sul fatto che questo sia all’attenzione. Grazie in anticipo per qualsiasi informazione possiate fornire.
Ehi, @tobiaseigen, qualche input ingegneristico su questo? (Sono passati 3 mesi — ma anch’io ero occupato con altre cose e ho perso di vista questa cosa, quindi non posso lamentarmi.)
Potrei iniziare a inviare una o più pull request questa settimana per rendere la conversazione più concreta — ma sono restio a farle rimanere non revisionate, e potrei anche usare qualche feedback su alcuni aspetti del mio approccio.
@RGJ@chrismalone e @mdoggydog Grazie mille per il vostro contributo. Abbiamo ancora bisogno di questa correzione e siamo grati a tutti coloro che stanno lavorando al problema.
Sinceramente, sono sorpreso che questo non abbia ricevuto più attenzione. Capisco bene l’esitazione nel fare una PR senza sapere se verrà esaminata e potenzialmente implementata.
Anche se immagino che una PR potrebbe forse diventare un plugin, questo limiterebbe maggiormente questa opzione all’hosting autonomo.
@mdoggydog Sembra che la tua soluzione qui sia di sostituire l’impostazione enable names con una che accetta un elenco di gruppi, e i nomi dei membri sono visibili solo a quei gruppi.
Nota che questo dovrebbe comunque rispettare l’impostazione display name on posts (e qualsiasi altra simile che possa esistere), quindi anche i gruppi autorizzati non vedono il nome sui post se quell’impostazione è disabilitata.
Inoltre, alcune altre cose che dobbiamo correggere/modificare qui come effetti a catena:
I nomi dovrebbero essere sempre visibili nella vista amministratore di un profilo utente. Questo sarà il caso indipendentemente da qualsiasi impostazione.
I nomi dovrebbero essere visualizzati nelle e-mail solo se l’utente è in un gruppo consentito.
Quanto sopra dovrebbe risolvere i problemi attuali, oltre a rendere questa funzionalità più flessibile e utile.
Ti sembra quello che stai proponendo qui? Se sì, saremmo sicuramente felici di dare un’occhiata a qualsiasi PR (Pull Request) tu invii con questo aggiornamento incluso.
Il codice che ho scritto non rimuove l’impostazione enable names,[1] ma vi aggiunge:
Aggiungere un’impostazione full_names_visible_to_groups (che include admins e moderators come valori obbligatori).
Aggiungere un metodo can_see_full_names? a Guardian, che esegue un “and” di enable_names e l’appartenenza al gruppo in full_names_visible_to_groups.
Utilizzare questo nuovo metodo in tutti i punti appropriati in cui un nome completo viene esposto/emesso dal server.
1 e 2 sono stati facili. 3 è più complicato, e so di aver incontrato alcuni intoppi che non ero sicuro di come risolvere senza ricevere consigli/guida. Devo tornare indietro e rivedere a fondo il mio codice e i miei appunti. (Sono passati più di 2 mesi da quando mi sono immerso in questo. )
(Se ricordo bene, display name on posts e simili sono impostazioni lato client, che influenzano la presentazione dei dati ricevuti dal server. In altre parole, una restrizione in aggiunta a qualsiasi cosa il server emetta.)
Credo che (1) sia gestito se enable_names è vero, il che probabilmente sarà ciò che quasi tutti vorranno una volta disponibile la nuova impostazione per gruppo.[2]
Penso di aver incontrato e gestito (2) — per lo più.[3]
Ricordo altri casi in cui vengono trapelati nomi completi.[4]
Comunque, rivedrò gli appunti e cercherò di inviare PR questa settimana, e nel processo farò riemergere le domande aperte/punti in sospeso.
…per una serie di ragioni, tra cui: (a) non ero sicuro di quale fosse l’intento effettivo dell’impostazione (vedi la mia domanda in un post precedente sopra) e (b) lasciarla inserita fornisce un percorso di aggiornamento incrementale più sicuro. ↩︎
…se si assume che enable_names = false significhi “Questo sito non utilizza nomi completi in alcun modo”. ↩︎
Ad esempio, quando un’email di invito viene inviata a un qualche indirizzo (ovviamente non associato a un utente, altrimenti non avrebbe bisogno di un invito), l’email include il nome completo di chi invita o no? ↩︎
Ad esempio, oneboxer.rb, quando fa il oneboxing di un utente locale, scrive il nome completo nel contenuto del post cotto, rendendolo visibile a chiunque, per sempre. ↩︎
Questo PR è un prerequisito per quelli successivi, garantendo che le istanze di Guardian vengano effettivamente passate da un serializzatore all’altro. I dettagli sono nel PR/messaggio di commit. La conversazione su questo PR potrebbe anche iniziare mentre preparo il prossimo.
La mia mini avventura su GitHub
… beh, c’era fino a quando non ho digitato l’URL nella casella di modifica qui … e poi il mio intero account è stato improvvisamente sospeso.
Ho presentato una richiesta di ripristino e aggiornerò questo messaggio quando avrò aggiornamenti.
13 ore dopo, ho ricevuto un’email che diceva, in sostanza: “A volte succede; tutto a posto ora”. Molto kafkiano. Il mio account è scomparso dal sito, al punto che i post che avevo fatto in Issues/PR anni fa erano svaniti, lasciando dietro conversazioni misteriose a senso unico, con poche citazioni fantasma come unica prova che qualcun altro (io) era stato lì.
Questo sembra orribilmente drastico, non solo per l’account sospeso, ma anche per tutti i progetti a cui vengono strappati via pezzi della loro storia.
Mi sto rendendo conto che questo comporterà anche il coordinamento delle modifiche nei repository dei plugin di Discourse, il che significa una catena di PR (Pull Request), in una sorta di ordine dall’interno verso l’esterno, per garantire che i test passino sempre (e, naturalmente, che main sia sempre funzionale).
Immagino che la sequenza sarebbe simile a questa (dove CORE significa “PR in discourse/discourse” e PLUG significa “PR nei repository ufficiali dei plugin”):
Imposta l’inoltro dell’ambito del serializzatore * (nessun cambiamento funzionale previsto) *
a. CORE Implementa il controllo dell’ambito del serializzatore, disabilitato per impostazione predefinita
b. PLUG Correzioni per l’inoltro dell’ambito
c. CORE Correzioni per l’inoltro dell’ambito e abilita il controllo dell’ambito per impostazione predefinita
Fornisci preventivamente Guardians (sostituendo i segnaposto) nei punti necessari per la Fase 4 * (nessun cambiamento funzionale previsto) *
CORE Correzioni dei segnaposto
PLUG Correzioni dei segnaposto
Implementa un semplice Guardian#can_see_full_names? che dipende solo da enable_names * (nessun cambiamento funzionale previsto) *
CORE Aggiungi il metodo a Guardian
Usa can_see_full_names? ovunque venga emesso il nome completo (sostituendo l’uso semplice di enable_names come appropriato) (potrebbe esserci un cambiamento funzionale)
CORE Aggiungi una nuova impostazione alla configurazione e controlla l’impostazione nel metodo Guardian
(1) e (2) si riducono a garantire che i Guardians siano utilizzati in modo più coerente e affidabile in tutto il codice base di Discourse.
(3) e (4) riguardano l’istituzione di un’astrazione più precisa per controllare quando i nomi completi sono esposti dal backend (decidendo sull’esposizione a seconda del contesto rappresentato dal Guardian).
(5) è finalmente la parte (relativamente banale) in cui l’esposizione del nome completo è regolata dall’appartenenza al gruppo.
Grazie! Ho coinvolto un ingegnere per dare un’occhiata. Sembra che tu sia sulla strada giusta, ma un ingegnere sarà in grado di fornire un feedback più informato
Mi dispiace, ma devo rifiutare questa PR. Tale modifica è troppo complessa e difficile da mantenere. I motivi principali sono:
L’ambito (scope) non è sempre richiesto e non dovrebbe essere imposto;
Modificarlo e mantenerlo successivamente in tutti i posti, come i plugin, sarebbe un’enorme quantità di lavoro;
PlaceholderGuarian non risolve il problema ma aggiunge un ambito fittizio (con l’intenzione di risolverlo in seguito);
La maggior parte delle volte, la serializzazione dovrebbe avvenire nel controller e l’ambito verrà aggiunto automaticamente.
Visualizzare un nome utente o un nome completo in base al gruppo è piuttosto complicato. Invece di cercare di integrarlo nel core di Discourse, possiamo iniziare creando un plugin? Se la tua community è piccola, ecco come può funzionare:
Imposta SiteSetting.enable_names su false per utilizzare sempre il nome utente;
Definisci un endpoint che restituirebbe una mappa di nome utente → nome completo per gli utenti TL3;
Ho appena terminato una PR che risolve il problema originale. L’amministratore sarà sempre in grado di vedere il nome completo e modificarlo. Cercheremo di unirla all’inizio della prossima settimana
Penso che ci sia ancora un fondamentale malinteso/disaccordo su cosa dovrebbe fare esattamente l’impostazione enable_names, che si riduce a questa domanda:
L’impostazione enable_names intende significare
“Non mostrare i nomi completi pubblicamente”,
“Questo sito non utilizza i nomi completi, punto.”
Penso che alcune persone su questo argomento pensino che significhi (1), e altre pensino che significhi (2). La mia impressione è quest’ultima, ovvero che enable_names decida se il sito utilizza o meno i nomi completi.
Tieni presente che quando enable_names è disattivato:
La finestra di dialogo di registrazione non offre il campo del nome completo.
Gli utenti non vedono il campo del nome completo nella propria pagina delle preferenze dell’account; gli utenti non vedono mai il proprio nome completo da nessuna parte.
Non capisco il caso d’uso per un sito in cui gli amministratori, e solo gli amministratori, sono gli unici a sapere che un campo del nome completo esiste nel sistema. La mia mancanza di immaginazione mi rende scettico sul fatto che qualcuno qui lo desideri davvero. Se qualcuno lo desidera, per favore illuminatemi!
(Penso che ci sia anche qualche malinteso su cosa sta cercando di realizzare la mia bozza di PR, e come, e perché — ma volevo prima affrontare la domanda “Cosa fa effettivamente enable_names?”)
Sì, posso citare numerosi esempi. Spesso l’azienda proprietaria della community ha il diritto legale (e/o la necessità) di conoscere i nomi dei propri clienti, ma le leggi sulla privacy le vietano di pubblicare tali nomi a terzi. Praticamente la stessa cosa del perché usare CC in un’email di massa è un no-no e si dovrebbe usare BCC.
Beh, questo è iniziato come un semplice bug report in cui si comportava male. E poi siamo tutti entrati in una discussione su cosa dovesse fare, il che ha anche causato molta confusione e discussioni extra. Il che va bene, ma sarebbe stato meglio in un topic Feature.
È il numero 1. La descrizione dell’impostazione dice:
Mostra il nome completo dell’utente nel suo profilo, nella scheda utente e nelle email. Disabilita per nascondere il nome completo ovunque.
Il fatto che il nome completo sia nascosto implica che esista, e gli amministratori possono vedere le cose nascoste.
Ci sono anche display_name_on_posts, full_name_requirement e display_name_on_email_from.
Se vuoi il numero 2, immagino che avrebbe più senso basarsi su full_name_requirement e aggiungere un’opzione ‘Mai’ lì.
(E sì, sono d’accordo sul fatto che enable_names dovrebbe essere chiamato diversamente, ma rinominare le impostazioni non è mai divertente). E sono anche d’accordo sul fatto che
Questa correzione ripristinerà la funzione originale? Cioè, l’amministratore e l’utente possono vedere il loro nome completo? Sembra solo che questa modifica abbia inizialmente causato molti problemi rispetto alla funzione originale. Anche il moderatore completo dovrebbe avere un’opzione per vedere il nome reale tramite un’impostazione, poiché in alcuni casi potrebbe essere desiderato/necessario.
Dopo che il team ha apportato questa modifica, tutti gli utenti che avevano inserito il nome reale sono diventati vuoti.
Questa impostazione, a mio parere, avrebbe dovuto essere separata in 2 impostazioni con definizioni chiare. Con la nuova funzionalità per disabilitare i nomi come una nuova impostazione per disattivare i nomi reali.
Sono fortunato ad avere una piccola community. Immagina un sito con migliaia di membri i cui nomi reali sono stati cancellati.
)
)
