Produits Entr'ouvert » Hobo

SETTING_WHATEVER = json.loads("x") dans l'application

Sauf que souvent dans l'application ça ne commencera pas par SETTING, tu voulais ici écrire juste WHATEVER ? (genre on écrirait SETTING_NEWSLETTERS_CELL_ENABLED et ça mettrait NEWSLETTERS_CELL_ENABLED) ?

~~~

Ou plutôt WHATEVER ici c'est imaginé un nom d'application, SETTING_COMBO = {...} et ça taperait en vrac dans combo.

Mais l'unité, ce n'est pas l'application, c'est le service. (on a deux combo, genre).

Et les variables peuvent déjà être attachées à un service particulier si on les veut uniquement dans celui-là.

Frédéric Péters a écrit :

Et les variables peuvent déjà être attachées à un service particulier si on les veut uniquement dans celui-là.

Oui je pensais plutôt à ça, l'histoire d'une variable qui s'appliquerait à tous les services d'un même type a sa place dans les thèmes mais pas ici je pense.

Maintenant on peut imaginer des variables globales de setting aussi, par exemple pour la durée des cookies de session.

Je précise pour les types de données, ça vient de hobo.environment.models.Variable qui ne parse le JSON qu'on entre que si la chaîne démarre par [ ou {.

Mon utilisation première ce serait LDAP_AUTH_SETTINGS, mais en plus général tout ce qu'on met dans settings.json en fait (et c'est pour ça que la limitation de type me gêne un peu, DEBUG=True dans settings.json ça peut être bien pratique en prod, même si un DEBUG=<mon-IP> serait encore mieux, mais c'est pour un autre jour).

