Gestion Droits d'Accès (GDA)

GDA

---

 

 

 

 

Gestion des droits d’accès (GDA)

Dans le but de pouvoir ouvrir Cegid Orli sur l’extérieur tout en contrôlant les droits de manipulation des données (mise à jour ou simple consultation), le principe de gestion des droits d’accès aux données permet, pour chaque utilisateur qui se connecte à la base de données via Cegid Orli, un contrôle permanent (effectué en direct) pour toutes les données accédées (sur lesquelles Cegid a prévu les GDA).

Le principe des GDA consiste donc à définir pour qui on va faire des filtres sur les données, ‎et quelles sont les données auxquelles ces utilisateurs ont ou n’ont pas accès.

• les GDA sont tous accessibles et s’utilisent comme décrit ci-dessous ; ‎il faut utiliser la fonction JP510

 

Fonctionnement

Les droits d’accès aux données sont gérés pour les utilisateurs connus informatiquement par le système via leur login saisi lors de la connexion à la base de données.

Plusieurs façons de gérer ces droits d’accès sont prévues selon le profil de l’utilisateur et le mode de gestion choisi pour les filtres :

Modes de gestion prévus :

• FICHES ASSOCIÉES
• DROITS DIRECTS
• FILTRES PRÉDÉFINIS

‎ 

Fiches associées

Ce mode de gestion n’est utilisable qu’au niveau utilisateur.

Il n’apparaît pas dans la gestion des groupes d’utilisateurs.

L’utilisateur est caractérisé par son profil.
‎Cette notion représente ce qu’il est par rapport à la base de données à laquelle il accède.

Il peut être du type « membre du personnel » (profil 000), ou correspondre à une notion physique gérée informatiquement dans Cegid Orli (exemple : profil Client 001, Fournisseur, 003, Atelier 004, etc…). Dans le second cas (l’utilisateur n’est pas un membre du personnel), la logique veut que cet utilisateur ne puisse avoir accès qu’aux données qui sont rattachées à sa propre représentation informatique. Il faut donc lui mettre un filtre par rapport à son propre code (son code client, son code fournisseur, son code atelier, etc…).

Pour ces profils, on saisit un filtre nommé « FICHE ASSOCIÉE » qui permet de saisir la représentation informatique de l’utilisateur dans le progiciel et ainsi, donner « naturellement » les droits d’accès aux seules données associées (un client ne voit que ses commandes, un atelier ne voit que ses ordres de fabrication, etc…).

Pour un profil type membre du personnel, on ne peut logiquement pas saisir un filtre sous la forme « fiche associée ».

 

Droits directs

Quel que soit le profil de l’utilisateur, ce mode de gestion des droits d’accès est disponible.

Il peut donc être utilisé au niveau utilisateur et groupe d’utilisateurs.

Cela permet de saisir directement l’entité à filtrer et les critères de filtres associés. Ce qui donne la possibilité de gérer ponctuellement et rapidement un filtre pour une personne ou un groupe précis. Par contre, cette méthode fait que le filtre est associé uniquement à l’utilisateur ou au groupe d’utilisateurs sur lequel il a été saisi en droits directs. Il n’est pas disponible pour d’autres.

 

Filtres prédéfinis

Comme pour le mode précédent, cette façon de gérer les filtres est disponible pour tous les profils et à tous les niveaux (utilisateur et groupe).

Ce mode de gestion impose un travail en deux temps : Il faut en premier définir quels ensembles de données on veut filtrer en créant une bibliothèque de filtres et ensuite, associer ces filtres aux utilisateurs et groupes, ce qui a l’avantage de pouvoir disposer de filtres communs à plusieurs personnes avec une répercussion automatique du filtre sur tous les utilisateurs et groupes associées en cas de modification de la bibliothèque. Par contre, cette méthode de gestion est un peu plus lourde que la précédente car elle impose de définir les filtres avant de saisir pour qui ils vont s’appliquer.

• Fonction JP510 : GESTION DES UTILISATEURS 
• Fonction JP533 : GESTION DES GROUPES UTILISATEURS 

 

Une fois qu’on connaît la population sur laquelle on veut appliquer les GDA, il faut saisir les filtres.

 

 

Entités filtrées

