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é telles que :

• Notre socle destiné à la gestion des profiles 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 central à la problématique.

• 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 permissions autorisent à un utilisateur ou à un device, via des profils, d’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 que cela peut apporter.

• Un nouveau paramétrage

  • Nous proposons de pouvoir manipuler et affecter chaque utilisateurs et devices indépendamment au sein d’un arbre de profiles 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 profile.

  • 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.

  • Nous mettons à disposition des templates permettant d’appliquer rapidement des affectations standard à des utilisateurs ou devices depuis une fiche.

• Nouvelles syntaxes, refactorisation du backoffice et du mobile

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

  • Pour palier à la notion de groupe SWS SWB et SWC, il est maintenant possible de consulter l’accessibilité des autres utilisateurs.

Pour qui s’applique la migration ?

Pour tous les projets voulant migrer vers weavy 6.2.

Comment migrer mon projet ?

Nous avons développé plusieurs outils qui travailleront ensemble pour appliquer les modifications à votre projet.
Le point d’entré 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