WebHookEventType e os plugins resolvidos e atribuídos

[RGJ (Richard - Communiteq)]

Nessa mudança (fantástica) que adicionou webhooks ao plugin solved, alguma funcionalidade relacionada aos tipos de eventos do webhook foi movida para o núcleo.

No entanto, isso traz alguns efeitos colaterais indesejados.

1. Em instâncias que não têm os plugins solved ou assign instalados, os tipos de evento são exibidos, mas a tradução está faltando e (obviamente) os eventos não estão disponíveis, embora sejam mostrados.

2. Os plugins solved e assign estão atualmente quebrados em novas instalações estáveis e beta porque estão faltando os seeds.

Minha ideia inicial foi pedir que você fizesse o backport dos seeds para a versão estável para corrigir o #2, mas como há um bug adicional (#1), talvez seja melhor deixar o código de seeding no próprio plugin e apenas reservar os IDs no código do núcleo.

Resumindo, acho que seria melhor mover o código

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

de volta para os plugins solved e assign.

[blake (Blake Erickson)]

Obrigado por trazer isso à tona. Vou verificar o que podemos fazer para que, se os plugins não estiverem instalados, eles não apareçam no núcleo.

[RGJ (Richard - Communiteq)]

Ótimo, obrigado!
Você poderia, por favor, tentar resolver o fato de que isso também está quebrado na versão estável?

[blake (Blake Erickson)]

@RGJ

1. Em instâncias que não possuem os plugins solved ou assign instalados, os tipos de evento estão sendo exibidos, mas a tradução está faltando e, é claro, os eventos não estão disponíveis, embora sejam mostrados.

Uma correção foi criada para isso:

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

Quanto ao item #2:

@RGJ

2. os plugins solved e assign estão atualmente quebrados em instalações novas estáveis e beta

Não estou vendo nenhum problema ao executar a versão estável (2.4.1) localmente com as versões mais recentes dos plugins discourse-assign e discourse-solved.

Você poderia fornecer algumas informações sobre como posso replicar os problemas que você está enfrentando?

[RGJ (Richard - Communiteq)]

@blake

Você poderia fornecer algumas informações sobre como posso replicar os problemas que você está enfrentando?

Uma instalação nova na versão estável com a versão mais recente do plugin “solved” não terá os IDs na tabela web_hook_event_type, impedindo que o tipo de webhook seja exibido.

Isso está acontecendo porque o código que popula os IDs foi removido do plugin “solved” e ainda não está presente na versão estável/beta.

Sites instalados anteriormente que tinham uma versão mais antiga do plugin “solved” já possuem os dados de seed e não terão esse problema.

Portanto, o passo de replicação é simples: crie uma instalação totalmente nova na versão estável.

Instalação nova e limpa na versão 2.4.1 com o plugin “solved”: nenhum webhook disponível.

Vamos realizar o seeding manualmente e, em seguida, verificar novamente a tela de webhooks; ele aparecerá:

[blake (Blake Erickson)]

Ah, certo, então “quebrado” significa que ele simplesmente não aparece.

@RGJ

Instalação nova e limpa na versão 2.4.1 com o plugin resolvido: nenhum webhook disponível.

Isso é por design. É um recurso da versão 2.5 ou superior.

[RGJ (Richard - Communiteq)]

Ok, você está totalmente certo, peço desculpas por não ter sido claro. Eu estava confundindo ‘quebrado’ com ‘não disponível’, e como se trata de um recurso novo, de fato nada está quebrado.

Ainda assim, parece um pouco estranho que o código de seed de um plugin tenha sido movido para o núcleo. Entendo que você queira reservar os IDs, mas acho que seria mais limpo deixar a seed no plugin. Mas isso é apenas minha opinião pessoal