Lo probé localmente. Parece que hay varios factores en juego:
El objeto siteSettings al que te refieres se obtiene mediante el inicializador y luego se utiliza en una llamada a modifyClass:
Los inicializadores se vuelven a ejecutar para cada prueba. El problema es que no tenemos forma de “restablecer” ninguna llamada a modifyClass que se haya realizado en pruebas anteriores. Nuestra solución es el parámetro pluginId, lo que significa que solo se utiliza la primera llamada a modifyClass en toda la suite de pruebas. Las llamadas a modifyClass de inicializadores en pruebas futuras se ignoran.
Normalmente, eso está bien, ya que el código dentro de una invocación de modifyClass no tiende a cambiar en cada ejecución de prueba. Sin embargo, en este caso, estás haciendo referencia a la referencia siteSettings del ámbito del inicializador.
En resumen: en las pruebas, esta implementación significa que modifyClass se quedará con la configuración del sitio de la prueba que fue la primera en ejecutarse.
La solución es usar una referencia siteSettings “en tiempo de ejecución” en lugar de “en tiempo de inicializador”. Podemos usar la del propio model:composer. Esta diferencia hace que las pruebas pasen para mí:
diff --git a/assets/javascripts/discourse/initializers/location-edits.js.es6 b/assets/javascripts/discourse/initializers/location-edits.js.es6
index 19e50c0..9d5f882 100644
--- a/assets/javascripts/discourse/initializers/location-edits.js.es6
+++ b/assets/javascripts/discourse/initializers/location-edits.js.es6
@@ -83,7 +83,7 @@ export default {
@observes("draftKey")
_setupDefaultLocation() {
if (this.draftKey === "new_topic") {
- const topicDefaultLocation = siteSettings.location_topic_default;
+ const topicDefaultLocation = this.siteSettings.location_topic_default;
if (
topicDefaultLocation === "user" &&
currentUser.custom_fields.geo_location &&