Projet

Général

Profil

Bug #50126

variable supprimée depuis theme/config.json persistantes dans hobo.json

Ajouté par Thomas Jund il y a environ 3 ans. Mis à jour il y a presque 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
14 janvier 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Lors de la suppression d'une variable dans un fichier config.json elle reste persistante dans hobo.json.

Par exemple, si un thème a posé `"logo_link_url": "https://www.entrouvert.com/", il va s'inscrire dans hobo.json
Si on bascule vers un autre theme qui n'a pas déclaré cette variable dans son config, la variable reste dans hobo.json et le logo pointera toujours vers l'url déclarée.


Demandes liées

Lié à Hobo - Bug #32147: Les variables dans Hobo ne sont pas supprimées quand on les supprimeNouveau10 avril 2019

Actions

Historique

#1

Mis à jour par Thomas Jund il y a environ 3 ans

Pénible ce truc.

#2

Mis à jour par Benjamin Dauvergne il y a environ 3 ans

  • Assigné à mis à Thomas Jund

Si tu passes sur chaque service, que tu édites pour de faux son titre et que tu cliques sur Enregistrer, est-ce que le problème persiste ?

Je ne suggère pas que ce soit une solution satisfaisante mais c'est pour confirmer que c'est simplement un problème de détection que la configuration du thème a changé et pas un problème dans la diffusion de celle-ci.

#3

Mis à jour par Benjamin Dauvergne il y a environ 3 ans

Benjamin Dauvergne a écrit :

Si tu passes sur chaque service, que tu édites pour de faux son titre et que tu cliques sur Enregistrer, est-ce que le problème persiste ?

Je ne suggère pas que ce soit une solution satisfaisante mais c'est pour confirmer que c'est simplement un problème de détection que la configuration du thème a changé et pas un problème dans la diffusion de celle-ci.

Je me répond à moi même: les variables issues du thème ne passent pas par hobo.json mais par un mécanisme différent (qui nécessite par contre un redémarrage d'un worker/du service, sans rien faire ça prend 3h); vérifie que celle que tu vois n'est pas aussi posée à la main dans hobo, ça me parait être la seule explication possible (ou alors tu n'as pas eu la patience d'attendre 3h :)).

PS: le code

class ThemeSettings(SettingsDictUpdateMixin):
    def get_new_time(self, tenant):
        return 0 <-- ça veut dire qu'on ne peut pas détecter de changement dans la configuration du thème, par contre c'est rechargé si autre chose change, comme hobo.json (juste le timestamp suffit)

    def update_settings(self, tenant_settings, tenant):
        if not hasattr(tenant_settings, 'TEMPLATE_VARS'):
            return
        theme_id = tenant_settings.TEMPLATE_VARS.get('theme')
        if not theme_id:
            return
        theme = get_theme(theme_id)
        if not theme:
            return
        tenant_settings.THEME_INFO = theme
        module_name = os.environ.get('DJANGO_SETTINGS_MODULE', '').split('.')[0]
        module_settings = theme.get('settings', {}).get(module_name)
        if not module_settings:
            return
        self.handle_settings(tenant_settings, module_settings)

#4

Mis à jour par Thomas Jund il y a environ 3 ans

qui nécessite par contre un redémarrage d'un worker/du service, sans rien faire ça prend 3h);

L'exemple que je donne de la variable "logo_link_url" est restée des mois. Cas d'usage: Valentin a posé la valeur `"logo_link_url": "http://www.essonne.fr/"`pour le thème de l'Essonne. Valeur qui s'est activée chez moi en local en testant son intégration.
Depuis plusieurs mois, je travaille sur des thèmes qui n'ont pas défini de valeur pour cette variable et pourtant, elle est toujours définie. Et donc, si je bosse sur un thème quelconque où un clic sur le logo du header doit me ramener vers la home du portail, ben je m'en vais vers le site de l'Essonne :).

Comme je bascule beaucoup d'un thème à un autre, je me retrouve avec plein de variables définies différemment des valeurs par défaut.

Peut-être que le worker en question, chez moi, ne fait pas son job. À creuser.

#5

Mis à jour par Benjamin Dauvergne il y a environ 3 ans

Chez toi c'est du publik-devinst ? Donc oui ça ne se relance jamais, ça ne se comporte pas du tout comme le SaaS, tu peux aussi faire simplement touch /var/lib/combo/combo.dev.publik.love/hobo.json.

#6

Mis à jour par Emmanuel Cazenave il y a environ 3 ans

Dans l'idée de faire quelque chose dans devinst pour améliorer la situation, qu'est ce qui se passe en prod qui ne se passe pas dans devinst ? Un cron ? J'ai pas compris.

#7

Mis à jour par Thomas Jund il y a environ 3 ans

tu peux aussi faire simplement touch /var/lib/combo/combo.dev.publik.love/hobo.jso

Testé, et cette commande va juste modifier l'horodatage du fichier. Sans reconstruire le fichier en supprimant les variables fantômes.
Lorsque je change de thème ou supprime une variable depuis theme/config.json (ou suppression d'un fichier extra.js), est-ce que je ne peux pas tout simplement supprimer les fichiers hobo.json. hobo va-t-il les recréer si je relance le thème depuis son bo?

#8

Mis à jour par Thomas Jund il y a presque 3 ans

Suite à https://dev.entrouvert.org/issues/53694
Il s'avère donc qu'une variable supprimée côté config.json dans un thème ne la restore pas dans sa version par défaut au sein des fichiers hobo.json, même sur les serveurs.

#9

Mis à jour par Thomas Jund il y a environ 2 ans

  • Lié à Bug #32147: Les variables dans Hobo ne sont pas supprimées quand on les supprime ajouté
#10

Mis à jour par Frédéric Péters il y a presque 2 ans

  • Statut changé de Nouveau à Fermé

#32147 existe déjà.

Formats disponibles : Atom PDF