Pour pouvoir faire des filtres sur les données, on leur a associé des entités. Ces dernières permettent de codifier quelles sont les données principales sur lesquelles on sait gérer des filtres.

Un fichier (mis à jour uniquement par Cegid) permet de consulter quelles sont les entités de type sécurité sur lesquelles on sait gérer des droits d’accès.

• Fonction JP503 : TYPES D’ENTITÉS

 

Critères de filtres

Pour chaque entité, un écran permet de saisir des critères de filtres qui définissent des grands ensembles de données. A ce niveau on peut préciser quels droits on donne à ces ensembles de données : droits de mise à jour, droits de consultation seule ou interdiction.

• Fonction JP512 : DESCRIPTION DES FILTRES

 

Précautions de base

Il faut partir du principe que si vous souhaitez interdire une donnée d’une entité (ex : un client),
‎il faut aussi autoriser toutes les autres données de la même entité.

exemple :
je souhaite interdire le client CLI123 de la société 01 et le client CLI456 de la société 02.

Il faut alors créer 4 enregistrements :

Si vous ne saisissez que les deux dernières lignes, les autres clients seront considérés également comme interdits.

 

En résumé, il faut toujours créer un enregistrement « large » pour les données autorisées (exemple : avec un code société).

 

Description du contenu d’un filtre

 

exemple :
soit le Fichier article suivant :

Comportement d’un groupe d’enregistrements d’un filtre :

Filtre1

La lecture du filtre est :

Ligne1 = Autorisation de tous les articles dans la société 1
Ligne2 = Interdiction de tous les articles dans l’état 2

Le filtre 1 peut donc être décomposé en un ensemble d’enregistrements autorisés et un ensemble d’enregistrements interdits :

Ensemble autorisé :

-----ARTICLE (ART1)------------------SOCIETE(1)-------ETAT(0)-------------

-----ARTICLE (ART2)------------------SOCIETE(1)-------ETAT(1)-------------

-----ARTICLE (ART3)------------------SOCIETE(1)-------ETAT(2)-------------

Ensemble interdit :

-----ARTICLE (ART3)------------------SOCIETE(1)-------ETAT(2)-------------

-----ARTICLE (ART4)------------------SOCIETE(2)-------ETAT(2)-------------

 

Le comportement des deux types d’enregistrements à la sortie du moteur GDA est illustré sur le schéma suivant :

 

En résumé :

 

 

• Remarque : Enregistrements vides

----------------------------------------------------AUTORISE

(exemple : autorisation de tous les articles sans aucune condition)

----------------------------------------------------INTERDIT

(exemple : interdiction de tous les articles sans aucune condition)

 

Pour marquer visuellement l’enregistrement on interdit la saisie d’un enregistrement avec tous les critères à vide (sachant que vide signifie ‘quel que soit la valeur du critère’) :

 

Il faut positionner au moins un critère au joker % pour ce type d’enregistrements :

-%---------------------------------------------------AUTORISE

(autorisation de tous les articles sans aucune condition)

-%---------------------------------------------------INTERDIT

(interdiction de tous les articles sans aucune condition)

 

Articles similaires

Dans les fonctions permettant de créer une entité par rapport à une autre entité « similaire » de même type, les droits d’accès sont appliqués en consultation seulement sur l’entité servant de base à la création.

 

exemple :

Si vous souhaitez créer un article par AR001 en utilisant la création par similaire, en supposant que l’article à créer soit modifiable, et que l’article de base ne soit que consultable, la création sera quand même possible.

‎ 

Comportement d’un groupe DE filtreS :

 

Filtre1

 

Filtre2

 

Les deux filtres précédents sont équivalents au filtre suivant :

Filtre3

 

On peut donc reprendre le même raisonnement du schéma précédent.

Quel est alors l’intérêt d’avoir créé deux filtres ?
C’est la possibilité de distribuer ou personnaliser ces filtres par fonction et par webuser :

• pour le webuser1, j’applique le filtre 1 et 2 dans la consultation du stock
• ET uniquement le filtre 2 pour la saisie des articles
• ET pour le webuser2, j’applique le comportement inverse.

Ce paramétrage ne pouvait être effectué à l’aide du filtre 3 seul du fait que les enregistrements du filtre ne sont pas personnalisables par fonction et par webuser.

 

