...
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 utilisateur et devices device 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
Globalement, nous ne faisons plus référence aux anciens groupes SWS, SWB, SWC ainsi qu’au anciennes tables de gestion des profils.
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.feature.authorized.
session ira vérifier l’accessibilité à la feature pour l’utilisateur courant
capacity.authorized.session ira vérifier l’accessibilité à la capacité et sa feature parente pour l’utilisateur courant
Renommage des variables de session injectées lors du warmup pour les features et la capacités :
Une feature est vérifiable via la variable Feature.NomDeFeature pour l’utilisateur courant
Une feature est vérifiable via la variable Feature.NomDeFeature.Baseuser_IDs pour les autres collaborateurs
Une capacité est vérifiable via la variable Capacity.NomDeCapacity pour l’utilisateur courant
Une capacité est vérifiable via la variable Capacity.NomDeCapacity.Baseuser_IDs pour les autres collaborateurs
Nouvelle table de cache exploitée pour consulter l’accessibilité d’un utilisateur sans avoir à le recalculer
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 ce basant sur la table de mapping. Ainsi qu’avec la nouvelle syntaxe pour apporter plus de souplesse au développement et préparer au futurs changements.
Il est par exemple possible d’utiliser Intervention.Available comme avant mais aussi Feature.Intervention avec la nouvelle syntaxe.Création d’une nouvelle page d’accueille qui ne tiendra plus des anciens groupes.
Pour qui s’applique la migration ?
...