Se (você já está no Grupo A)
Você pode entrar livremente neste grupo
Senão
Você deve enviar um pedido de adesão
O caso de uso é que temos contratados externos. Queremos dar-lhes acesso ao Discourse. Atualmente, eles podem entrar livremente nos mesmos grupos que nossos funcionários podem entrar. Isso cria um problema de confidencialidade.
Se tornarmos a entrada no grupo baseada em pedidos de adesão, então receberei constantemente pedidos de adesão que aceitarei automaticamente de qualquer maneira. Além disso, terei o hábito de aceitá-los por padrão e, sem dúvida, aceitarei um pedido de contratado por acidente, o que anulará completamente o propósito.
Nossos funcionários devem poder entrar nos grupos de seu interesse, mas os contratados só devem ter permissão para entrar se forem autorizados a fazê-lo.
Grupos são coleções de usuários que podem ser usadas para controlar o acesso a categorias. Você poderia simplesmente dar acesso à sua equipe a todas as categorias sem exigir que elas entrem em um grupo? (adicione o grupo de funcionários a todas essas categorias). Ou há algo mais que você está fazendo com o grupo?
Duvido que isso vá para o núcleo em breve, mas um plugin poderia fazer isso.
Desculpe se essas sugestões são o que você já sabe e o que você realmente quer é o recurso.
@Tris20 Estou um pouco perdido, mas isso não é uma função normal onde você pode permitir acesso a algumas categorias dependendo de um grupo, como o grupo de empreiteiros, ou o que você está tentando alcançar em primeiro lugar?
Se um empreiteiro é membro desse grupo específico, por que ele precisa estar em outro grupo para ter acesso a outro grupo?
Isso significa que RH, Finanças e Jurídico verão as categorias acima,
Portanto, se dermos a todos os funcionários acesso a todas as categorias, também abriremos problemas de confidencialidade. Ao criar um grupo para cada categoria, sabemos quem tem acesso à informação.
Também haverá um número significativo de categorias. É muito mais fácil para nós ter uma abordagem geral para as categorias: um grupo de membros e um grupo de moderadores por Categoria. A Categoria só é visível se você for membro do grupo da categoria. por exemplo, você só vê Docker se entrou no Grupo Docker.
Portanto, basicamente, eles apenas entram/saem do grupo se quiserem ver a respectiva categoria. Assim, um grupo geral de “funcionários” não atingiria realmente esse objetivo (embora já tenhamos um para uso geral).
Se eu tiver três contratados, um para cada Categoria:
Docker
Grafana
Linux
Eles não podem ter permissão para ver as categorias para as quais não foram contratados.
Isso significa que crio grupos “Contratados-Docker”, “Contratados-Grafana”, etc.? Não posso fazer isso para todas as Categorias.
A maneira mais eficaz de gerenciar isso é ter um grupo de Contratados utilizando a atribuição automática baseada no endereço de e-mail, por exemplo, @external.com. Então, posso restringir o acesso desses usuários especificamente.
No entanto, cada membro do grupo de contratados será contratado para ferramentas diferentes e precisará de acesso a áreas diferentes. Consequentemente, ou permito que o grupo de contratados acesse todas as categorias (o que frustra o propósito) ou crio um grupo de contratados para cada categoria (não, não, não) ou… permitimos que os usuários de um grupo existente (todos os funcionários) participem livremente do grupo.
Em geral, ter contratados significa que não posso usar a funcionalidade de “participar livremente” de forma alguma.
Duas solicitações de recursos semelhantes que seriam resolvidas por esta sugestão.
A proposta acima permitiria que todos os membros entrassem livremente em grupos (e categorias associadas) se estivessem em um grupo de “usuários bem-comportados” (ou talvez até acima de um nível de confiança!). Aqueles abaixo do nível de confiança ou que não estão no grupo de “usuários bem-comportados” devem entrar mediante solicitação.
Da mesma forma, se o tópico estiver em uma categoria específica.