Ciao.\n\nOra che possiamo concedere a gruppi specifici l’accesso ai sussurri, siamo molto vicini alla rimozione dell’accesso da moderatore per la maggior parte dei nostri utenti interni.\n\nNon-moderator access to whispers, quando abbiamo iniziato a rimuovere l’accesso, ci siamo resi conto che ci mancava un ultimo pezzo e abbiamo dovuto annullare la modifica. Facciamo un uso intensivo delle assegnazioni (a utenti e gruppi) nella nostra organizzazione.\n\nTutto questo è “nascosto” alla nostra community di utenti. Questo funziona davvero per noi, perché a volte assegniamo thread a un gruppo perché…\n\n- stiamo solo passando un feedback (un FYI)\n- è necessaria un’azione\n- non sappiamo se è necessaria un’azione (e il gruppo lo scoprirà una volta che lo vedrà)\n\nGli utenti interni si fidano di assegnare thread ad altri gruppi dell’organizzazione.\n\nCiò che abbiamo capito, mentre iniziavamo a revocare l’accesso da moderatore, è che la visibilità dei gruppi e la possibilità di assegnare ai gruppi possono essere aperte solo fino a “solo membri del gruppo, moderatori e amministratori” prima che dovremmo consentire agli utenti non interni la possibilità di vedere e assegnare ai gruppi.\n\nSarebbe fantastico se anche questi permessi potessero essere definiti a livello di gruppo. Per noi, questo è l’ultimo pezzo mancante.\n\nCosa ci spinge: \n\nPenso sia importante menzionare perché siamo in questo percorso.\n\nAbbiamo circa 170 moderatori sulla nostra istanza. Questi utenti non hanno bisogno di accedere agli indirizzi e-mail e agli indirizzi IP dei nostri utenti. Soprattutto con la continua crescita della nostra organizzazione, sembra rischioso avere queste informazioni disponibili a tutti.
Solo come inciso rispetto alla richiesta principale di funzionalità, ma l’impostazione dell’amministratore i moderatori visualizzano le email aiuta in qualche modo con questo problema?
Ad essere sincero, non avevo idea che esistesse quell’opzione e, di fatto, è disattivata sulla nostra istanza! Ho impersonato un altro moderatore sulla nostra istanza e, in effetti, non possono visualizzare gli indirizzi e-mail.
Giuro di aver avuto accesso per vedere le e-mail quando ero “solo” un moderatore (non un amministratore), forse avevamo un’impostazione diversa allora (la nostra istanza ha attraversato un bel percorso negli ultimi 8 mesi).
Grazie mille per averlo fatto notare.
Quindi questo sicuramente riduce l’urgenza e, in generale, vorrei ancora vedere la piattaforma continuare a muoversi verso permessi flessibili basati su gruppi piuttosto che su queste opzioni più rigide.
Scusa, puoi spiegare meglio qui.
Stiamo anche lavorando su un problema simile in Discourse, infatti non ho accesso admin/moderator sulla nostra istanza di sviluppo. Capisco perfettamente i vasti vantaggi di mantenere basso il numero di admin/moderator.
Puoi spiegare il problema?
Tenendo presente che ci sono alcuni blocchi di costruzione su cui puoi fare affidamento:
-
Moderazione delle categorie, puoi definire la moderazione su categorie specifiche per gruppi specifici. Ciò consente agli utenti ad alta fiducia una maggiore flessibilità.
-
Sistema di livelli di fiducia… a TL4 (manuale) si sblocca molto
-
Impostazione del sito
assign allowed on groups(che sblocca l’assegnazione per gruppi specifici)
Certamente. Felice di approfondire.
Abbiamo un gruppo di team diversi nella nostra azienda che contribuiscono alla nostra Community come SME per qualsiasi parte del nostro prodotto di cui sono responsabili. Viene creato un gruppo per ogni team e, quando è necessaria l’esperienza di un team su un argomento, l’argomento viene assegnato al team (e di solito poi assegnato a un individuo, che lo annulla automaticamente quando ha contribuito per quanto possibile).
Non vogliamo rivelare ai nostri utenti come funziona tutto questo. Cerchiamo di mantenere basse le aspettative (è un supporto gratuito che offriamo ai nostri utenti open source), non vogliamo che gli utenti inizino a chiedere “Perché non potete semplicemente assegnare questo al team _____ già adesso??” – infatti, non vogliamo che i nostri utenti sappiano nemmeno che questi gruppi esistono.
Di solito, sono a favore della trasparenza radicale… ma questo funziona molto bene per noi.
E vogliamo che i nostri utenti interni possano vedere tutti questi gruppi, gli argomenti ad essi assegnati e abbiano la possibilità di riassegnarli ad altri gruppi.
Ma i permessi di interazione a livello di gruppo:
- Chi può vedere questo gruppo?
- Chi può vedere i membri di questo gruppo?
- Chi può menzionare questo gruppo con @?
- Chi può inviare messaggi a questo gruppo?
- Chi può assegnare questo gruppo
Sono limitati ai seguenti permessi
Ciò significa che se vogliamo assicurarci che tutti i nostri utenti interni possano vedere / interagire con i gruppi nel modo in cui ne abbiamo bisogno, dobbiamo concedere almeno l’accesso da moderatore. Questo non è l’ideale.
Spero che questo aiuti a chiarire il problema. Fatemi sapere se posso chiarire ulteriormente qualcosa.
Capisco, questo è certamente un bel pasticcio. Sono d’accordo al 100% che dovremmo semplicemente far cadere questo da:
A:
Quali gruppi sono autorizzati a X:
[my-group/owners group1 group2 ecc... ]
Infatti, questo probabilmente semplificherebbe l’interfaccia utente e l’implementazione interna che non dovrebbe più ragionare su enum e così via.
La cosa più difficile di un porting è che “i proprietari del gruppo” non sono un vero gruppo, quindi avremmo bisogno di una sorta di nuovo primitivo per descrivere cosa significa. L’ID del gruppo non è sufficiente.
Sarebbe utile se lo fosse!
La mia richiesta di funzionalità per esattamente questo:
Onestamente, trovo difficile pensare a un caso d’uso reale in cui i proprietari di gruppi non dovrebbero essere autorizzati a fare tutto in virtù del fatto di essere proprietari di gruppi.
In tal caso, potresti forse ignorare quel problema e concedere ai proprietari di gruppi i diritti di amministratore. Il resto delle autorizzazioni verrebbe quindi delegato a singoli gruppi.
Ti sento, ma sono molto preoccupato di apportare modifiche che potrebbero interrompere il funzionamento. Supportando un semplice gruppo ombra “proprietario del gruppo” possiamo eseguire la migrazione completa a una nuova interfaccia utente senza interrompere nulla per gli utenti esistenti della funzionalità.
Certo, capisco perfettamente il tuo punto di vista!