Gostaria de ocultar tópicos na página “Mais recentes” de usuários que são membros de um determinado grupo “ruim”. Acredito que isso possa ser feito com um componente de tema, mas estou aberto a ideias. Este é um caso de uso único e não preciso de uma interface de usuário para editar os parâmetros.
Aqui está um esforço semelhante, talvez um ponto de partida. A abordagem é usar api.modifyClass para adicionar uma classe aos tópicos (os <tr> na página “Mais recentes”), em seguida, algumas linhas de CSS para definir essa classe como display: none. Presumo que se possa obter o usuário em modifyClass e adicionar a classe se o usuário for membro do grupo “ruim”.
(Percebo que isso não afeta suas permissões, eles ainda podem ver o tópico nas visualizações de Categorias ou Pesquisa, ainda receberão e-mails, poderiam descobrir meu truque e editar seu CSS local, etc. Eu só quero criar um incômodo e fazê-los tomar uma atitude. Dadas todas as restrições, acho que essa abordagem funcionará.)
Quando você precisa que seja feito?
Nas próximas semanas.
Qual é o seu orçamento, em USD que você pode oferecer para esta tarefa?
Você quer que /latest fique vazio para esses usuários? Ou ocultar apenas alguns tópicos?
O objetivo é irritá-los? (porque eles estão irritando todo mundo?). Só estou me perguntando se há uma maneira melhor de irritá-los.
Esqueci de mencionar, ainda queremos permitir que eles vejam um tópico em seus “Mais Recentes” - os Termos de Serviço atualizados.
Eu também não gosto muito, mas é o melhor que consigo pensar. O objetivo é fazer com que todos os usuários assinem os ToS atualizados, com importância maior que o normal. Houve uma discussão em How to force existing users to accept ToS que talvez o Discourse Policy pudesse ajudar. Mas o Policy não impõe nada, e por causa da importância dos novos ToS, queremos algo mais do que uma bolha azul para incomodar os usuários. Desenvolvemos um plugin há alguns anos para adicionar membros a um grupo quando eles aceitavam uma política, e isso funcionou para algumas coisas, mas não consigo ver como fazer isso funcionar para este caso.
Já temos um conjunto bastante elaborado de grupos e categorias, então não podemos simplesmente alterar as permissões de cada categoria de “todos” para “tos-acceptors”. Se as permissões de categoria suportassem lógica booleana, talvez pudéssemos alterar as permissões para permitir apenas usuários que são membros de ambos os grupos ‘premium-group’ e ‘tos-acceptors’. Mas não suporta isso.
Não tenho uma opinião forte sobre como incomodá-los. Se houvesse alguma imposição integrada do Discourse Policy, eu a usaria. Mas precisamos de mais do que uma bolha azul neste caso.
Também considerei brevemente redirecioná-los com um link permanente se eles não forem membros de ‘tos-acceptors’. Essa ainda é uma opção se pudermos obter o ID do usuário ou nome de usuário anexado à URL do link permanente como parâmetros de consulta. Se os redirecionarmos para um Docusign ou algo assim, eu poderia configurar um webhook para adicioná-los ao grupo ‘tos-acceptors’ para que parem de ser redirecionados. Isso parece um plano melhor?
Talvez dê uma olhada em um dos componentes “Gate” existentes e ajuste os critérios deles? Eles têm bloqueadores bem irritantes e informam aos usuários o que é esperado de forma clara e direta.
Definitivamente, há espaço para definir condicionais com base na associação a grupos e para alterar a associação a grupos a partir da saída do assistente.
Um plugin que permitiria uma configuração de permissão complexa para categorias seria útil em muitas situações. Essa pode ser a melhor maneira de gastar tempo de desenvolvimento para esse problema?
Talvez com uma fórmula de slug em uma configuração de texto:
por exemplo: (#aceitador-tos ou #preocupacao-direta) e #grupo-premium