WebHookEventType y los plugins resueltos y asignados

[RGJ (Richard - Communiteq)]

En este (fantástico) cambio que agregó webhooks al complemento solved, alguna funcionalidad relacionada con los tipos de eventos de webhook se trasladó al núcleo.

Sin embargo, esto tiene algunos efectos secundarios no deseados.

1. En instancias que no tienen instalados los complementos solved o assign, los tipos de evento se muestran pero falta la traducción y, por supuesto, los eventos no están disponibles aunque se muestren.

2. Los complementos solved y assign actualmente están rotos en instalaciones nuevas de las versiones stable y beta porque les faltan los seeds.

Mi primera idea fue pedirles que hagan un backport de los seeds a stable para solucionar el problema #2, pero dado que hay un error adicional (#1), quizás sea mejor dejar el código de seeding en el complemento en sí y simplemente reservar los ID en el código del núcleo.

En resumen, creo que sería mejor mover el código

WebHookEventType.seed do |b|
  b.id = WebHookEventType::SOLVED
  b.name = "solved"
end

de nuevo a los complementos solved y assign.

[blake (Blake Erickson)]

Gracias por mencionarlo. Investigaré qué podemos hacer para que, si los complementos no están instalados, no aparezcan en el núcleo.

[RGJ (Richard - Communiteq)]

¡Genial, gracias!
¿Podrías por favor intentar abordar el hecho de que también está roto en la versión estable?

[blake (Blake Erickson)]

@RGJ

1. En las instancias que no tienen instalados los plugins solved o assign, los tipos de evento se muestran pero falta la traducción y, por supuesto, los eventos no están disponibles aunque se muestren.

Se ha creado una solución para esto:

FIX: Don't display webhooks for inactive plugins (#9206)

En cuanto al punto #2:

@RGJ

2. Los plugins solved y assign actualmente están rotos en las instalaciones nuevas de las versiones estable y beta.

No estoy viendo ningún problema al ejecutar la versión estable (2.4.1) localmente con las últimas versiones de los plugins discourse-assign y discourse-solved.

¿Podrías proporcionarme información sobre cómo puedo replicar los problemas que estás experimentando?

[RGJ (Richard - Communiteq)]

@blake

¿Podrías proporcionarme información sobre cómo puedo replicar los problemas que estás experimentando?

Una instalación nueva en la versión estable con la última versión del plugin solved no tendrá los ID en la tabla web_hook_event_type, lo que impedirá que se muestre el tipo de webhook.

Esto ocurre porque el código que inserta los ID ha sido eliminado del plugin solved y aún no está presente en la versión estable/beta.

Los sitios instalados previamente que tenían una versión anterior del plugin solved ya cuentan con los datos de semilla y no tendrán este problema.

Por lo tanto, el paso para replicar el problema es sencillo: crea una instalación totalmente nueva en la versión estable.

Instalación nueva y limpia en 2.4.1 con el plugin solved: no hay webhook disponible.

Realicemos la inserción de datos manualmente, luego volvamos a revisar la pantalla de webhooks y aparecerá:

[blake (Blake Erickson)]

Ah, vale, así que “roto” significa que simplemente no aparece.

@RGJ

Instalación nueva y limpia en 2.4.1 con el plugin resuelto: no hay webhook disponible.

Esto es intencional. Es una función de la versión 2.5 y superiores.

[RGJ (Richard - Communiteq)]

Ok, tienes toda la razón, mis disculpas por no haber sido claro. Confundí ‘roto’ con ‘no disponible’, y dado que se trata de una nueva función, en efecto, nada está roto.

Sin embargo, me parece un poco extraño que el código de inicialización de un complemento se haya trasladado al núcleo. Entiendo que quieras reservar los ID, pero creo que sería más limpio dejar la inicialización en el complemento. Pero eso es solo mi opinión personal