You are not logged in.
Pages: 1
Topic closed
Bonjour,
je souhaiterais limiter la visibilité de certaines entités à un profil donné.
J'ai deux profils qui ont les mêmes caractéristiques, mais un doit pouvoir voir l'ensemble des entités et pas l'autre.
Comment faire pour réaliser cela sans ajouter manuellement chaque utilisateur sur chaque groupe?
(car j'ai plus de 100 utilisateurs concernés et plus de 600 groupes à mettre à jour).
J'utilise GLPI 0.7.1.3 en attendant impatiemment la 0.72 !
GLPI 0.90.5 - OCS 2.3.1 - Plugin OCS / GLPI 1.2.2
Offline
Offline
bonjour
on ne limite pas la vision des entités à des profils
on affecte des profils sur des entités pour des utilisateurs
si vous utilisez l'authentification ldap, je vous conseille de regarder du côté des règles d'affectation des entités et profils à des utilisateurs
Offline
Non non pas de confusion je pense. Juste un manque de claireté dans mon explication.
J'ai un schéma du style :
Entité Racine
-Entité 1
-Entité 2
-Entité 3
-Entité 4
-Entité 5
J'ai un profil commun à différents utilisateurs qui est basé sur la racine, mais je veux que certains utilisateurs ne puissent voir qu'une partie des entités sous la racine.
GLPI 0.90.5 - OCS 2.3.1 - Plugin OCS / GLPI 1.2.2
Offline
ce n'est toujours pas clair.
Un profil dans GLPI définit les actions réalisables sans aucune lien avec les entités.
Pour chaque utilisateur on choisit quel profile on lui associe pour les différentes entités.
Entité qui est le concept qui permet de cloisonné les choses.
Si on donne le profil X sur l'entité 1 à un utilisateur il ne verra que les données de cette entité.
Si on associe le profil Y sur l'entité racine de manière récursive, l'utilisateur aura accès à toutes les entités.
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Pour compléter
Si on donne le Profil X sur l'entité 1 et sur l'entité 2, l'utilisateur aura accès à ces 2 entités seulement.
++
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
J'avais bien compris mais je m'était mal exprimé.
Par contre un profil est donné à un utilisateur, et pas à une entité non ?
Sachant que mon schéma ressemble à ça :
Entité Racine
-> Entité A
-> Entité 1
-> Entité 2
-> Entité B
-> Entité 3
-> Entité 4
-> Entité C
-> Entité 5
-> Entité 6
-> Entité 7
-> Entité 8
J'ai un groupe d'utilisateurs X qui ont un profil A qui doit leur permettre de travailler sur l'ensemble des entités. J'ai donc mis ce profil A en récursif à partir de l'entité racine.
J'ai maintenant groupe d'utilisateurs Y qui ont un profil A aussi, mais qui eux ne doivent pas voir les entités 7 et 8 (mais bien toutes les autres).
Donc j'ai le choix entre :
- Déplacer les entités 7 et 8 -> pas possible puisque généré à partir du LDAP
- Associer les utilisateurs restreints en visibilité aux groupes qu'ils peuvent voir -> problème : plus de 100 utilisateurs et plus de 600 entités à mettre à jour manuellement...
Je ne vois pas d'autre solution en fait...
Si vous en voyez d'autre je suis preneur
Si ma réflexion est fausse je vous remercie de me rediriger dans le bon sens.
Cordialement
GLPI 0.90.5 - OCS 2.3.1 - Plugin OCS / GLPI 1.2.2
Offline
Tu donne 2 habilitations a ton utilisateur
- Profil A sur entité 7
- Profil A sur entité 8
Et le tour et joué.
++
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Tu donne 2 habilitations a ton utilisateur
- Profil A sur entité 7
- Profil A sur entité 8Et le tour et joué.
++
J'ai pas compris...
Le problème est de limiter l'accès en visibilité à certain utilisateurs sur certaines entités qui, "dans la logique", devraient être vues puisque la récursivité leur permet.
Maintenant ces entités sont sensibles, et visiblement mal placées, donc j'essaye de les "cacher" à certains.
GLPI 0.90.5 - OCS 2.3.1 - Plugin OCS / GLPI 1.2.2
Offline
J'avais effectivement mal lu, je croyais qu'il devait voir 7 & 8... pas qui devait tout voir sauf 7 & 8
Le plus simple est donc clairement de déplacer les entités sensibles dans une branche spécifique.
Sinon tu donnes autant d'habilitations que nécessaire, mais ça va être chiant :
- Profil A sur entité A (Récursif)
- Profil A sur entité C (Récursif)
- Profil A sur entité 5
- Profil A sur entité 6
Il verra tout sauf 7 & 8...
++
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Oui c'est bien ce qu'il me semblait aussi
Parce que bon une 100aine d'utilisateurs à mettre à jour sur plus de 500 entités, ça va nous faire beaucoup de clic...
Je pense qu'on peut clôturer ce topic à moins que d'autres solutions soient envisageables.
GLPI 0.90.5 - OCS 2.3.1 - Plugin OCS / GLPI 1.2.2
Offline
Non j'en ai pas d'autres à formuler.
Votre question soulève un point : l'importance d'une reflexion préalable et intensive sur la gestion des entités souhaitée.
Je clos
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Pages: 1
Topic closed