La gestion des profils applicatifs (atelier de conception + vidéo)

De nombreuses applications nécessitent une gestion de profils qui n’est pas prévue dans l’annuaire de l’entreprise. C’est le cas des smartstarters, dans lesquels il est possible de définir, entre autres, les administrateurs et les demandeurs. La mise en place d’un tel mécanisme est spécifique aux besoins métiers, mais une logique peut être mutualisée. Cet article présente le principe de la gestion des utilisateurs afin de permettre le conditionnement des règles smartforms et workflow sur le rôle applicatif d’un utilisateur.

ProfilApplicatif
Un formulaire avec les différents éléments de cet atelier.

Conception

Nous allons créer deux smartobjects (smo) et trois vues dans cet atelier. Ces éléments peuvent être améliorés afin de répondre à d’autres règles métier.

  1. Le smartobject Permission ou Rôle
    • Propriétés : IdPermission Autonumber, Permission Text, Description Memo.
    • Association : (1) Permission.IdPermission avec (N) Utilisateur.Permission (relation 1 – N).
  2. Le smartobject Utilisateur ou Profil
    • Propriétés : IdUtilisateur Autonumber, Utilisateur Text, Permission Number.
    • Association : (1) Utilisateur.Utilisateur avec (1) votre smartobject ADUser.FQN (relation 1 – 1).  voir en fin de chapitre
    • Association : (N) Utilisateur.Permission avec (1) Permission.IdPermission (relation N – 1 dans ce sens : ) ).
  3. La vue List Editable sur le smo Permission
    • Pour permettre d’ajouter, éditer, et supprimer des permissions.
    • L’IdPermission n’est pas nécessairement affiché mais il est intéressant pour le concepteur de pouvoir le trouver facilement.
  4. La vue List Editable sur le smo Utilisateur
    • Pour permettre d’ajouter, éditer, et supprimer des utilisateurs.
    • L’utilisateur est le FQN d’une personne de l’AD (picker) et la permission est une permission de la liste précédente (dropdown list / radio button list).
  5. La vue Item sur le smo Utilisateur
    • Pour permettre d’afficher le nom et le profil de l’utilisateur connecté.
      1. Les champs Utilisateur et Permission sont présentés par des contrôles List Display
      2. La règle When the view executed initialize est enrichie d’une action Execute a SmartObject method : le smo Utilisateur et la méthode Get List. A la page de paramètre d’entrée on envoie le FQN à la propriété Utilisateur et à celle de paramètre de sortie on récupère les valeurs Utilisateur et Permission.

  A l’usage, l’association avec le smo AD ralentie considérablement l’affichage des interfaces, je la déconseille mais je laisse la ligne dans le tuto puisque cela est présent dans la vidéo. #fainéant

Cas d’usage

Dans un smartforms, on se repose sur la vue Item Utilisateur. En l’insérant dans un formulaire, vous récupérez le rôle (l’IdPermission) de l’utilisateur. Il suffit, par exemple, de mettre en place une règle sur le changement du contrôle Permission pour effectuer les actions voulues : afficher / masquer une vue ou un contrôle ; rendre éditable / en lecture seule …

Dans un processus, on se repose sur le smo Utilisateur. L’appel pour récupérer le rôle d’un utilisateur est le même que dans la vue item plus haut. On peut aussi trouver tous les utilisateurs partageant le même rôle, pour leur attribuer une tâche par exemple. Dans ce cas, le paramètre d’entrée n’est plus le FQN mais l’IdPermission.

La vidéo

C’est tout pour cette fois, cheers !

benjamin

Technical Specialist @t K2 France ----- Twitter : @benjaminbertram ----- LinkedIn : Benjamin Bertram

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.