En résumé :

Entités filtrées par fonction

Le principe retenu est que dans chaque fonction (fonctions Cegid Orli), Cegid définit quelles sont les entités gérées. Cette information (lien fonction > entité filtrée) est renseignée par Cegid dans un fichier. Ce qui permet de savoir quelles sont par défaut les entités sur lesquelles sont appliqués les droits d’accès aux données dans la fonction concernée.

Fonction JP511 : GESTION DES FILTRAGES STANDARDS

 

Application des filtres aux utilisateurs et fonctions

Il faut déterminer à qui on associe les filtres pour donner des droits ou limiter l’accès aux données.

Pour les filtres sur les fonctions, ceux-ci sont appliqués par défaut s’ils sont saisis sur une entité associée la fonction.

On peut le cas échéant, exclure un filtre pour une fonction précise, c’est à dire outre passer ce droit d’accès correspondant. On peut également modifier le mode d’application d’un filtre qui donnait initialement un droit de « mise à jour des données », en le passant en mode « consultation seule des données » et ce, toujours au niveau d’une fonction précise.

Pour les filtres sur les utilisateurs (ou groupe d’utilisateurs), on va saisir un lien entre chaque « web utilisateur » ou « web groupe » et chaque filtres / entité qu’on veut appliquer.

 

Paramétrage du mode GDA

Dans le fonctionnement du mode GDA natif, les données des filtres GDA en mode consultation ne sont pas considérées dans une fonction Type Gestion.

 

exemple :

Filtre1

Le client CL1 en consultation ne peut pas être utilisé dans les fonctions de gestion tels que CL001/CD001/FA002...etc.

 

Paramétrage mode consultation

Il est possible de moduler le mode natif GDA en faisant exception à la règle « Dans une fonction de maintenance, on interdit toute action de maintenance sur les données en droit de consultation ». Cela n’est possible que pour les Fonctions/Entités positionnées par Cegid dans JP511.

 

exemple :

Pour l’entité TARIF (024), la coche positionnée par Cegid ‘Mode consultation’, permet d’avoir accès dans les fonctions de gestion à un tarif déclaré en consultation seule.

 

Les fonctions concernées sont :

CD001 : commande

CL001/CL001W03 : client & informations variables

CM001 : commande matière composant

FA002 : facture et avoir

 

Un tarif déclaré dans JP510 en consultation seule sera accessible dans les 5 fonctions cités ci-dessus, mais dans aucune autre fonction.

Cela vous permet d’interdire à un utilisateur la maintenance sur un tarif tout en lui laissant la possibilité de saisir des commandes, factures avec ce tarif.

Fonctions utilisés

Sous-fonction JP513 : APPLICATION DES FILTRES appelé via

Fonction JP510 : GESTION DES UTILISATEURS WEB

Fonction JP533 : GESTION DES GROUPES UTILISATEURS WEB

 

Sous-fonction JP514 : DROITS DIRECTS appelé via

Fonction JP510 : GESTION DES UTILISATEURS WEB

Fonction JP533 : GESTION DES GROUPES UTILISATEURS WEB

 

Particularités

 GDA sur Lieu

Certaines pièces, comme le bon de chargement portent le lieu seulement sans porter le magasin.

Dans ce cas, Cegid n’a pas créé de GDA lieux, mais a utilisé la GDA magasin avec un fonctionnement particulier, ceci pour éviter de complexifier le paramétrage et éviter des conflits avec les GDA magasins.

