La modification du sérialiseur de catégorie se comporte différemment en 2.4.0

Après la mise à niveau vers Release v2.4.0.beta2 · discourse/discourse · GitHub, presque tous nos plugins (par exemple, les aperçus de listes de sujets, les événements, les lieux, les notations, etc.) rencontrent un problème avec la méthode add_to_serializer dans plugin.rb.

L’utilisation existante suivait ce format :

add_to_serializer(:serializer, property) { value }

Cela ne fonctionne plus dans un environnement de production. Il fonctionne toujours dans un environnement de développement.

Au départ, j’ai pensé que cela pourrait être lié à la façon dont l’activation des plugins est gérée. En effet, la méthode _include? de add_to_serializer utilise l’état enabled?

if define_include_method
   # Ne pas inclure les méthodes sérialisées si le plugin est désactivé
  klass.public_send(:define_method, "include_#{attr}?") { plugin.enabled? }
end

Cependant, l’utilisation du système enabled_site_setting ne semble pas résoudre le problème. De plus, enabled? semble toujours revenir à true par défaut :

def enabled?
  @enabled_site_setting ? SiteSetting.get(@enabled_site_setting) : true
end

Pour résoudre le problème immédiat, nous avons modifié la façon dont nos plugins sérialisent les données, mais je souhaiterais comprendre ce qui se passe si possible. Quelqu’un a-t-il des idées sur ce qui se passe ici ?

cc @merefield, @fzngagan

C’est très inhabituel, car nous utilisons cela dans les sondages et ils ne sont certainement pas cassés. La seule chose à laquelle je puisse penser, c’est qu’ils étaient cassés dans la version bêta, mais corrigés dans la branche master ? Pouvez-vous essayer sur tests-passés et voir s’ils fonctionnent ?

Je vais tester davantage aujourd’hui. L’utilisation dans les sondages est légèrement différente, car la méthode _include? est toujours précédée d’un troisième paramètre false. Je soupçonne que la méthode include? pourrait être en cause.

add_to_serializer(:post, :polls_votes, false)

Il semble que ce problème soit spécifique aux modifications des sérialiseurs de catégories.

https://staging.discourse.angusmcleod.com.au a un seul plugin installé : « test-add-to-serializer »

Comme vous pouvez le voir dans plugin.rb, plusieurs modifications sont apportées aux sérialiseurs.

Les modifications des sérialiseurs autres que ceux des catégories semblent fonctionner, mais les modifications du sérialiseur basic_category ne fonctionnent qu’en développement.

Vous ne trouverez pas les propriétés de test de la catégorie à l’adresse suivante :

https://staging.discourse.angusmcleod.com.au/categories.json

ou

https://staging.discourse.angusmcleod.com.au/c/records-musicians.json

Mais vous trouverez les autres propriétés de test à l’adresse suivante :

https://staging.discourse.angusmcleod.com.au/t/this-is-a-title-of-a-topic/42.json

ou

https://staging.discourse.angusmcleod.com.au/latest.json

Le problème semble donc ne pas concerner la méthode add_to_serializer en elle-même, mais la modification du sérialiseur basic_category.

@j.jaffeux @dan Salut :), il semble que vous ayez effectué un travail récent sur discourse-voting pour résoudre le même problème que j’ai décrit ci-dessus.

Savez-vous pourquoi il n’est plus suffisant d’ajouter des propriétés au basic_category_serializer ?

Je peux confirmer que cela affecte tests-passed

Dan est absent, mais essentiellement, il existe trois endroits différents où nous sérialisons les catégories avec des quantités de données variables. Nous verrons s’il est possible d’éliminer le mixin ici, ce qui rend le raisonnement plus difficile.

Corrigé et rétroporté sur les versions stable et bêta.

Dan a correctement configuré la structure d’héritage ; il s’agissait simplement d’un bug majeur du cœur très ancien.

Merci @sam, c’est très apprécié.

Merci d’avoir signalé et insisté sur ce point. C’était un cas très, très difficile à identifier. J’ai passé un peu de temps à examiner les internals de Rails pour comprendre ce qui se passait.

N’hésitez pas à consulter le nouveau test si vous êtes curieux de voir comment nous nous assurons que cela fonctionne correctement à l’avenir.

Merci beaucoup, @sam, d’avoir corrigé cela rapidement.

@angus, notre plugin fonctionnera-t-il sans les récentes modifications que nous avons apportées en raison de cette correction ?