He configurado una categoría para el seguimiento de errores en nuestro servidor de Discourse. Me gustaría hacer un seguimiento tanto de las incidencias de errores públicas enviadas por los usuarios como de los errores enviados internamente en el mismo lugar.
Quiero que los errores públicos sean visibles para todos (por lo que los temas privados no son una solución). De esta manera, podemos reducir los duplicados y la gente puede comentar o ampliar un tema existente.
También quiero que nuestros equipos internos puedan enviar errores, pero no quiero que sean visibles para el público en general a menos que lo queramos específicamente para un tema determinado.
Podemos activar el susurro en las respuestas, pero no en el tema en sí. Entonces, ¿hay alguna forma de configurar la visibilidad por tema?
Establecer el tema como ‘No listado’ casi hace lo que queremos, excepto que tenemos un grupo de desarrolladores que necesitan verlos pero no están configurados como moderadores o administradores, simplemente están en un grupo.
¿Puede haber dos versiones de esta jerarquía de árbol? Una para uso interno y otra para uso externo. Puede usar etiquetas (o autoetiquetas) para ayudar al equipo interno a ver qué errores existen tanto interna como públicamente. Alternativamente, si es un cliente empresarial, podría tener habilitadas categorías de tercer nivel.
Tengo un autoalojamiento, así que puedo poner otro nivel ahí si quiero, pero de nuevo, no es la solución más simple para el usuario.
Lo que entiendo es que mi solicitud no es posible.
Es una pena. Esto se solucionaría teniendo una configuración del sitio para “Permitir que estos grupos vean Temas No Listados. Los administradores y moderadores siempre pueden ver estos temas.”
¿Qué tan importante es para ti que otros usuarios no lean estos temas?
Dudo que los temas no listados sean realmente una solución para ti. Cuando sigues una categoría, también recibes una notificación por cada tema no listado que se crea. Esta notificación contiene el enlace para que puedas visitar y leer el tema.
Por lo tanto, los temas no solo serían visibles para el grupo específico.
Solo las categorías controlan el acceso, pero si quieres una versión más suave de eso, podrías hacer algo con CSS para lograrlo.
Ah. Quizás lo que deberías hacer es cambiar tus permisos para que los desarrolladores (que son demasiado estúpidos, perezosos o descuidados para poner las cosas en la categoría correcta) no tengan derechos de creación en la categoría de errores públicos. Luego, si algo debe ser público, alguien que tenga suficiente capacidad de atención para ser confiable puede moverlos a la categoría pública.
Ese tipo de cosas va en contra del propósito de mi solicitud original. Quiero una categoría de errores y control sobre la visibilidad de temas individuales dentro de esa categoría.
Parece que debería ser factible, pero según los comentarios, tal vez no.
Creo que con cualquier proceso que implique “podría ser público, podría ser privado” habrá margen para el error del usuario cada vez que alguien cree un tema. Ya sea elegir la categoría correcta, recordar hacer clic en “susurrar” o agregar una etiqueta que luego haga algo de magia CSS para ocultarlo, etc. Hay un punto en el que tienes que tomar esa decisión y una oportunidad para equivocarte.
Creo que una subcategoría es el camino a seguir para poder tener confianza en las protecciones de visibilidad. Si no desea activar las sub-subcategorías para esto (o ajustar su estructura de categoría de nivel superior con una alternativa como Category Groups), puede tener una subcategoría adicional en Soporte para #internal-bug-reports y luego usar el filtro de temas para crear una lista de temas personalizada que incluya temas de ambas categorías, que luego puede agregar a la barra lateral para que la usen sus desarrolladores.
Solo por diversión, probé si podía cambiar el post_type de un OP usando la API. Y aunque funcionó, todavía apareció en la lista de temas para un usuario de prueba que no susurraba y luego arrojó un error cuando hizo clic en él. Por lo tanto, parecería que se necesitaría algo de trabajo de desarrollo adicional para suavizar eso (y también puede haber otros conflictos por el comportamiento inesperado cuando comiences a investigar).
Eso podría no ser tan malo. No me importa si los usuarios normales pueden ver los títulos.
Mi solución alternativa actual es similar:
Cree un tema con un nombre debidamente descriptivo.
El cuerpo consistirá en “Seguimiento del error n.º”
Guardar
Edite la publicación y ponga el n.º de la URL para que el cuerpo ahora diga “Seguimiento del error n.º 138”
Susurre todas las respuestas adicionales
Ahora solo agrego mi grupo de desarrollo al ‘Grupos permitidos para susurrar’.
No es tan elegante como me gustaría, pero escribir el SOP para ello es bastante sencillo.
Esto tiene el beneficio adicional de permitir que un usuario normal agregue una publicación al tema si tiene un error que parece similar al título.
Por lo tanto, parecería que se necesitaría algo de trabajo de desarrollo adicional para suavizar eso (y también puede haber otros conflictos por el comportamiento inesperado cuando comiences a investigar).