Le principe consistera à contrôler le droit d'accès utilisateur au lieu donné de l’entête du bon de chargement, ceci par le biais d'une lecture particulière des GDA magasins produits finis et matières (lecture sans code magasin avec obligation d'avoir saisi en paramétrage des GDA un droit d'accès sur le  lieu / tous magasins articles ou matières pour l'utilisateur donné). Il n'y aura pas de contrôle séparé entre lieux produits finis et matière, l'accès au lieu d'un côté y donnant droit de l'autre.

Ce principe « GDA sur lieu seul » est appliqué SEULEMENT sur les fonctions où le GDA s’applique sur un Chargement : LI070, LI071 et LI056.

‎ 

Récapitulatif

L’accès aux informations est géré par plusieurs fonctions, résumées dans le tableau ci-dessous :

‎ 

 

JP511 : Filtres Standard

JP511W01
Cette fonction référence la liste des différentes Entités/Fonctions pour lesquelles Cegid Orli gère la sécurité d'accès aux données

 

Une entité de gestion représente les "données ou fiches principales" utilisées dans le progiciel. Ces entités elles mêmes sont définies comme gérant la sécurité nativement dans le progiciel (gestion des entités). Une entité peut se retrouver dans différentes fonctions et une fonction peut être concernée par différentes entités.

Le contenu de cette liste ne peut être modifié par l'Entreprise mais l'application qui en est faite dans les programmes d'affectation/désaffectation des filtres peut être personnalisée par modification de certains filtrages standards dans des contextes donnés (programme, mode, utilisateur ou groupe).

Il est possible de suspendre momentanément les contrôles GDA pour un programme/entité donné à l'aide de la coche "Exclure".

En cas d'ajout de filtrages standards par Cegid dans les nouvelles versions du progiciel, ceux-ci seront pris en compte par défaut et l'entreprise devra faire sa personnalisation.

Modulation du mode natif :

Pour certaines entités/fonctions Cegid autorise la possibilité de moduler le mode natif d'appel des fonctions GDA.
exemple : permet de prendre en compte dans une fonction Type Gestion des données des filtres en consultation.

 

 

JP512 : Description des Filtres

JP512W01
Cette fonction gère une bibliothèque de filtres par entité

 

La sécurité d'accès aux données permet de restreindre l'accès aux DONNÉES en consultation ou maintenance en fonction de l'utilisateur ou du groupe.

 

Sa mise en œuvre nécessite :

• La définition des filtres 
• L'affectation des filtres aux utilisateurs ou groupes de sécurité
• Et enfin l'exploitation dans l'application à sécuriser à l'aide des objets métiers appropriés

‎

‎Une entité de gestion représente d'une manière synthétique les "données ou fiches principales" utilisées dans le progiciel. Ces entités sont définies comme gérant la sécurité nativement dans le progiciel et ne peuvent donc être modifiées par l'Entreprise. 

 

Principe des filtres prédéfinis :

Différents utilisateurs ou groupes d'utilisateurs peuvent nécessiter les mêmes droits d'accès pour une entité de gestion donnée. Afin d'en faciliter la gestion administrative, une notion de Filtre permet de référencer de manière unique ces droits d'accès afin de pouvoir ensuite les affecter aux différents utilisateurs ou groupes concernés. Un filtre peut porter sur une ou plusieurs entités de gestion. Pour chacune des entités de gestion concernée, le filtre est défini par une ou plusieurs combinaisons de valeurs des critères (champs) prévus pour les droits d'accès à l'entité donnée et peut permettre de définir les données auxquelles l'accès est interdit ou autorisé en consultation seule ou autorisé en consultation et mise à jour. 
‎
‎Dans cette fonction, chaque entité pouvant être sécurisée dispose d'une page autonome définissant les caractéristiques du filtre (pages des critères), de sorte on peut intégrer de nouvelles entités non gérées dans cette version. Par ailleurs chaque onglet possède un équivalent sous-programme pouvant être appelé indépendamment pour la définition du contenu des fiches (ou droits directs sur un utilisateur ou groupe). Pour l'exploitation des filtres appliqués aux utilisateurs/groupes dans le progiciel Cegid Orli, on se base sur des objets métiers standard définis pour chaque entité.

 

Description du contenu d'un filtre :

Chaque enregistrement précise s'il concerne une : 
‎Une interdiction d'accès ou 
‎une autorisation d'accès en consultation seule ou 
‎une autorisation d'accès en consultation et mise à jour. 
‎
‎Ainsi soit le filtre portant sur l'entité Client : Il peut être de type: 
‎filtre prédéfinis dans ce cas les critères Client sont saisis dans JP512. 
‎filtre Droits directs ou filtre fiche associée dans ce cas les critères Client sont saisis directement dans JP510 ou JP533. 
‎
‎

 

Définition du filtre

‎Application du filtre sur le login de l'utilisateur Cegid Orli JP510 ‎ou son groupe JP533

‎
‎Définition du filtre

‎Application du filtre sur le login de l'utilisateur Cegid Orli JP510 ‎ou son groupe JP533

 

‎Définition du filtre

‎Application du filtre sur le login de l'utilisateur Cegid Orli JP510 ‎ou son groupe JP533

‎ 

La saisie des jockers % et _ est autorisée. 
‎L'unicité des enregistrements ne tient pas compte des trois statuts.

exemple : Le filtre suivant n'est donc pas permis :

‎Lors de la suppression d'un filtre un message d'avertissement vous indique si ce filtre est déjà affecté à un utilisateur (JP510) ou un groupe (JP533).
‎Pour ne pas garder de filtres orphelins dans la base (sans enregistrement),
‎la suppression du seul enregistrement du filtre est interdite au niveau de la page des critères :
‎dans ce cas vous devez logiquement supprimer le filtre en entête). 

 

