Apps
Une app Liberty est un espace de noms — un regroupement logique de connecteurs, écrans, menus, tableaux de bord, graphiques et jobs qui appartiennent à un domaine métier (CRM, facturation, administration JD Edwards, RH interne…). Le framework collecte le champ App de chaque entité au chargement et expose la liste résultante dans le sélecteur d'espace de travail de l'en-tête — changer d'espace de travail change la barre latérale vers l'arbre de menus de cette app.
Les apps ne sont pas un concept séparé à câbler — chaque constructeur Paramètres expose une liste déroulante App sur chaque entité. Cette page couvre le fonctionnement du sélecteur d'espace de travail, la manière d'empaqueter une app pour le transfert entre environnements et le motif de permission par app.
Vue d'ensemble
_default.sql:<app>-*:*, screen:<app>:*, menu:<app>:* — un rôle par app garde les choses propres.Comment une app est créée
Les apps n'ont pas d'action "créer" qui leur soit propre. Une app existe dès qu'une entité la référence. Ouvrir Paramètres → Connecteurs → Nouveau connecteur, saisir billing dans le champ App — billing est maintenant une app avec un connecteur. Ajouter un menu dans Paramètres → Menus → Nouveau menu avec la même valeur App, et le sélecteur d'espace de travail commence à afficher Billing.
Pour donner à l'app un libellé convivial, une icône et un ordre d'affichage, l'onglet Paramètres → Apps fournit les métadonnées par app :
| Champ | Effet |
|---|---|
| ID | L'identifiant de l'app — court, en kebab-case (billing, crm). Utilisé comme préfixe d'espace de noms partout. Le renommage déclenche une réécriture de chaque référence. |
| Nom affiché | Affiché dans le sélecteur d'espace de travail et comme en-tête de la barre latérale. Localisé via le dictionnaire. |
| Icône | Un nom d'icône Lucide. Apparaît à côté du nom de l'espace de travail. |
| Ordre | Détermine la position dans le sélecteur d'espace de travail. Les nombres les plus bas en premier. |
| Description | Texte libre — apparaît comme info-bulle dans le sélecteur d'espace de travail. |
Actions par ligne :
- ⬇ Exporter — produit un zip de chaque entité qui porte l'identifiant de cette app (voir Export / import).
- ✏️ Modifier — ouvre l'éditeur de métadonnées.
Le framework fonctionne encore avec des apps qui n'ont pas d'entrée de métadonnées — le sélecteur d'espace de travail affiche alors l'identifiant brut au lieu du nom convivial.
Le sélecteur d'espace de travail
L'en-tête affiche une puce d'espace de travail avec une liste déroulante. La liste déroulante liste chaque app dont l'utilisateur appelant peut voir au moins un menu (filtrée par les permissions par app), triée par Ordre puis alphabétiquement.
| Comportement | Quand |
|---|---|
| Sélecteur visible | Au moins deux apps ont des menus que l'appelant peut voir. |
| Sélecteur masqué | Une seule app (le cas par défaut pour les installations mono-locataire). |
| Mémorisé par utilisateur | Le dernier espace de travail choisi est enregistré dans localStorage. |
Un utilisateur avec la permission sur une seule app ne voit aucun sélecteur — le framework bascule directement sur cet espace de travail.
Conventions par app
| Convention | Raison |
|---|---|
| Un menu par app dans Paramètres → Menus. L'App du menu pilote la clé de l'espace de travail. | Déclarer un menu est ce qui rend l'espace de travail sélectionnable. |
Préfixer les connecteurs par l'app (billing-customers, crm-contacts). | Garde le catalogue des connecteurs lisible et évite les collisions quand deux apps interrogent la même base. |
Mettre les identifiants d'écran dans l'espace de noms de l'app (billing/invoices, crm/customers). | Le framework autorise le même identifiant d'écran dans deux apps ; l'espace de noms évite que le mauvais soit choisi. |
| Les entrées de dictionnaire peuvent être partagées. | Le dictionnaire est global par défaut — les libellés et tables de correspondance définis une fois sont référencés depuis chaque app. |
| Les jobs sont dans l'espace de noms de l'app (la liste déroulante App du constructeur de jobs). | Garde le catalogue Paramètres → Jobs organisé ; les jobs transverses au framework sont sous _default. |
Export / import
Les apps se déplacent entre environnements (dev → recette → prod) via le flux export / import de Paramètres → Apps.
Exporter
Cliquer ⬇ Exporter sur une ligne d'app, ou ouvrir l'éditeur de métadonnées de l'app et utiliser l'action Exporter. Le framework produit un zip qui contient :
| Chemin dans le zip | Contenu |
|---|---|
manifest.toml | Métadonnées : identifiant d'app, version, horodatage d'export, dépendances (autres apps requises), version du framework compatible. |
connectors.toml | Les entrées de connecteurs dont l'App correspond. Plus les pools qu'ils référencent (un avertissement apparaît quand un pool est partagé avec une autre app). |
dictionary.toml | Les entrées de dictionnaire référencées par les écrans de l'app (tables de correspondance, formats, libellés). |
screens.toml | Les écrans de l'app. |
menus.toml | L'arbre de menus de l'app. |
dashboards.toml | Les tableaux de bord de l'app. |
charts.toml | Les graphiques référencés par les tableaux de bord. |
jobs.toml | Les jobs Nomaflow de l'app. |
plugins/ (si présent) | Le répertoire de plugins entier (callables Python personnalisés). |
Le zip est téléchargé par le navigateur. Pour les exports multi-apps, cocher les cases sur chaque ligne + Exporter la sélection.
Importer
Cliquer ↑ Importer une app en haut de l'onglet Apps. Une boîte de dialogue demande le fichier zip, puis expose un aperçu de diff avant application :
| Section | Ce que l'aperçu affiche |
|---|---|
| À ajouter | Entités présentes dans le zip et absentes de l'installation. |
| À remplacer | Entités présentes dans les deux ; le diff est affiché en ligne ("changement de libellé", "colonne supplémentaire"). |
| À refuser | Collisions d'identifiants entre apps (par ex. le billing du zip entre en collision avec un écran existant). L'opérateur les clarifie avant Confirmer. |
Confirmer applique l'import en une transaction. Un échec revient en arrière ; l'installation reste sur son état précédent.
Pour les installations sous contrôle de version, le chemin plus simple est un patch git sur liberty-apps — la modification est relisible dans la PR, les imports partiels sont possibles et le retour arrière est git revert. Le flux zip concerne les installations qui ne partagent pas de dépôt git (apps client livrées par un fournisseur, données de démo).
Apps fournisseur livrées
Certaines apps sont livrées pré-construites par Nomana-IT — NomaUBL (facturation électronique), NomaSX-1 (maintenance de sécurité), NomaJDE (administration JD Edwards). Elles suivent la même convention : un identifiant d'app, un arbre de menus, des écrans, des tableaux de bord. Installer l'une d'elles est un Importer une app gouverné par licence — la liste features.apps de la clé de licence contrôle ce qui peut être importé.
Une app livrée est opaque pour le client au sens où le contenu est livré tel quel et est destiné à être utilisé tel quel, mais chaque entité reste visible et modifiable depuis l'interface Paramètres. Les modifications côté client survivent aux mises à jour fournisseur quand elles se trouvent dans un espace de noms client séparé (billing-customer à côté du billing du fournisseur) — voir Déploiement → Mise à jour pour la disposition recommandée.
Permissions par app
Le moteur de rôles s'intègre aux apps via le motif générique <surface>:<app>:*. Une paire de rôles typique pour une installation à deux apps :
| Rôle | Permissions |
|---|---|
| billing-user | sql:billing-*:*, screen:billing:*, menu:billing:*, dashboard:billing-* |
| crm-user | sql:crm-*:*, screen:crm:*, menu:crm:*, dashboard:crm-* |
Un utilisateur qui porte les deux rôles voit les deux espaces de travail. Un utilisateur qui ne porte que billing-user voit l'espace de travail Billing et n'a pas connaissance de celui de CRM. Voir Rôles et permissions.
Conseils et bonnes pratiques
- Choisir tôt les identifiants d'app. Renommer une app déclenche une réécriture de propagation, mais le chemin plus simple est de partir avec le bon nom. Les renommages sont pris en charge via l'action Renommer de l'éditeur d'Apps.
- Utiliser l'app par défaut pour les installations mono-locataire. Ne pas fabriquer un identifiant d'app juste pour remplir le champ.
- Grouper les connecteurs par app même en partageant un pool. Un
billing-invoices+billing-creditsqui interrogent le même pooldefaultest plus clair qu'invoices+credits. - Garder les entrées de dictionnaire partagées. Une table de correspondance
currencydéfinie une fois et référencée depuisbillingetcrmest préférable à deux définitions parallèles. - Exporter avant une mise à jour fournisseur sensible. Un instantané
billing.zipde l'état courant est un chemin de retour arrière en un clic si la nouvelle version fournisseur régresse.
Sous le capot
Le champ App de chaque entité est enregistré sur l'entité elle-même dans le TOML de section. Les métadonnées d'app (nom affiché, icône, ordre) sont enregistrées dans dictionary.toml → apps. Les opérateurs ne modifient pas ces fichiers à la main ; l'interface Paramètres est l'interface de référence. Le flux export / import fait des allers-retours par fichiers zip qui contiennent les mêmes extraits TOML ; l'onglet Apps est aussi la surface de référence pour cela.
Pour aller plus loin
- Plugins — callables Python personnalisés empaquetés avec les apps.
- i18n — ajout de langues et packs de libellés par app.
- Déploiement → Mise à jour — déplacer les personnalisations client à travers les mises à jour de framework et d'apps fournisseur.