Skip to main content

Gestionnaire des applications

Le module gestionnaire des applications App Registry dans Open ENT gère l'enregistrement, la configuration, et l'accès aux applications au sein de la plateforme. Il joue un rôle central dans l'organisation et la personnalisation des applications disponibles pour les utilisateurs en fonction de leurs rôles et de leurs besoins spécifiques.

Principales fonctions du module App Registry :​

  1. Enregistrement des applications :

    • Gestion des applications disponibles : Le module permet d'enregistrer différentes applications au sein de la plateforme. Cela inclut les applications internes (développées pour la plateforme) ainsi que les applications tierces (intégrées via des API ou des connecteurs).

    • Déclaration des applications : Chaque application peut être déclarée avec ses métadonnées, telles que le nom, la description, l'URL d'accès, les icônes, et autres informations nécessaires pour l'intégration. La déclaration d'une application se fait au démarrage par envoi d'un message EventBus.

  2. Configuration des applications :

    • Personnalisation des applications : Le module App Registry permet aux administrateurs de configurer les paramètres spécifiques des applications, comme les droits d'accès, les préférences d'affichage, et les paramètres de connexion.
    • Gestion des versions : Il est également possible de gérer les différentes versions des applications, assurant ainsi que les utilisateurs accèdent toujours à la version la plus appropriée.

  3. Contrôle d'accès et permissions :

    • Rôles et permissions : Le module permet de définir quels utilisateurs ou groupes d'utilisateurs peuvent accéder à quelles applications, en fonction de leur rôle (élève, enseignant, administrateur, etc.). Cela permet de personnaliser l'environnement de travail pour chaque utilisateur en fonction de ses besoins.
    • Accès sécurisé : Il s'assure que seules les personnes autorisées peuvent accéder à certaines applications sensibles, en intégrant des mécanismes de sécurité comme l'authentification et l'autorisation.

  4. Catalogue des applications :

    • Affichage pour les utilisateurs : Pour les utilisateurs finaux, le module App Registry fournit un catalogue d'applications disponibles, permettant une navigation facile et intuitive pour accéder aux outils dont ils ont besoin.
    • Filtrage et recherche : Les utilisateurs peuvent rechercher et filtrer les applications selon leurs besoins, facilitant l'accès rapide aux ressources appropriées.

  5. Interopérabilité et intégration :

    • Intégration avec d'autres modules : Le module App Registry s'intègre avec d'autres composants de la plateforme, comme le module Directory pour gérer les accès en fonction des utilisateurs et des groupes.
    • Connecteurs API : Il permet l'intégration d'applications tierces via des connecteurs API, élargissant ainsi l'écosystème d'outils disponibles au sein de la plateforme.

Catégorisation des applications (portail)​

La catégorisation des tuiles du portail est pilotée par la donnée (et non plus par un catalogue figé côté front) :

  • Modèle — chaque Application porte une propriété category (la catégorie d'affectation). Les métadonnées d'une catégorie (libellé, couleur, icône, ordre, visibilité) sont stockées dans un nœud ApplicationCategory. Une application sans category est classée dans « Autres ».
  • Administration — un module dédié du Dashboard (super‑admin) gère le CRUD des catégories et l'affectation des applications (glisser‑déposer) — voir Catégories d'applications. Les écritures passent par l'API d'administration (Neo4j).
  • Lecture par le portail — le portail obtient la table adresse → catégorie via un service en lecture seule dédié, puis regroupe les tuiles. Ce choix évite d'ajouter category à la projection de session : cela préserve la résolution de session des modules (un champ supplémentaire dans la session casse la désérialisation UserInfos du common embarqué par certains modules). La session n'est donc pas modifiée.
  • Prise en compte — une modification (création, renommage, réaffectation) est reflétée sur le portail après un recalcul de session (déconnexion / reconnexion). Côté application mobile, la même donnée sera exposée par un point d'API backend dédié (chantier mobile).