Rôles
La gestion des rôles permet de définir, en gestion d'objet, des filtrages des données de façon très sélective, en fonction de l'utilisateur. Elle est particulièrement utile pour filtrer des données devant être présentées à des utilisateurs connectés depuis l'extérieur (par exemple par l'interface Web). En effet, elle permet, par exemple, de ne présenter, en saisie des commandes, que les commandes passées par un client ou payées par ce client (qui est supposé être l'utilisateur).
Principes de fonctionnement
Cette gestion se base sur :
- la définition de codes rôles (client, payeur, représentant, fournisseur...) de façon très libre dans une table diverse (la table numéro 60)
- l'association, pour les objets sur lesquels on désire établir un filtrage, d' un champ de la table principale avec le code rôle. C'est cette association qui permettra d'établir le critère de filtrage des données. La gestion des rôles documentée ici permet de définir ces associations.
- de façon opérationnelle, l'attribution, dans la fiche utilisateur, d'un ou plusieurs rôles avec les codes correspondants (30 au maximum). C'est cette attribution qui définira les filtres automatiques dans les gestions d'objets concernées.
Dès lors que ces paramétrages sont définis, et que des rôles (et les codes correspondants) ont été définis dans la fiche utilisateur :
- Un filtrage est fait dans l'objet (liste gauche, fenêtres de sélection) sur le ou les codes définis dans la fiche utilisateur
- Un contrôle est fait lors de la création sur les champs filtrés.
- Un filtrage peut être réalisé dans le requêteur.
Remarques et limites
Attention, le filtrage a les limites suivantes :
- Le filtrage liste gauche se fait uniquement sur les champs de la table principale de l'objet (pas de filtrage non plus sur le picking)
- En cas de saisie de clé interdite sans passage par la sélection, la saisie est acceptée dans un premier temps, le contrôle ne se faisant à la fin. Pour contourner cette limite, il est possible de réaliser des contrôles de rôles en temps réel sur certains champs en spécifique, et ce de façon très simple, en utilisant l'action CROLE comme action de contrôle. Ceci n'est pas réalisé en standard car la généralisation sur tous les champs provoquerait de nombreux échanges entre client et serveur alors qu'en général on fait ce type de contrôle sur très peu de champs.
- le filtrage induit par les rôles n'est pas géré par les états standards (cela serait impossible vu les possibilités extrêmes de paramétrage), ni par les consultations standard. Il convient donc de créer des états particuliers si on désire les rendre accessibles à des utilisateurs extérieurs (mais ceci est possible en jouant sur les codes d'accès pour dédier des états spécifiquement filtrés à ces utilisateurs).
- un filtrage massif de données dans une table dont la liste gauche n'est pas forcément ordonnée selon le critère filtrant peut être très pénalisant en terme de temps de réponse. Il est donc conseillé d'utiliser des index d'optimisation et de les déclarer dans la liste gauche.
Dans le cas où plusieurs rôles sont définis dans la fiche utilisateur, la règle est la suivante :
- si les rôles sont identiques et la clé associée est différente, on fait un ou logique entre les conditions.
- si les rôles sont différents, on fait un et logique entre les conditions.
Exemples
Quelques exemples permettront d'illustrer cette logique. On désire filtrer :
- les articles par code acheteur (champ BUY associé à l'objet ITM pour le rôle acheteur)
- les commandes d'achat par fournisseur (champ BPSNUM associé à l'objet POH pour le rôle fournisseur)
- les commandes d'achat également par code acheteur (champ BUY associé à l'objet POH pour le rôle acheteur)
Si l'utilisateur JOHNDOE possède le rôle acheteur pour les codes MARTIN et DURAND, et le rôle fournisseur pour les codes DUPONT, DUPUIS, et DUMONT, on aura les filtres suivants :
- En saisie de commande fournisseur, on ne verra que les commandes passées au fournisseur DUPONT, DUPUIS, ou DUMONT, et ce par les acheteurs MARTIN ou DURAND.
- Si on crée une commande, la fenêtre de sélection des acheteurs et des fournisseurs filtrera correctement les acheteurs et les fournisseurs autorisés. Par contre, si on saisit un code interdit, il ne sera contrôlé qu'au moment où on tente de valider la commande.
- Les articles commandés seront aussi filtrés en direct au moment de leur sélection en fonction des acheteurs. Là encore, si on saisit un article non acheté par un des acheteurs, le contrôle se fera en validation de commande.
- Par contre, on ne filtre pas l'affichage d'une commande sur les articles (si des commandes fournisseurs ont été passées sur des articles normalement filtrés pour l'utilisateur, on pourra les sélectionner, mais in fine leur modification sera refusée).
L'implémentation technique se fait par l'ajout de filtres sur la table gérée dans la gestion d'objet, de façon automatique. Ces filtres sont à la fois actifs dans la sélection standard et dans la liste gauche. Soit un exemple plus technique. Si on définit les associations suivantes pour le rôle client (défini par exemple avec le code BPC), et le rôle commercial (défini par exemple avec le code REP) :
- dans l'objet SIH (facture client), le rôle BPC induit un filtrage sur le champ BPR (code tiers facturé).
- sur l'objet SOH (commande client), le rôle BPC induit un filtrage sur le champ BPCORD (client commandeur).
- sur l'objet BPC (client), le rôle BPC induit un filtrage sur le champ BPCNUM (code client).
- sur l'objet SOH (commande client), le rôle REP, induit un filtrage sur le champ REP (représentant).
Si un utilisateur possède dans sa fiche le rôle BPC associé au code MARTIN, on fera automatiquement un filtre sur l'objet SIH : (BPR="MARTIN"), sur l'objet SOH (BPCORD="MARTIN"), et sur l'objet BPC (BPCNUM="MARTIN").
Bien entendu, seuls les filtres correspondant à un rôle associé à l'utilisateur sont activés. Ainsi, si l'utilisateur n'a pas de rôle BPC dans sa fiche, le filtres définis ci-dessus ne seront pas faits : l'utilisateur verra donc toutes les commandes, toutes les factures, et tous les clients (sous réserve que d'autres filtres - par groupe de sites, par d'autres rôles par exemple - n'aient pas été définis pour l'utilisateur).
L'illustration par l'exemple de la composition de plusieurs filtres est la suivante :
- si l'utilisateur a trois fois le rôle BPC avec les clients MARTIN, DURAND, et DUPUIS, le filtre sur la fiche client sera :
(BPCNUM="MARTIN" or BPCNUM="DURAND" or BPCNUM="DUPUIS") - si l'utilisateur a à la fois le rôle BPC associé au code MARTIN, et le rôle REP associé au code DUPUIS, le filtre réalisé sur la gestion des commandes sera :
(BPCORD="MARTIN") and (REP="DUPUIS")
Gestion de l'écran
Ecran de saisie
Présentation
La définition des rôles se fait dans une saisie globale en tableau, dans lequel on définit, pour chaque code rôle et par objet concerné, sur quel champ le filtre agit.
Champs
Les champs suivants sont présents dans cet onglet :
Tableau
|
Le rôle permet de contrôler l'accès à plusieurs fonctions(OBJets). Il est possible de rattacher à un même rôle plusieurs OBJets.Par exemple, on peut définir le rôle modification d'une pièceclient et considérer que l'OBJet BIC saisie d'une facture etl'OBJet SOH saisie d'un commande client ne sont accessibles quepour certains clients. Pour chaque OBJet, il faut définir un champ sur lequel se ferale contrôle. Dans l'exemple ci-dessus, on pourrait définir leschamps BPR Tiers et BPCORD Client commande. Les autorisations d'accès sont définies dans la gestion desutilisateurs. Les rôles sont répertoriés dans la table diverse 60. |
|
|
|
|
Boutons spécifiques
Ce bouton permet de copier un rôle vers un autre dossier accessible depuis le serveur où se trouve le dossier courant. |