Rôles

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")

Pré-requis

Codes activité

Les codes activités suivants (classés par type) peuvent avoir une influence sur le comportement de la fonction :

Codes activités dépendants

Ces codes ne sont jamais saisis en gestion de dossier, car leur valeur est calculée :

  AUDIT (Audit).

Fonctionnel

  ABI :  Business Intelligence

  ASD :  SData

  LEG :  Gestion multi-législations

Habilitations

Cette fonction est de type objet. Les opérations de création, modification, et suppression de fiche peuvent être activées ou désactivées pour un utilisateur donné. Des filtres par rôles peuvent également être mis en place sur cette fonction.

Autres pré-requis

Tables diverses

Les tables diverses suivantes sont utilisées par la fonction. Elles doivent donc être renseignées :

  Table diverse numéro 60 : Rôles

Pré-requis divers

Le nombre de rôles associés à un utilisateur donné est limité par le code activité AUB.

Gestion de l'écran

Ecran de saisie

 

 

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.

Messages d'erreur

Il n'y a pas de message d'erreur autre que les messages d'erreur génériques.

Tables mises en oeuvre

Les tables suivantes sont mises en oeuvre par la fonction :

Table	Intitulé Table
ACTIV [ACV]	Codes activité
AOBJET [AOB]	Objets de base
AROLE [ARL]	Rôles
ATABDIV [ADI]	Tables diverses
ATABLE [ATB]	Dictionnaire des tables
ATABZON [ATZ]	Dictionnaire des champs
ATYPE [ATY]	Types de données