¿Hay alguna manera de desactivar estas notificaciones sin recurrir a un truco de CSS? En realidad no necesito ese ruido visual.
5 Me gusta
¿Pero eso no seguiría mostrando un contador/indicador de notificaciones? Pero supongo que no se puede evitar.
Ya no más 
5 Me gusta
Esto me ha confundido un par de veces y no veo que se mencione arriba como una preocupación o problema.
No tengo la costumbre de revisar los Cambios próximos haciendo clic en la opción del menú de la izquierda:
https://xyz.discourse.group/admin/config/upcoming-changes
Esa página incluye un enlace de Vista previa para cada cambio.
Normalmente, como parte de mi rutina diaria, reviso la bandeja de entrada de Discourse y a veces encuentro una notificación sobre cambios próximos, por ejemplo:
https://xyz.discourse.group/admin/config/upcoming-changes?changeNamesFilter=enable_ai_bot_starred_conversations
Fíjate en el cambio en la URL y también en que el enlace de Vista previa falta.
Ese enlace de Vista previa que falta es lo que me ha estado confundiendo durante unos días. Sabía que el enlace existía, pero pensé que había desaparecido.
Espero que esto proporcione suficientes detalles para entender la preocupación y posiblemente solucionarlo.
Tanto los enlaces “Comentarios…” como “Vista previa” son opcionales para los elementos de cambio próximos:
- Los comentarios apuntarán a un tema aquí en Meta para discutir el cambio.
- La vista previa abrirá una captura de pantalla del cambio en una ventana modal en la página.
Corresponde al desarrollador que añada el cambio próximo especificar estos elementos… Avisaré a algunas personas internamente y veré si puedo conseguir que los agreguen.
1 me gusta
Hoy, el botón Vista previa aparece con la URL indicada.
https://xyz.discourse.group/admin/config/upcoming-changes?changeNamesFilter=enable_new_checkbox_style
¡Gracias!
2 Me gusta
Hoy pensé exactamente lo mismo…
Sé que esto es cierto en nuestro servicio de alojamiento, pero no estaba seguro de qué hacemos para los que se alojan a sí mismos.
Hoy busqué la fuente de verdad sobre lo que hacemos allí y descubrí que actualmente esperamos hasta que sea estable.
Así es como lo hicimos al principio: FEATURE: Automatic promotion of upcoming changes - Pull Request #36211 - discourse/discourse - GitHub
Y parece que sigue siendo así aquí:
Me pregunto si deberíamos cambiarlo a beta para los que se alojan a sí mismos.
Mientras tanto, voy a hacer una pequeña edición en el primer mensaje aquí.
1 me gusta
¿Quieres actualizar también la documentación?
Es realmente útil saberlo. Ahora entiendo por qué Martin dijo que no movería el cambio a estable antes de que se resolviera el problema. Había revisado la documentación en ese momento y me preguntaba qué diferencia hace si beta ya significa “habilitado por defecto”.
2 Me gusta
¿Te refieres a beta aquí?
También me pregunto cuántos administradores perderán la opción de optar por no participar y proporcionar comentarios antes de que el cambio sea permanente si lo eliminamos después de estar en beta, omitiendo “stable” (y permanente).
1 me gusta
Sí, me refería a beta. Ups, gracias. Corregido.
Ahora hay una PR abierta para hacer ese cambio aquí:
1 me gusta
Entonces, ¿stable solo es relevante para los pocos sitios donde el administrador ajustó la configuración de sitio oculto para habilitar cambios más tarde?
¿Cómo afectará este cambio al hecho de que aún no hay solución para los componentes de temas y el reemplazo del grupo de todos?
Si beta habilita el cambio para todos, no moverlo a stable
ya no parece tan útil. Seguirá resultando en que los componentes estén rotos para casi todos los foros.
1 me gusta
Sí. Tal vez veamos que más sitios elijan cambiar esa configuración después de este cambio. Pero el valor predeterminado sería permitir las cosas antes.
Un cambio así provocaría más quejas antes.
Recomendaríamos a las personas afectadas que lo desactiven hasta que lo solucionemos.
El cambio aún no es permanente hasta que llegue a estable/permanente, no lo eliminaremos antes… la beta simplemente lo habilita de forma predeterminada antes para autoalojadores. Como dice Dave:
Todavía puedes deshabilitarlo si hay problemas en la beta.
Estoy trabajando en esto actualmente, tuve que obtener consenso interno sobre qué hacer con esto. Hasta ahora, no hemos recibido ningún comentario al respecto excepto de ti, así que no creo que esté causando una gran cantidad de problemas para los administradores de sitios en beta ahora mismo.
Confía en mí, quiero solucionar esto tanto como tú, es mi cambio, pero también tengo prioridades competitivas en mi tiempo.
Para mí pareció que las «mejoras en la generación de informes» saltaron la fase «estable».
Tal vez simplemente no entiendo cómo funciona esto.
No estoy seguro de por qué se eliminó este cambio en particular en la versión beta en lugar de pasar a la versión estable/permanente, lo consultaré internamente.
1 me gusta
Fue un error que cometimos y hemos reintroducido el cambio previsto en DEV: Reintroduce reporting_improvements upcoming change as permanent … · discourse/discourse@08cf6f4 · GitHub.
Perdón, probablemente tengo un malentendido. En el PR que enlazaste veo que la configuración se volvió a agregar. Lo que no entiendo es qué efecto tiene ahora. ¿Qué cambia exactamente ahora dependiendo de si activo o desactivo el cambio? No puedo seguirlo en el código de alguna manera.
Así como está ahora, el paso que habría activado el cambio para la mayoría de los foros en primer lugar aún se saltó, ¿verdad? Así que nunca tuvieron la oportunidad de salir porque afectaba su foro, ¿o todavía he entendido mal el proceso?
También he intentado ver cómo funciona ahora, pero no puedo encontrar el cambio. ¿Alguien tiene una idea de qué estoy haciendo mal? La versión es 08cf6f4
La función ahora es permanente, por lo que no es un cambio que puedas activar o desactivar.
1 me gusta
Cuando los cambios se vuelven permanentes, aparecen en /whats-new en su lugar, añadiré esta información al OP, junto con cualquier otra cosa que hayamos podido pasar por alto en los últimos meses.
Edición: Ya está hecho
1 me gusta