Solo quería agregar un gran agradecimiento al equipo de Discourse por incluir el parámetro bypass_bump. Es una herramienta pequeña pero poderosa: permite que los scripts y complementos actualicen el contenido en segundo plano sin mostrar involuntariamente temas antiguos en la vista más reciente.
En nuestro caso, lo usamos para scripts de sincronización de ICS, y asegura que solo los cambios significativos muevan los temas. Una adición reflexiva que mantiene los foros de la comunidad limpios y la experiencia del lector sin interrupciones. ¡Gracias de nuevo!
esto no es una publicación de elogios engañosa, como la anterior , porque
Discourse admite una marca bypass_bump al revisar una publicación; evita que la fecha de “bump” del tema cambie, incluso si editas la última (o la primera y única) publicación. Esto está explícitamente listado en las opciones de PostRevisor (“- bypass_bump: no hacer “bump” al tema, incluso si es la última publicación”).
Este tema de elogios existe y expone exactamente ese caso de uso.
Históricamente, la gente usaba la solución alternativa /t/{id}/reset-bump-date porque esta opción no era ampliamente conocida/documentada en la documentación de la API, pero todavía está disponible si es necesario.
Nota práctica: cuando haces PUT a /posts/{post_id}.json con el nuevo raw e incluyes bypass_bump=true, la edición no mostrará el tema en /latest. (La documentación oficial no detalla este parámetro, pero está implementado del lado del servidor a través de PostRevisor).
Todavía no estoy 100% seguro del estado oficial de bypass_bump en la documentación de la API; no aparece en ningún lugar obvio.
Pero cuando miro los registros del script de sincronización de Python de Ethsim12, son instructivos. El script intenta llamar a la API con bypass_bump=true. Si ese parámetro fuera ignorado o inválido, lo único que evitaría saltos innecesarios es la solución alternativa que agregaron: una llamada manual a
/t/{topic_id}/reset-bump-date
Por lo tanto, la salida del registro en sí se convierte en una fuerte evidencia. Si el registro muestra temas que se actualizan sin aparecer en /latest (y sin necesidad de la solución alternativa de reinicio), esa es una muy buena prueba de que bypass_bump está activo y funcionando. Si el registro siempre recurre a reset-bump-date, entonces tal vez no lo esté.
En otras palabras: los registros de este script son de gran ayuda para confirmar si bypass_bump existe y si el servidor lo respeta realmente.
Gracias por compartir este PR, moin — contexto muy útil.
Por mi proyecto paralelo (importador ics_to_discourse.py), acabo de confirmar un cambio para evitar que las actualizaciones basadas en el calendario “ruidosamente” impulsen temas:
Ese commit añade algo de lógica para decidir si una edición es “significativa” (cambio de hora/ubicación, etc.), y utiliza bypass_bump más una opción de respaldo para restablecer la fecha de impulso, de modo que las sincronizaciones rutinarias de ICS no muestren temas innecesariamente.
Por lo tanto, este PR se alinea perfectamente con lo que pretendía — es bueno ver que el núcleo se mueve en la misma dirección. Una vez que se fusione el comportamiento de “no impulsar en la edición”, simplificaré y eliminaré la opción de respaldo adicional, pero por ahora el commit mantiene las cosas tranquilas en las instalaciones actuales de Discourse.
Hmm, he vuelto a leer este tema y me he dado cuenta de que no incluí otra PR relevante, cuando no estaba activo en la Universidad y tenía tiempo para programar
, porque