COMPORTEMENT DES FILTRES NULL (=filtre sans enregistrements) :

Dans JP512 de gestion des filtres prédéfinis on commence à saisir un filtre et on ne saisit aucun critère. On a donc la configuration suivante à l'écran : 
‎
‎Définition du filtre

‎ 

N.B. :
ne pas interpréter comme étant enregistrement null autorisé en mise à jour mais filtre sans enregistrement. ‎Pour ne pas compliquer la compréhension des filtres, la saisie des filtres NULL est en principe déconseillée . Si vous décidez d'utiliser ce type de filtre il n'a aucun effet quelque soit le paramétrage : 
‎
‎Application du filtre sur le login de l'utilisateur Cegid Orli JP510 ‎ou son groupe JP533

 

Entités :

1. Client
2. Article
3. Matière
4. Division commerciale
5. Commande client PF
6. Fournisseur
7. Magasin matière
8. Magasin PF
9. Commande fournisseur PF
10. Commande fournisseur Matière
11. Réservation fournisseur Matière
12. Tarif PF
13. Division production
14. Atelier
15. Passerelles import/export
16. Gestionnaire
17. Circuit fabrication PF
18. Tarif matière
19. Société
20. Division création
21. entité Personnalisée

‎

JP513 : Filtres Prédéfinis

JP513W01
Ce sous-programme permet l'application à l'utilisateur (ou groupe si appelé depuis JP533) des filtres préalablement définis par l'entreprise

 

L'administrateur dispose ici d'une liste de valeurs de tous les filtres gérés dans la bibliothèque des filtres.

Le bouton Détail à droite du filtre permet de consulter les données du filtre pour les différentes entités concernées.

Aucune modification des filtres prédéfinis n'est autorisée à partir de cet appel : la maintenance du filtre se fait dans la fonction de définition des filtres.

La page "Personnalisation par programme" affiche la liste des fonctions concernées par le filtre, avec la possibilité d'exclusion et de positionnement du mode d'utilisation en consultation seule. Attention, les fonctions exclues du filtrage standard au niveau le plus globale tout groupe tout utilisateur (JP511) n'apparaissent pas dans cette liste.

N.B. :
en cas d'ajout de filtrages standards (non exclus) dans les nouvelles versions du progiciel, ceux-ci seront appliqués par défaut, charge à l'entreprise de venir les exclure dans les fonctions concernées.

 

 

JP514 : Droits Directs

JP514W01
Ce sous-programme permet de définir des filtres directement sur un utilisateur (ou groupe si appelé depuis JP533) tout en laissant la possibilité de choisir le type d'entité

 

On associe un type de fiches à l'utilisateur et on définit son contenu.

Dans l'onglet Définition du filtre , le sous-programme charge la sous forme de définition des critères du filtre pour l'entité choisie. Pour chaque entité, la sous forme chargée ici possède un équivalent onglet géré dans la fonction de définition des filtres.

Dans l'onglet « Personnalisation par programme », l'administrateur peut exclure un filtre en limitant son impact à une liste de fonctions déduite des filtrages standards ou positionner le mode du filtre en consultation seule pour fonction/entité donnée.

Les fonctions exclus du filtrage standard au niveau le plus globale tout groupe tout utilisateur (JP511) n'apparaissent pas dans cette liste.