No entanto, existem casos de uso para grandes comunidades como a minha, nas quais temos literalmente fóruns menores existindo dentro do principal. Pense em Clãs na cultura de jogos.
Essas subcomunidades adotam as regras principais do fórum, mas também têm algumas regras adicionais específicas e uma equipe dedicada que tem como objetivo moderar a seção, bem como liderá-las, mas isso é irrelevante.
Moderadores de categoria não podem agir sobre os usuários em si, apenas sobre a categoria, no entanto, eles deveriam, no meu caso de uso, ser capazes de impedir que alguns usuários participem se quebrarem algumas de suas regras de subfórum.
Tudo o que eu realmente preciso é saber se poderia haver granularidade suficiente nas funções principais para permitir que os moderadores de categoria bloqueiem usuários específicos de acessar sua categoria.
A maneira como posso imaginar isso é que uma tabela personalizada é gerada que adiciona tanto o category_id quanto o user_id e, quando um usuário tenta acessar um tópico ou categoria específica, simplesmente verifica essa tabela também.
Estou muito longe do alvo? Seria viável? Tenho muita experiência em desenvolvimento de software, mas quase nenhuma com Ruby, então não sei realmente por onde começar a procurar no código-fonte do Discourse para entender onde devo procurar
Você poderia permitir que apenas membros da categoria do clã postassem e remover os usuários que você não quer que estejam na categoria. Isso exigiria que todos que você quer na categoria fossem membros desse grupo.
Fiz o mesmo. E como não permito que ninguém suba automaticamente além do TL2, essa foi uma solução mental e administrativa muito fácil e descomplicada. Havia também um toque de elegância
Fiz isso para um cliente há um tempo. Os níveis de confiança não funcionariam para nós, então, em vez disso, criamos grupos privados por categoria nos quais cada usuário era automaticamente provisionado, e os moderadores de categoria eram os proprietários.
“Banimentos” eram tão simples quanto remover essas associações, o que significava zero trabalho por parte da administração.
Um pouco mais de esforço para começar, mas efetivamente zero depois.
Exemplo: um dos meus clientes tem um fórum com uma categoria “À Venda”, acessível para TL2 e superior.
Eles querem proibir certos membros de criar tópicos lá, mas precisariam copiar e manter um grupo que contenha as mesmas pessoas do TL2 menos 5 usuários específicos.
Presumivelmente da mesma forma, provisionar usuários em grupos com base em um critério (detectar promoção para TL2?) e, em seguida, removê-los, se necessário? Só porque TL2 é o critério de entrada não significa que você precise depender desse status TL2 para determinar a associação, certo? Também depende se você tem tempo e recursos para criar algo em/ao redor de sua instância.
Eu não sugeri que fosse uma solução completa para todos. Pode não funcionar para o caso de uso deles se eles não quiserem fazer o trabalho extra, mas para o exemplo com meu cliente e o cenário em que uma instância está sendo particionada em guildas/clãs/o que quer que seja, pode ser uma boa opção.
Mas se já estamos desenvolvendo algo na instância de qualquer forma, então eu prefiro ter a funcionalidade de banir categorias
Isso também torna as coisas mais fáceis de manter. Se eu tiver 50.000 usuários e precisar que todos eles possam acessar a categoria, exceto alguns, então é difícil obter uma lista desses poucos.
Quer dizer, banir é apenas outra palavra para exclusão, e o Discourse não tem realmente uma permissão de exclusão. Ela precisa existir quando ‘não inclusão’ é efetivamente a mesma coisa? Gosto do modelo de permissão explícita, ele torna a solução de problemas indolor.
Ainda tenho pesadelos ocasionais sobre tentar resolver o modelo de permissão/negação do vBulletin anos atrás. A única coisa que experimentei com mais dor e dívida associada é o RSOP.
Agradeço todas as sugestões de soluções alternativas, mas fiz uma pergunta técnica específica, não alternativas que comprometam o que estou tentando descobrir
@crius seria factível com um plugin, acho que você pode ir bem longe no lado do cliente substituindo as permissions no serializador da categoria e no lado do servidor adicionando uma verificação extra usando NewPostManager.add_handler.
Você considerou usar grupos? Crie uma categoria com 2 grupos para acesso. 1 Grupo são seus moderadores de categoria. O Outro são seus participantes no subfórum. O grupo de participantes é obrigado a solicitar acesso à área do subfórum. Seus moderadores de categoria, alguns ou todos, são proprietários desse grupo. Se um membro quebrar regras exigindo que ele seja expulso do subfórum. Expulse do grupo de participantes e comunique-se com outros moderadores de categoria sobre a duração.
Bem, então, infelizmente, você pode precisar considerar o patrocínio de um plugin. É aqui que o financiamento coletivo de plugins seria um ótimo conceito. A equipe principal pode eventualmente adicionar algo como o que você está solicitando, mas pode levar algum tempo devido às prioridades da lista de desenvolvimento.
Por outro lado, com a sugestão de grupo, pode ser possível adicionar uma opção de expulsar do grupo com um componente de tema.
Você tem certeza absoluta de que fez a pergunta certa
Quero dizer, seu objetivo principal é resolver um problema, e o banimento de categoria é apenas sua resposta não resolvida para isso. A pergunta certa seria como resolvo o problema X e quais são minhas opções.
Avaliei a possibilidade de gerenciar isso com TL ou grupos de usuários, mas isso aumentará a carga de trabalho dos moderadores, o que simplesmente não é viável em grandes comunidades.
Os grupos de usuários, em particular, são prejudiciais para uma experiência de usuário enxuta.
Não preciso pedir patrocínio, pois tenho muita experiência como engenheiro de software e outras pessoas que também têm muita experiência. Nós simplesmente não usamos Ruby, então essa será a única lentidão.
Obrigado pelas contribuições, de qualquer forma. Aprecio que este fórum tende a ser muito opinativo, mas quando se trata do software em si, seria melhor simplesmente seguir uma abordagem que seja mais “dar a opção”, com, é claro, complexidade adicional em termos de código estando do outro lado da balança.
Muito amor para @RGJ por adicionar alguns insights
