Actuellement les fichiers contenu dans /dyn sont à la fois des fichiers liés à l’application et des fichiers de configuration de l’instance.
Il serait souhaitable de ré-organiser le contenu de dyn. Ce ticket est là pour collecter les propositions et retours d’expérience en vue d’une proposition d’évolution.
Ma réponse s’appuie sur une visée d’utilisation des externals SVN, qui est une hypothèse très théorique. Le modèle est le suivant:
framework = SVNext => appli version publique = SVNext => appli version locale / forge locale = “/dyn” non effacé => appli locale sur environnement X
On pourrait imaginer de tout condenser en 4 fichiers:
-un fichier pour les paramètres liés à l’instance: favicon, identifiant de session, serveur de base, serveur annuaire, niveau de débug, …
-un fichier pour les paramètres liés à l’application: utilisation des nouvelles actions, droits hiérarchiques, version…
-deux fichiers pour la surcharge “custom” des éléments précédents
-les éléments de configuration “sans danger” pouvant être mis à disposition dans la table om_parametre: taille en pixel, URL système externe, …
Pour repartir de la liste actuelle des fichiers, en restant avec les même fichiers :
Fichiers liés à l’application, tout en restant surchargeables pour une version locale de l’application (répertoire /custom ?)
Fichiers de configuration, liés à l’instance, à placer dans un répertoire séparé pour pouvoir le laisser à la libre gestion de l’exploitation et non consultable par la majorité (mots de passe, URLs …):
Fichiers mixtes => à revoir
Autres éléments absents de /dyn qu’il serait souhaitable de pouvoir lier à l’instance pour indiquer à l’utilisateur dans quel environnement il se trouve quand il n’est pas en PROD: DEV, INT, … afin qu’il soit vigilant en PROD !