Olá.\n\nAgora que podemos conceder acesso específico a grupos para sussurros, estamos muito perto de remover o acesso de moderador para a maioria dos nossos usuários internos.\n\nNon-moderator access to whispers, quando começamos a remover o acesso, percebemos que faltava uma última peça e tivemos que reverter a mudança. Fazemos uso intensivo de atribuições (para usuários e grupos) em nossa organização. \n\nTudo isso é "escondido" da nossa comunidade de usuários. Isso realmente funciona para nós, porque às vezes atribuímos tópicos a um grupo porque…\n\n- estamos apenas repassando feedback (um aviso)\n- precisamos que uma ação seja tomada\n- não sabemos se alguma ação precisa ser tomada (e o grupo descobrirá assim que a vir)\n\nUsuários internos são confiáveis para atribuir tópicos a outros grupos na organização.\n\nO que percebemos, ao começar a revogar o acesso de moderador, é que a visibilidade do grupo e a capacidade de atribuir a grupos só podem ser abertas até "apenas membros do grupo, moderadores e administradores" antes que tenhamos que permitir que usuários não internos vejam e atribuam a grupos.\n\nSeria ótimo se essas permissões pudessem ser definidas em nível de grupo também. Para nós, esta é a última peça que falta.\n\nO que nos impulsiona:\n\nEu acho importante mencionar por que estamos nessa jornada.\n\nTemos cerca de 170 moderadores em nossa instância. Esses usuários não precisam de acesso aos endereços de e-mail e endereços IP de nossos usuários. Especialmente à medida que nossa organização continua a crescer, parece arriscado ter essas informações disponíveis para todos.
Apenas como um aparte da solicitação principal de recursos, mas a configuração de administrador moderators view emails ajuda em algo com esse problema?
Para ser honesto, eu não tinha ideia de que essa opção existia – e, na verdade, ela está desativada em nossa instância! Eu me passei por outro moderador em nossa instância e, de fato, eles não conseguem ver endereços de e-mail.
Juro que eu tinha acesso para ver e-mails quando eu era “apenas” um moderador (não um administrador) – talvez tivéssemos uma configuração diferente naquela época (nossa instância passou por uma jornada e tanto nos últimos 8 meses).
Muito obrigado por apontar isso.
Portanto, isso definitivamente remove um pouco da urgência – e, em geral, eu ainda gostaria de ver a plataforma continuar avançando em direção a permissões flexíveis baseadas em grupos, em vez dessas opções mais rígidas.
Desculpe, você pode expandir um pouco aqui?
Também estamos trabalhando em um problema semelhante no Discourse, na verdade não tenho acesso de administrador/moderador em nossa instância de desenvolvimento. Eu entendo completamente as vastas vantagens de manter o número de administradores/moderadores baixo.
Você pode detalhar o problema?
Tendo em mente que existem alguns blocos de construção nos quais você pode se apoiar:
-
Moderação de categoria, você pode definir moderação sobre categorias específicas para grupos específicos. Isso permite que usuários de alta confiança tenham maior flexibilidade.
-
Sistema de nível de confiança… no TL4 (manual) muitas coisas são desbloqueadas
-
Configuração do site
assign allowed on groups(que desbloqueia a atribuição para grupos específicos)
Com certeza. Fico feliz em expandir.
Temos várias equipes diferentes em nossa empresa que contribuem para nossa Comunidade como SMEs (Especialistas no Assunto) para qualquer parte de nosso produto pela qual sejam responsáveis. Um grupo é criado para cada equipe e, quando a expertise de uma equipe é necessária em um tópico, o tópico é atribuído à equipe (e geralmente, em seguida, atribuído a um indivíduo, que o desatribui de si mesmo quando contribuiu o máximo que pôde).
Não queremos revelar aos nossos usuários como tudo isso funciona. Tentamos manter as expectativas baixas (é um suporte gratuito que oferecemos aos nossos usuários de código aberto), não queremos que os usuários comecem a perguntar “Por que vocês não podem simplesmente atribuir isso à equipe _____ já??” – na verdade, não queremos que nossos usuários saibam que esses grupos existem.
Geralmente, sou a favor da transparência radical… mas isso funciona muito bem para nós.
E queremos que nossos usuários internos possam ver todos esses grupos, os tópicos atribuídos a eles e ter a capacidade de reatribuí-los a outros grupos.
Mas as permissões de interação em nível de grupo:
- Quem pode ver este grupo?
- Quem pode ver os membros deste grupo?
- Quem pode @mencionar este grupo?
- Quem pode enviar mensagens para este grupo?
- Quem pode atribuir este grupo
São limitadas às seguintes permissões
Isso significa que, se quisermos garantir que todos os nossos usuários internos possam ver / interagir com os grupos da maneira que precisamos, teremos que conceder pelo menos acesso de moderador. Isso não é o ideal.
Espero que isso ajude a esclarecer o problema. Me avise se posso esclarecer mais alguma coisa.
Entendo, isso certamente é um dilema. Concordo 100% que deveríamos simplesmente mudar este menu suspenso de:
Para:
Quais grupos têm permissão para X:
[meu-grupo/proprietários grupo1 grupo2 etc... ]
Na verdade, isso provavelmente simplificaria a interface do usuário e a implementação interna, que não precisaria mais lidar com enums e assim por diante.
A coisa mais difícil sobre uma porta é que “proprietários de grupo” não é um grupo real, então precisaríamos de algum tipo de novo primitivo para descrever o que isso significa. O ID do grupo não é suficiente.
Seria útil se fosse um grupo real!
Minha solicitação de recurso para exatamente isso:
Sinceramente, estou tendo dificuldade em pensar em um caso de uso real onde os proprietários de grupos não deveriam ter permissão para fazer tudo, em virtude de serem proprietários de grupos.
Nesse caso, você poderia talvez ignorar esse problema e conceder aos proprietários de grupos “direitos de deus”. As demais permissões seriam então delegadas a grupos individuais.
Eu entendo, mas me preocupo muito em fazer alterações drásticas. Ao suportar um simples grupo sombra de "proprietário do grupo", podemos migrar completamente para uma nova interface de usuário sem quebrar nada para os usuários existentes do recurso.
Com certeza, entendo totalmente sua perspectiva sobre isso!