Ça a son utilité aussi pour prototyper des cellules JSON ou jouer avec le nouveau moteur de recherche du portail agent (et j'en oublie certainement).

Mettre le

tenant_settings.TEMPLATE_VARS[key] = value

dans un else pour éviter que les variables de type SETTING_FOO ne se retrouvent accessibles dans les templates (facilement lisibles via une cellule json, visibles dans des traces, ce genre de truc ; mais aussi parce qu'il n'ont rien à y faire de toute façon)

Ensuite ce qui me chiffonne un peu, c'est que les settings vont se retrouver partout, sur tous les logiciels, et par exemple la config ldap avec ses éventuels petits secrets, j'ai pas forcément envie de la voir répandue sur chrono ou combo... Voir dans quelle mesure on pourrait avoir « setting_prefix = 'COMBO_SETTING_' » et équivalent...? (genre via un settings.PROJECT_NAME.replace('-', '_').upper())

Thomas Noël a écrit :

Ensuite ce qui me chiffonne un peu, c'est que les settings vont se retrouver partout, sur tous les logiciels, et par exemple la config ldap avec ses éventuels petits secrets, j'ai pas forcément envie de la voir répandue sur chrono ou combo... Voir dans quelle mesure on pourrait avoir « setting_prefix = 'COMBO_SETTING_' » et équivalent...? (genre via un settings.PROJECT_NAME.replace('-', '_').upper())

Ils seront dans le hobo.json (donc sur la VM qui fait tourner combo/chrono/etc..) mais pas charger dans l'application elle même puisque pour LDAP_AUTH_SETTINGS on utilisera vraisemblablement une variable de service, la solution à ça nécessiterait de revoir le système de déploiement pour envoyer un hobo.json différent (sans les variables qui ne concerne pas ce type de brique, voir même un hobo.json par instance) à chaque brique.

Ça commence à compliquer outre mesure pour quelque chose qui ne devait être qu'un pis-aller :/

Frédéric Péters a écrit :

Ça commence à compliquer outre mesure pour quelque chose qui ne devait être qu'un pis-aller :/

Autant quand on me dit faut pas complexifier la fabrique de formulaire, ça s'entend, autant là pour un écran où personne ne va jamais j'ai plus de mal. Si on peut faire disparaître les settings.json je pense qu'on y gagne grandement.

Il y aurait un tour des settings.json à faire, sans doute, perso j'y imagine de la configuration LDAP (#6648) et FranceConnect (pas trouvé de ticket); côté combo depuis peu les trucs de recherche (#26260, #26261), il y a eu davantage mais ça arrive désormais à être lié à l'intégration graphique; côté welco il y a la gestion des permissions d'accès mais on arrête de toute fçaon welco.

Remplacer les settings.json où nous sommes les seuls à aller par ces variables dans Hobo avec comme argument qu'on sera les seuls à y aller, je n'accroche pas.

Et même dans Hobo la direction est à faire des écrans dédiés, spécifiques (comme la configuration des emails), plutôt que l'interface générique des variables.

Que ça puisse en certaines situations dépanner, j'entends, mais il y a quand même un coût à maintenir un espace supplémentaire de configuration.

Bref, sur ce patch, avoir l'assurance que ça va rester du dépannage, du temporaire, qu'on n'oubliera pas ça, est pour moi nécessaire.

Frédéric Péters a écrit :

Il y aurait un tour des settings.json à faire, sans doute, perso j'y imagine de la configuration LDAP (#6648) et FranceConnect (pas trouvé de ticket); côté combo depuis peu les trucs de recherche (#26260, #26261), il y a eu davantage mais ça arrive désormais à être lié à l'intégration graphique; côté welco il y a la gestion des permissions d'accès mais on arrête de toute fçaon welco.

Remplacer les settings.json où nous sommes les seuls à aller par ces variables dans Hobo avec comme argument qu'on sera les seuls à y aller, je n'accroche pas.

Non certaines personnes ne peuvent pas y aller, les CPFs, Mike est obligé de bidouiller des cellules JSON et se fait rétorquer qu'il ne faut pas faire comme cela; et je ne vois pas trop comment gérer un client qui voudrait pondre une cellule JSON tout en étant en SaaS.

Je suis tout à fait ouvert à prévoir une whitelist dans cette optique.

Non certaines personnes ne peuvent pas y aller, les CPFs, Mike est obligé de bidouiller des cellules JSON et se fait rétorquer qu'il ne faut pas faire comme cela; et je ne vois pas trop comment gérer un client qui voudrait pondre une cellule JSON tout en étant en SaaS.

Je ne vois pas en quoi ça aide la situation du développement de cellules JSON vu que le fichier de gabarit doit être sur le filesystem.

S'il y a à faire évoluer la manière dont on développe les cellules JSON, c'est intéressant, ayons cette discussion sur la liste, pas dans un ticket "permettre de taper des settings divers via hobo".

Frédéric Péters a écrit :

Non certaines personnes ne peuvent pas y aller, les CPFs, Mike est obligé de bidouiller des cellules JSON et se fait rétorquer qu'il ne faut pas faire comme cela; et je ne vois pas trop comment gérer un client qui voudrait pondre une cellule JSON tout en étant en SaaS.

Je ne vois pas en quoi ça aide la situation du développement de cellules JSON vu que le fichier de gabarit doit être sur le filesystem.

Objection retenue.

S'il y a à faire évoluer la manière dont on développe les cellules JSON, c'est intéressant, ayons cette discussion sur la liste, pas dans un ticket "permettre de taper des settings divers via hobo".

Il reste encore d'autres settings...

Pour moi ça irait mais 1/ soit déplacer ça hors de TemplateVars, 2/ soit préparer derrière un ticket qui réunirait en un unique HoboJsonSettings(?) une série de settings loaders (je dirais KnownServices, TemplateVars, CORSSettings, SharedThemeSettings).

Le taper avant SettingsJSON, que ce dernier reste prioritaire ?

Frédéric Péters a écrit :

Le taper avant SettingsJSON, que ce dernier reste prioritaire ?

J'ai un doute sur le plus pertinent: vaut-il mieux qu'un truc visible dans le BO s'applique avant ou après un truc planqué dans un fichier sur le disque ? À mon avis le BO devrait avoir la priorité sur le settings.json, dans l'ordre /etc, tenant-dir, puis BO. Non ?