Ho provato questo localmente. Sembra che ci siano alcuni fattori in gioco:
L’oggetto siteSettings a cui fai riferimento viene ottenuto dall’inizializzatore, e poi utilizzato in una chiamata modifyClass:
Gli inizializzatori vengono rieseguiti per ogni test. Il problema è che non abbiamo modo di “resettare” eventuali chiamate modifyClass che sono state effettuate dai test precedenti. La nostra soluzione è il parametro pluginId - significa che solo la prima chiamata modifyClass nell’intera suite di test viene effettivamente utilizzata. Le chiamate a modifyClass dagli inizializzatori nei test futuri vengono ignorate.
Normalmente va bene - il codice all’interno di un’invocazione modifyClass non tende a cambiare in ogni esecuzione del test. Tuttavia, in questo caso stai facendo riferimento al riferimento siteSettings dallo scope degli inizializzatori.
Il tl;dr qui è: nei test, questa implementazione significa che modifyClass rimarrà bloccato con le impostazioni del sito dall’ultimo test che è stato eseguito per primo.
La soluzione è utilizzare un riferimento siteSettings “al runtime” piuttosto che al momento dell’“inizializzatore”. Possiamo usare quello da model:composer stesso. Questa diff fa passare i test per me:
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 &&