Permissions
Une permission est un droit ou une autorisation accordée à un utilisateur ou un groupe d'utilisateurs pour effectuer certaines actions sur un système ou un contenu. Les permissions déterminent ce qu'un utilisateur peut faire avec un contenu spécifique, comme lire, modifier, créer, supprimer ou gérer. Les permissions peuvent être définies de manière détaillée pour chaque utilisateur ou groupe, afin de contrôler l'accès aux ressources et de garantir la sécurité des données.
Permissions dans un site
La première étape consiste à définir des permissions sur les sites. En standard, les sites reflètent les différents états du produit, ce qui permet d'attribuer des permissions différentes en fonction de l'état du produit. Dans chaque site, il est possible de définir les membres et leurs rôles en cliquant sur "membres du site". Les membres peuvent être ajoutés individuellement ou par le biais de groupes.
Une permission est une règle définie par :
- Un groupe utilisateur ou un utilisateur (pour rechercher un utilisateur ou un groupe, il faut taper les 3 premières lettres du nom) ;
- Un rôle :
- Lecteur : Peut consulter le contenu.
- Contributeur : Peut consulter et modifier l'ensemble des contenus, créer de nouveaux contenus.
- Collaborateur: A l'autorisation de consulter, modifier, créer et supprimer l'ensemble du contenu.
- Gestionnaire: A l'autorisation de consulter, modifier, créer et supprimer l'ensemble du contenu. Il peut inviter des personnes et gerer les permissions sur le site.
- Gestionnaire de version : Peut ranger une branche/version vers ce site et consulter du contenu. (ex: ranger une branche vers sa version validé, l'utilisateur doit être gestionnaire de version sur le site validé)
Rôle | Consulter le contenu | Modifier le contenu | Créer du contenu | Supprimer du contenu | Ajouter des utilisateurs | Ranger une branche |
---|---|---|---|---|---|---|
Lecteur | Oui | Non | Non | Non | Non | Non |
Contributeur | Oui | Oui | Oui | Non | Non | Oui |
Collaborateur | Oui | Oui | Oui | Oui | Non | Oui |
Gestionnaire | Oui | Oui | Oui | Oui | Oui | Oui |
Gestionnaire de version | Oui | Non | Non | Non | Non | Oui |
Dans le cas de conflit, l'accès le plus permissive s'applique.
Note : Nous vous recommandons de gérer les permissions via des groupes afin d'appliquer des règles et permissions de manière collective, plutôt que de façon individuelle, ce qui simplifie l'administration et le contrôle des accès.
Permissions dans l'entrepôt
Permissions sur un dossier
Les permissions du parent sont héritées par le contenu et il est aussi possible d'ajouter des autorisations locales pour chaque contenu (par exemple un dossier ou document) via le bouton « Gérer les permissions ». Cela permet d'affiner les droits des utilisateurs pour des dossiers spécifiques.
La permission est l'association:
- Un groupe utilisateur ou un utilisateur (pour rechercher un utilisateur ou un groupe, il faut taper les 3 premières lettres du nom) ;
- Un rôle :
- Lecteur : A accès en lecture au contenu.
- Éditeur : Peut consulter et modifier le contenu existant, mais ne peut pas créer de nouveau contenu.
- Contributeur : Peut consulter, modifier l'ensemble des contenus et créer de nouveaux contenus.
- Collaborateur : Peut consulter, modifier, supprimer et créer du contenu.
- Coordinateur : A l'autorisation de consulter, modifier, créer et supprimer l'ensemble du contenu et gerer les permissions.
Il existe également un rôle spécial appelé propriétaire, qui est attribué au créateur d'un contenu. Le propriétaire a un accès complet au contenu qu'il ou elle a créé. Le rôle de propriétaire est désactivé dans beCPG, sauf pour les utilisateurs externes, et s'il est spécifiquement indiqué sur un nœud avec l'aspect Ownable. Un fournisseur par exemple même s'il n'est que contributeur dispose de permissions complètes sur le contenu qu'il a créé.
Rôle | Consulter le contenu | Modifier le contenu | Créer du contenu | Supprimer du contenu | Contrôle total |
---|---|---|---|---|---|
Lecteur | Oui | Non | Non | Non | Non |
Éditeur | Oui | Oui | Non | Non | Non |
Contributeur | Oui | Oui | Oui | Non | Non |
Collaborateur | Oui | Oui | Oui | Oui | Non |
Coordinateur | Oui | Oui | Oui | Oui | Oui |
Propriétaire | Oui | Oui | Oui | Oui | Oui |
Dans le cas de conflit, l'accès le plus permissive s'applique.
ex: 1.Un utilisateur a le rôle "Lecteur" sur le site, et "Coordinateur" sur le dossier alors il aura le rôle de "Coordinateur" pour tous les contenus du dossier . 2.Un utilisateur a le rôle "Coordinateur" sur le site, et "Lecture" sur le dossier alors la règle la plus permissive gagne. Il aura le rôle de "Coordinateur" pour tous les contenus du dossier .
Desactiver l'héritage des autorisations
Par défaut, les permissions des parents sont héritées, mais il est aussi possible de désactiver l'héritage des autorisations. Ainsi seules les autorisations locales seront appliquées sur ce document/dossier. Via le bouton « Gérer les permissions », cliquez sur "Héritez des autorisations" pour les désactiver.
ex: 1.Un utilisateur a le rôle "Lecteur" sur le site, et pas d'autorisation sur le dossier. L'héritage des autorisations est désactivé. Alors il n'aura aucun rôle pour tous les contenus du dossier et ne verra donc pas le dossier . 2.Un utilisateur a le rôle "Coordinateur" sur le site, et "Lecture" sur le dossier. L'héritage des autorisations est désactivé. Il aura le rôle de "Lecture" pour tous les contenus du dossier .
Les règles de sécurités (ACL)
Avant de créer des règles de sécurité nous vous conseillons de demander à beCPG.
beCPG permet de restreindre les accès à certains champs et/ou de restreindre /etendre les accès à certainnes listes d'un type par groupe d'utilisateurs. Le type peut être un type entité (produit fini, matière première, semi-fini ...) ou une liste (Composition, coût, Nutriment...). Pour cela, allez dans le dossier Système " Règles de sécurité » de l'administration et créez un dossier. Ce dossier correspond à un groupe de permissions (règle de sécurité) appliquées à un type dans beCPG.
Une fois le dossier créée, il se transforme en entité Groupe de permissions (ACL), éditer ses propriétés et choisir le type pour lequel la permission est activée :
ex : Ici nous choisissons de créer des permissions sur le type « Produit fini »
Les Permissions
Sur la liste « Permissions », définir les droits d'accès sur chaque propriété. Trois droits d'accès peuvent être établies :
- Lecture - Pas d'accès pour les autres : Uniquement des droits de lecture, les autres groupes n'ont aucun accès aux champs.
- Lecture et écriture - Lecture pour les autres: Droits de lecture et d'écriture, les autres groupes auront uniquement des droits de lecture.
- Lecture et écriture - Pas d'accès pour les autres : Droits de lecture et d'écriture, les autres groupes n'ont aucun accès aux champs.
Application des règles
Les règles de sécurité s'appliquent immédiatement dans l'interface beCPG sur le site.
Permission sur les champs
Ajoutez ainsi de nouvelles permissions à la liste de données via le bouton « Ajoutez». Selectionnez le droit d'accès, le nom de la propriété et le groupe :
Rappel: Les droits d'accès viennent restreindre les permissions héritées et non les étendre (ex: restreindre un droit d'écriture en lecture). Il n'est pas possible d'étendre les droits sur un champ (ex : ouvrir un droit de lecture en écriture* )
Permissions sur les listes
Dans les propriétés, les listes d'une entité sont aussi disponibles. Vous pouvez donc définir des droits d'accès spécifiques (ex: masquer la liste coût). Il est aussi possible d'étendre l'accès pour les listes. Dans ce cas, beCPG doit effectuer des modifications pour "activer la règle de sécurité".
Permissions locales
Les permissions locales s'appliquent spécifiquement à certains produits, plutôt qu'à l'ensemble des entités du même type, comme c'est le cas avec une permission classique. Pour créer une règle de sécurité locale, créez d'abord une règle de sécurité classique, puis sélectionnez "Permission locale".
Pour l’application de la règle aux produits de votre choix, deux méthodes s’offrent à vous :
- Ajoutez manuellement la règle aux produits : Cette approche permet de sélectionner individuellement les produits qui nécessitent des permissions. Il suffit d'accéder au produit en question dans beCPG et de lui appliquer directement la règle de permission. Vérifiez d’abord que l’aspect de sécurité fait partie des aspects actuellement sélectionnés: Cliquez ici L’ajout de cet aspect conditionne l’apparition du champ “Règle de sécurité” au niveau des propriétés du produit. Y ajoutez ensuite manuellement les règles créées dans l’administration.
Ajoutez sur le modèle la règle de sécurité local. Tous les entités utilisant ce modèle hériteront de la règle.
Ajoutez automatiquement la règle via une formule SPEL qui définit les conditions d’application. Cette formule, basée sur des critères spécifiques à chaque cas et peut-être appliquée à un modèle de produit afin de permettre une gestion plus efficace à grande échelle. exemple: vous pouvez créer une formule pour appliquer la règle de sécurité à tous les produits finis ayant un modèle spécifique. Cette méthode assure que les permissions sont correctement assignées sans nécessiter d'interventions manuelles répétitives.
Lecture seule par défaut
En cochant le paramètre "Lecture seule par défaut" , toutes les listes et champs du type sont considérés en lecture seule par défaut si aucune permission n'existe sur ceux-ci.
Permissions liées au portail fournisseur
Lorsqu'une entité est assignée au fournisseur, elle est déplacée dans le dossier du fournisseur dans le site portail fournisseur. Sur ce dossier, tous les comptes liés à ce fournisseur sont mis en "Coordinator".
Un external user ne doit être membre d'aucun site.
Permissions sur les rapports
Il est possible de définir des droits sur les fiches techniques afin de gérer finement leur consultation et/ou leur édition.
Pour ce faire:
- Aller dans: Entrepôt> Système> Rapports> Rapports de fiche produits;
- Sélectionner le dossier correspondant au type de produits dont vous souhaitez gérer les permissions sur les fiches techniques (PF,SF,MP);
- Placer le curseur sur la ligne correspondant à la fiche technique concernée et cliquer sur "Plus" puis "Gérer les droits d'accès";
- Si la configuration par défaut ne convient pas, c'est-à-dire si tout le monde n'a pas le droit de consulter la fiche technique en tant que "Lecteur", cliquer sur "Hériter des droits d'accès" pour faire passer le logo du "Check" à "Sens interdit" et pouvoir administrer vos propres droits;
- Cliquer sur "Ajouter un utilisateur/groupe" pour donner des droits sur cette fiche technique à certains utilisateurs ou groupes uniquement. Une fois l'utilisateur ou le groupe choisi, lui assigner un rôle (lecteur, collaborateur etc.).
- Cliquer sur "Enregistrer";
- Enfin, placer le curseur sur la ligne correspondant à la fiche technique concernée et cliquer sur "Plus" puis "Mettre à jour les droits d'accès".
Permissions sur les projets
Il est possible de définir des droits :
Soit sur des dossiers contenant spécifiquement des projets. Pour ce faire, consulter la doc à propos des permissions sur les dossiers disponible ici
Soit sur les projets individuellement. Pour ce faire:
- Aller dans le dossier contenant le projet en question;
- Placer le curseur sur la ligne correspondant au projet concerné et cliquer sur "Plus" puis "Gérer les droits d'accès";
- Si la configuration par défaut ne convient pas, c'est-à-dire si tout le monde n'a pas le droit de consulter le projet en tant que "Lecteur", cliquer sur "Hériter des droits d'accès" pour faire passer le logo du "Check" à "Sens interdit" et pouvoir administrer vos propres droits;
- Cliquer sur "Ajouter un utilisateur/groupe" pour donner des droits sur le projet à certains utilisateurs ou groupes uniquement. Une fois l'utilisateur ou le groupe choisi, lui assigner un rôle (lecteur, collaborateur etc.).
- Cliquer sur "Enregistrer".
N.B: un utilisateur ou un groupe défini en tant que "Lecteur" sur un projet ne pourra pas ajouter de nouvelles tâches ni modifier ou supprimer des tâches SAUF si elles lui sont assignées !
Ici, Jérôme en tant que lecteur ne peut pas modifier la tâche car elle ne lui est pas assignée:
Ici, Jérôme en tant que lecteur peut modifier la tâche car elle lui est assignée:
Permissions sur les dossiers de la liste documents
Il est possible de définir des droits sur les dossiers contenus dans la liste Documents des entités (ex : suppression de l'héritage des droits sur un dossier puis création de droits spécifiques) Ils sont définis au niveau des modèles et s'appliquent à toutes les entités associées à ce dernier.
Les droits s'appliquent à la création des entités ou sur les entités existantes lors de leurs formulations ou lors de la synchronisation des modèles.
Lors de la synchronisation des modèles, les droits des dossiers pour des entités existantes se synchronisent :
Soit les dossiers n'existent pas : ils sont créés avec les droits associés.
Soit les dossiers existent : si l'orthographe des dossiers est identique, les droits sont mis à jour
Dans le cas où les entités contiennent des dossiers différents de ceux présent dans le modèle:
Soit les dossiers sont vides : ils sont simplements supprimés
Soit les dossiers sont plein : ils sont conservés mais ils héritent automatiquement des droits du dossier parent. Si des droits pontuels avaient été déterminés au préalable, ils seront supprimés.
N.B: Les sous-dossiers héritent des droits du dossier dans lequel ils sont contenus.
Permissions sur les ordres de modification
La possibilité de créer et d'appliquer un ordre de modification est régie par un rôle assigné un groupe.
Il en existe 2 :
- beCPG Créateurs d'ordres de modification (CreateChangeOrder) :donne les droits pour créer un ordre de modification réaliser les simulations et l'analyse d'impact.
- beCPG Responsables d'ordres de modification (ApplyChangeOrder) : donne les droits pour appliquer l'ordre de modification.
beCPG Responsables d'ordres de modification et l'administrateur sont les seuls à pouvoir appliquer un ordre de modification.
Pour la Modification des droits d'un utilisateur référer à cette documentation