Me gustaría ocultar temas en la página “Latest” (Más recientes) a los usuarios que sean miembros de un cierto grupo “malo”. Creo que esto se puede hacer con un componente de tema, pero estoy abierto a ideas. Este es un caso de uso único y no necesito una interfaz de usuario para editar los parámetros.
Aquí hay un esfuerzo similar, tal vez un punto de partida. El enfoque es usar api.modifyClass para agregar una clase a los temas (los <tr> en la página “Latest”), luego unas pocas líneas de CSS para establecer esa clase en display: none. Supongo que se puede obtener el usuario en modifyClass y agregar la clase si el usuario es miembro del grupo “malo”.
(Me doy cuenta de que esto no afecta sus permisos, aún pueden ver el tema en la vista de Categorías o Búsqueda, aún recibirán correos electrónicos, podrían descubrir mi truco y editar su CSS local, etc. Solo quiero crear una molestia y hacer que tomen una acción. Dadas todas las restricciones, creo que este enfoque funcionará).
¿Cuándo lo necesitas hecho?
Próximas semanas.
¿Cuál es tu presupuesto, en USD, que puedes ofrecer para esta tarea?
¿Quieres que /latest esté vacío para estos usuarios? ¿O ocultar solo algunos temas?
¿El punto es molestarlos? (¿porque molestan a todos?). Solo me pregunto si hay una mejor manera de molestarlos.
Olvidé mencionar que todavía queremos permitirles ver un tema en su “Últimos”: los Términos de Servicio actualizados.
Tampoco me gusta mucho, pero es lo mejor que se me ocurre. El objetivo es que todos los usuarios firmen los Términos de Servicio actualizados, con una importancia superior a la habitual. Hubo una discusión en How to force existing users to accept ToS sobre si Discourse Policy podría ayudar. Pero Policy no impone nada, y dada la importancia de los nuevos Términos de Servicio, queremos algo más que una burbuja azul para insistir a los usuarios. Desarrollamos un plugin hace unos años para añadir miembros a un grupo cuando aceptaban una política, y eso funcionó para algunas cosas, pero no veo cómo hacerlo funcionar para esto.
Ya tenemos un conjunto bastante elaborado de grupos y categorías, por lo que no podemos simplemente cambiar los permisos de cada categoría de “todos” a “aceptadores-de-términos-de-servicio”. Si los permisos de categoría admitieran lógica booleana, quizás podríamos cambiar los permisos para permitir solo a los usuarios que son miembros tanto de “grupo-premium” como de “aceptadores-de-términos-de-servicio”. Pero no lo admite.
No tengo una opinión firme sobre cómo insistirles. Si hubiera alguna aplicación integrada de Discourse Policy, la usaría. Pero necesitamos algo más que una burbuja azul en este caso.
También consideré brevemente redirigirlos con un enlace permanente si no son miembros de “aceptadores-de-términos-de-servicio”. Esa sigue siendo una opción si pudiéramos adjuntar el ID de usuario o el nombre de usuario a la URL del enlace permanente como parámetros de consulta. Si los redirigimos a Docusign o algo similar, podría configurar un webhook para añadirlos al grupo “aceptadores-de-términos-de-servicio” para que dejen de ser redirigidos. ¿Suena como un mejor plan?
¿Quizás deberías mirar uno de los componentes “Gate” existentes y ajustar sus criterios? Estos tienen bloqueadores bastante molestos e informan a los usuarios lo que se espera de una manera clara y sencilla.
Es posible que puedas dirigir a los usuarios para que acepten los Términos de Servicio utilizando algunas de las funciones del plugin Discourse Custom Wizard:
Definitivamente hay margen para establecer condicionales basados en la membresía de grupo y para cambiar la membresía de grupo a partir de la salida del asistente.
Un plugin que permitiera una configuración de permiso complejo para categorías sería útil en muchas situaciones. ¿Esa podría ser la mejor manera de invertir tiempo de desarrollo para ese problema?
Quizás con una fórmula de slug en una configuración de texto:
por ejemplo: (#aceptador-tos o #interesado-directo) y #grupo-premium