Synthèse

Pourquoi une migration ?

Dans l’optique de vouloir proposer à nos utilisateurs une expérience mélangeant sans restrictions toutes nos fonctionnalités, nous avons décidé de repenser nos bases et revu plusieurs de nos mécaniques d’accessibilité tels que :

• Notre socle destiné à la gestion des profils que nous trouvions beaucoup trop rigide à l’utilisation, limité dans ses manipulations et exclusif au backoffice.

• La notion de groupe SWS, SWB et SWC qui était centrale à la problématique de cloisonnement.

• Les variables mélangeant la notion de paramétrage et d’activation. Parfois globale, parfois dans plusieurs groupes.

Qu’est-ce que la migration va changer pour moi ?

Un utilisateur final ne verra pas de changement. Il aura accès ou non à certains éléments comme avant.
Pour l'administration et le développement, la gestion de l’accessibilité via des autorisations de page et des fonctionnalités sera beaucoup plus flexible et visuel. En voici le détail :

• Nous parlons maintenant de permissions et de fonctionnalités.

  • Les tables concernant les permissions commencent par sw_data_permission et les tables concernant les fonctionnalités commencent par sw_data_feature.

  • Les permissions autorisent un utilisateur ou un device, via des profils, à avoir les capacités de création, suppression, modification et bien plus encore.

  • Les fonctionnalités ne sont plus mélangées avec de simple variable mais ont maintenant leur propre table avec tous les avantages qui en découle.

• Un nouveau paramétrage

  • Nous proposons de pouvoir manipuler et affecter chaque utilisateur et device indépendamment au sein d’un arbre de profils afin d’en accorder des capacités.

  • Il sera maintenant possible d’accéder à des fiches détaillant précisément l’accessibilité de chaque utilisateur, device et profil.

  • La nouvelle structure de profil par héritage permettra d'être extrêmement fin ou au contraire extrêmement générale dans l’affectation des capacités aux profils.

  • Nous mettons à disposition des modèles permettant d’appliquer rapidement des affectations standard à des utilisateurs ou devices depuis une fiche ou création de compte.

• Nouvelles syntaxes, refactorisation du backoffice et du mobile

  • Globalement, nous ne faisons plus référence aux anciens groupes SWS, SWB, SWC ainsi qu’aux anciennes tables de gestion des profils.

  • Sur le backoffice, en une seule condition, une capacité sera maintenant vérifiée parallèlement à sa fonctionnalité.
    Avant, nous devions appliquer deux conditions pour vérifier un profil et une variable avec beaucoup de chance de se tromper ou de simplement oublier de le faire.

    • feature.authorized.session ira vérifier l’activation de la fonctionnalité sur le projet

    • capacity.authorized.session ira vérifier l’autorisation de la capacité pour l’utilisateur courant ainsi que l’activation de sa fonctionnalité parente

    • Exemple :

      • feature.authorized.session avec la valeur Feature.Intervention vérifie que la fonctionnalité intervention est active sur le projet.

      • capacity.authorized.session avec la valeur Capacity.Intervention.Read vérifie que la fonctionnalité intervention est active sur le projet et que l’utilisateur courant possède l’autorisation nécessaire pour cette capacité (L’utilisateur doit être dans un profil associé à cette capacité).

  • Renommage des variables de session injectées lors du warmup (projectsettings) pour les fonctionnalités et les capacités :

    • Une fonctionnalité est vérifiable via la variable de session Feature.NomDeFeature

    • Une capacité est vérifiable via la variable de session Capacity.NomDeCapacity pour l’utilisateur courant

      • Certaines capacités particulières sont vérifiables pour les autres collaborateurs. Il s’agit des capacités Business et Service, vérifiables via les variables de session BaseuserIDsWithBusinessCapacity et BaseuserIDsWithServiceCapacity

  • Refactorisation du script Project.Settings sur le backoffice et l’extranet afin d’apporter plus d'homogénéisation et décomplexifier les briques fonctionnels.

  • Sur le mobile

    • Refactorisation du script d’initialisation permettant d’injecter les mêmes variables d’options qu’auparavant en se basant sur la table de mapping. La nouvelle syntaxe permettra d'apporter plus de souplesse au développement et préparer les futurs changements.
      Il est par exemple possible d’utiliser Intervention.Available comme avant mais aussi Feature.Intervention avec la nouvelle syntaxe.
      Nous conseillons de s’orienter vers Feature.MaFeature

    • Création d’une nouvelle page d’accueil unifiée qui ne tiendra plus compte des anciens groupes.

Pour qui s’applique la migration ?

Pour tous les projets ayant weavy 6.2 ou supérieur.

Comment migrer mon projet ?

Nous avons développé plusieurs outils qui travailleront ensemble pour appliquer les modifications nécessaires à votre projet.
Le point d’entrée sera l’extension divalto VSCode et sa commande de migration de projet.
Des connaissances techniques et de développement seront requises.

Avant de commencer, nous vous détaillons quelques points et prérequis dans la page suivante :
Avant de migrer