Feature #5362
fermé
Attribution de droits d'un groupe/utilisateur à un autre
Ajouté par Emmanuel GRANGE il y a plus de 10 ans. Mis à jour il y a plus de 9 ans.
100%
Description
Bonjour,
Nous avons désormais plus de 2500 groupes, et plus de 4700 utilisateurs référencés par un annuaire LDAP sur notre portail .
Une société comme la notre ne cesse d'évoluer : Des services ou des fonctions (et donc leurs groupes) sont créés ou bien changent de noms, des personnes sont mutées ou remplacées, ...
La complexité et le contenu du portail ne cessant de croitre, nous nous heurtons régulièrement à de problèmes d'attribution de droits.
Dans un de nos précédent ticket, nous avions eu besoin de renommer quelques groupes, mais la procédure fut extrêmement compliquée (Modification de la base de données, redémarrage du portail, synchronisation manuelle...), et la mise en oeuvre eu des effets de Bore étrange (synchronisation qui boucle)
Nous aurions donc besoin d'évolution dans ce sens :
Principalement, nous aurions besoin de pouvoir remplacer un groupe/utilisateur par un autre, ce qui pourrait résoudre déjà pas mal de nos problématiques. Pour cette évolution, nous serions prêt à la subventionner.
Dans le même genre d'évolution qui a, je pense, aussi beaucoup d'intérêt, il serait intéressant de pouvoir attribuer à un groupe/utilisateur, les mêmes droits qu'un autre groupe/utilisateur.
Merci.
Fichiers
| Profil.png (161 ko) Profil.png | Maquette Profil | Cécile Bonin, 04/11/2014 10:52 | |
| droit.jpg (52,9 ko) droit.jpg | Stéphane Sallé, 23/02/2015 12:10 | ||
| droitbis.jpg (70,8 ko) droitbis.jpg | Stéphane Sallé, 23/02/2015 12:10 | ||
| server.log (7,26 ko) server.log | Stéphane Sallé, 24/02/2015 15:48 | ||
| Droits_apres.png (13,6 ko) Droits_apres.png | Stéphane Sallé, 24/02/2015 15:58 | ||
| Droits_avant.png (13,1 ko) Droits_avant.png | Stéphane Sallé, 24/02/2015 15:58 | ||
| execution.png (45,1 ko) execution.png | Stéphane Sallé, 24/02/2015 15:58 | ||
| traces.txt (4,37 Mo) traces.txt | Stéphane Sallé, 24/02/2015 16:00 | ||
| pom.xml (2,89 ko) pom.xml | Stéphane Sallé, 27/03/2015 15:31 | ||
| userpanel.jsp (31,1 ko) userpanel.jsp | Stéphane Sallé, 27/03/2015 15:31 |
Mis à jour par Emmanuel GRANGE il y a plus de 10 ans
Bonjour,
Merci de nous faire parvenir un devis sur cette évolution.
Mis à jour par David Lesimple il y a plus de 10 ans
- Statut changé de New à Feedback
Emmanuel GRANGE a écrit :
Dans un de nos précédent ticket, nous avions eu besoin de renommer quelques groupes, mais la procédure fut extrêmement compliquée (Modification de la base de données, redémarrage du portail, synchronisation manuelle...), et la mise en oeuvre eu des effets de Bore étrange (synchronisation qui boucle)
Nous aurions donc besoin d'évolution dans ce sens :
Principalement, nous aurions besoin de pouvoir remplacer un groupe/utilisateur par un autre, ce qui pourrait résoudre déjà pas mal de nos problématiques. Pour cette évolution, nous serions prêt à la subventionner.Dans le même genre d'évolution qui a, je pense, aussi beaucoup d'intérêt, il serait intéressant de pouvoir attribuer à un groupe/utilisateur, les mêmes droits qu'un autre groupe/utilisateur.
Au préalable, pour le changement de nom des groupes dans le LDAP, il auait en effet été préférable que l'identifiant ne soit pas le nom (CN) mais l'attribut objectGUID (voir domainMGI.properties). cela permettait de changer son nom sans impact dans le portail.
Quoiqu'il en soit, difficile de changer cela maintenant.
Pour le point : remplacer un groupe/utilisateur par un autre, c'est plutôt de ses droits d'accès dont tu parles non ?
Si je comprends bien, si j'ai 2 groupes A et B, si le groupe B vient d'être crée, cela revient à faire un couper/coller de droits d'accès dans le 1er cas, et un copier/coller de droits d'accès dans le second..
Est-ce que c'est conforme à ce que vous souhaitez ?
Mis à jour par Emmanuel GRANGE il y a plus de 10 ans
Oui, il s'agit bien des droits d'accès assignés à un utilisateur/groupe, et non pas hérités de l'appartenance d'un groupe.
Nous sommes intéressés, avant tout, par la copie des droits d'un utilisateur/groupe sur un autre utilisateur/groupe.
Il faudrait pouvoir choisir s'il faut remplacer tous les droits déjà existants, ou ajouter les nouveaux à ceux déjà existant.
Merci de faire 2 devis : avec et sans l'interface de choix.
Mis à jour par David Lesimple il y a environ 10 ans
Objet de l'évolution :
Depuis la partie Administration > Profil, après avoir sélectionné un utilisateur ou un groupe, la fiche
récapitulative est affichée. Une nouvelle action Affecter les mêmes droits... sera disponible dans le menu
Que voulez-vous faire ? et amènera vers une nouvelle page. Elle permettra de sélectionner
l'utilisateur/groupe depuis lequel les droits seront dupliqués et affectés à l'utilisateur/groupe courant. Il sera
possible de choisir si les droits de l'utilisateur/groupe source viendront remplacés de ceux de
l'utilisateur/groupe source ou si ils viendront en complément de ceux déjà existants.
Une fois la copie réalisée, les droits de la source et de la cible ne sont pas liés.
Mis à jour par Nicolas Eysseric il y a environ 10 ans
- Statut changé de Feedback à Assigned
- Assigné à mis à Cécile Bonin
Mis à jour par Cécile Bonin il y a environ 10 ans
- Sujet changé de Remplacer un groupe/utilisateur par un autre à Attribution de droits d'un groupe/utilisateur à un autre
- Statut changé de Assigned à In progress...
Mis à jour par Cécile Bonin il y a environ 10 ans
Bonjour,
Comment doit-on traiter le cas de figure de l'attribution des droits d'un utilisateur source à un utilisateur cible alors que l'utilisateur source appartient à un groupe ?
Par exemple l'utilisateur source A appartient au groupe G, et le groupe G a des droits sur telle application.
On souhaite attribuer les mêmes droits à l'utilisateur cible B.
2 solutions :
- le système ajoute des droits à l'utilisateur cible B de manière individuelle, pour l'application
- le système ajoute l'utilisateur cible B au groupe G (et donc automatiquement les droits)
Mis à jour par Emmanuel GRANGE il y a environ 10 ans
Bonjour,
L'outil ne doit gérer que les droits nominatifs.
Il ne doit pas ajouter les droits hérités (mais bien conserver l'héritage, si héritage il y a), ni les droits provenant de l'appartenance d'un autre groupe.
Nous utilisons un annuaire pour ce qui est du peuplement des groupes, et il ne faut pas que les groupes soient modifiés par un autre programme que notre annuaire. De plus, ces ajouts disparaitraient lors de la prochaine synchronisation.
Mis à jour par Cécile Bonin il y a environ 10 ans
Bonjour,
Ok, le système ne traitera pas le cas de figure pré-cité.
Le système traitera uniquement les attributions de droits nominatifs.
Bien sur, le système ne modifiera pas l'héritage des droits.
Seuls les droits spécifiques (sur les espaces et les applications) seront modifiés, et l'héritage descendant sera automatiquement modifié.
Nous n'avons pas parlé des droits sur les dossiers des applications GED.
Nous pourrions les traiter de manière optionnelle avec une case à cocher dans le formulaire : "Attribuer aussi les droits sur les dossiers", qui serait cochée par défaut.
Mis à jour par Emmanuel GRANGE il y a environ 10 ans
Effectivement, il faut aussi les droits sur les dossiers (partie importante de notre utilisation du portail).
Elle peut apparaitre comme une case à cocher, mais dans ce cas, il serait préférable que l'option soient cochée par défaut.
Je n'ai pas testé depuis longtemps, mais certains droits sur les dossiers étaient maintenus, même si les droits sur la GED étaient supprimés. Est-ce toujours le cas ? Et dans ce cas, comment agira l'outil ?
Mis à jour par Emmanuel GRANGE il y a environ 10 ans
Par contre, il faut que l'outil doit puisse aussi bien copier les droits d'un groupe, ou un utilisateur vers un autre groupe ou utilisateur.
Mis à jour par Cécile Bonin il y a environ 10 ans
Oui, il y a bien 4 possibilités :
- Attribution de droits d'un utilisateur à un utilisateur
- Attribution de droits d'un utilisateur à un groupe
- Attribution de droits d'un groupe à un utilisateur
- Attribution de droits d'un groupe à un groupe
Concernant les droits sur les dossiers, j'ai testé, il y a effectivement une anomalie, nous allons la corriger.
Si l'on supprime des droits d'accès à un utilisateur/groupe sur une application, il faut également supprimer ses droits sur les dossiers de cette application.
Mis à jour par Cécile Bonin il y a environ 10 ans
- % réalisé changé de 0 à 100
En plus de la présente évolution :
- Anomalie sur les droits dossiers corrigée
- Améliorations graphiques de l'écran Profil et des écrans de création / modification / consultation d'un utilisateur et d'un groupe
Mis à jour par Cécile Bonin il y a environ 10 ans
- Statut changé de In progress... à Resolved
- Anomalie sur les droits dossiers corrigée : cf commit https://github.com/CecileBONIN/Silverpeas-Core/commit/3aac058da6813880e3eb0722435b6ddf486d3805
cf PR https://github.com/Silverpeas/Silverpeas-Core/pull/570
Mis à jour par Cécile Bonin il y a environ 10 ans
- Fichier Profil.png Profil.png ajouté
Dans l'onglet Profil, l'utilisateur sélectionne un utilisateur ou un groupe (l'utilisateur ou le groupe cible), le système affiche sa fiche profil contenant ses droits actuels.
Dans le menu Que voulez-vous faire?, l'utilisateur choisit l'option Attribuer les mêmes droits d'accès.
L'utilisateur choisit l'utilisateur ou le groupe source.
Voir maquette.
4 cas de figure sont donc à considérer (1, 2, 3 et 4), avec pour chacune 4 possibilités (A, A et B, C et A, C et A et B) :
1) Attribution de droits d'un utilisateur à un utilisateur :
A- Ajouter aux droits actuels :
c'est-à-dire ajouter aux droits de l'utilisateur cible, ceux de l'utilisateur source.
- le système va chercher les droits d'accès (rôles) de l'utilisateur source, sur les espaces (et sous entendu les sous-espaces) et les applications, définis en droits spécifiques.
Le système ne prend en compte que les droits d'accès de l'utilisateur source, défini en tant qu'individu.
Le système ne prend pas en compte les droits d'accès de l'utilisateur source appartenant à un groupe. En d'autres termes, si l'utilisateur source appartient à un groupe, le système
ne prend pas en compte les droits d'accès de ce groupe sur les espaces et applications.
- le système attribue les mêmes droits d'accès (rôles) à l'utilisateur cible, sur chacun des espaces et applications concernés.
En d'autres termes, à chaque fois que le nom de l'utilisateur source apparait dans les acteurs jouant un rôle sur un espace ou une application,
le système y ajoute le nom de l'utilisateur cible.
L'héritage des droits est conservé.
Seuls les droits spécifiques sont impactés, et l'héritage descendant sera automatiquement modifié.
B- Attribuer aussi les droits sur les dossiers de la GED :
Fonction optionnelle.
Mode de fonctionnement similaire à ce qui est fait sur les espaces et les applications, appliqué aux dossiers des applications de GED.
- le système va chercher les droits d'accès (rôles) de l'utilisateur source, sur les dossiers de toutes les applications de GED, définis en droits spécifiques.
- le système attribue les mêmes droits d'accès (rôles) à l'utilisateur cible, sur chacun des dossiers concernés.
C- Remplacer les droits actuels :
c'est-à-dire remplacer les droits de l'utilisateur cible par ceux de l'utilisateur source.
- le système supprime les droits actuels de l'utilisateur cible sur tous les espaces, applications définis en droits spécifiques, de manière nominative.
Si l'utilisateur n'a plus de droits sur une application de GED, le système supprime également ses droits sur les dossiers de cette application.
- puis le système attribue les droits de l'utilisateur source (cf cas d'utilisation A et B).
2) Attribution de droits d'un utilisateur à un groupe :
Même mode de fonctionnement que le 1), avec attribution des droits de l'utilisateur source au groupe cible.
- Le système ne cherche que les droits de l'utilisateur source, définis en tant qu'individu.
Le système ne prend pas en compte les droits d'accès des groupes auquels appartient l'utilisateur source.
- dans le cas du remplacement de droits, si le groupe cible ou les membres de ce groupe n'ont plus de droits sur une application de GED, le système supprime également les droits de ceux-ci sur les dossiers de cette application.
- le système attribue les mêmes droits d'accès (rôles) que l'utilisateur source au groupe cible, sur chacun des espaces, applications, dossiers concernés.
En d'autres termes, à chaque fois que le nom de l'utilisateur source apparait dans les acteurs jouant un rôle sur un espace, une application ou un dossier
le système y ajoute le nom du groupe cible.
3) Attribution de droits d'un groupe à un utilisateur :
Même mode de fonctionnement, avec attribution des droits du groupe source à l'utilisateur cible.
- Le système ne cherche que les droits du groupe source, définis de manière nominative.
Le système ne prend pas en compte les droits d'accès de chacun des utilisateurs appartenant au groupe.
4) Attribution de droits d'un groupe à un groupe :
Même mode de fonctionnement, avec attribution des droits du groupe source au groupe cible.
Mis à jour par Yohann Chastagnier il y a environ 10 ans
- Statut changé de Resolved à Closed
Validé et intégré.
Mis à jour par Emmanuel GRANGE il y a presque 10 ans
Le développement est terminé, mais peut-on connaitre la date ainsi que la version du portail de livraison ?
Mis à jour par Sebastien Vuillet il y a presque 10 ans
La version 5.14.3 devrait sortir aujourd'hui.
Mis à jour par Stéphane Sallé il y a presque 10 ans
Bonjour,
Je suis en cours de test de l'évolution, j'aurai quelques questions à ce propos :
- Pour le moment, tous les utilisateurs qui ont accès à l'onglet profil peuvent utiliser la fonction "Attribuer les mêmes droits d'accès", nous ne savons pas encore si les utilisateurs pourront utiliser cette fonction ou si elle sera réservée aux Admins du portail. Est-ce simple pour vous de la rendre disponible qu'aux admins ?
- Dans le cas de figure où la personne qui lance la fonction d'attribution n'a pas accès à tous les espaces du portail, est ce que l'attribution ou le changement de droit sera effectif sur le portail complet ? (même les espaces auquel le user n'a pas accès).
- J'ai bien noté que je pouvais voir l'ensemble des droits sur les applications dans le profil d'un groupe ou d'un utilisateur. Mais ai-je la possibilité de voir les droits spécifiques et les droits sur les dossiers d'une GED ?
Merci pour vos réponses
Mis à jour par Cécile Bonin il y a presque 10 ans
Bonjour,
Voici quelques éléments de réponse :
- Le fait de rendre disponible cette fonction uniquement aux Administrateurs du portail est une petite évolution simple à mettre en oeuvre
- Oui l'attribution de droits se fait sur le portail complet. Les droits de l'utilisateur qui lance la fonction ne rentrent pas en ligne de compte.
- L'affichage du profil reprend l'ensemble des droits sur les applications (droits hérités et droits spécifiques). Les droits sur les dossiers des GED ne sont pas affichés.
Mis à jour par Stéphane Sallé il y a presque 10 ans
Bonjour,
Je viens de tester le premier cas à savoir :
Ajout des droits d'un utilisateur à un autre sans droits sur les dossiers de GED.
J'ai selectionné un user dans "Profil", ensuite "attribuer les mêmes droits d'accès".
Je choisi l'utilisateur source, choix Ajouter aux droits actuels et décoche de "attribuer aussi les droits sur les dossiers de la GED". Je clic sur OK, et instantanément j'ai le message "Les droits ont été attribués".
Quand je compare les droits des 2 utilisateurs (par le profil) je m'aperçois que l'utilisateur source à accès à une certaine GED alors que l'utilisateur cible n'y a pas accès. Si je vérifie également via le portail et non le backend, l'utilisateur cible, n'a pas d'accès.
J'ai bien activée l'évolution via ce fichier :
$SILVERPEAS_HOME/properties/org/silverpeas/jobOrganizationPeas/settings/jobOrganizationPeasSettings.properties
et le paramètre admin.profile.rights.copyReplace.activated à passer à true.
Ai-je oublié quelque chose ou il y a un problème ?
L'évolution est disponible sur notre portail de test.
Merci
Stéphane
Mis à jour par Yohann Chastagnier il y a presque 10 ans
Bonjour,
Si j'ai bien compris votre test, vous avez attribué les droits d'un utilisateur U_Source vers un utilisateur U_Dest via une opération d'ajout (c'est à dire que les droits existants de U_Dest ne sont pas écrasés), et en indiquant que les droits des dossiers ne devaient pas être attribués.
Cette opération achevée, lors de la vérification des droits de U_Source et U_Dest, vous avez remarqué que U_Source avait accès à une GED G et pas U_Dest.
Peut-être que U_Source a un droit d'accès sur G via son appartenance à un groupe Grp et que c'est ce groupe qui est spécifié dans les droits d'accès à G et pas U_Source.
Dans cette hypothèse, il est normal que l'attribution des droits de U_Source vers U_Dest ne change rien pour U_Dest en termes de droits sur G (cas reproduit sur nos serveurs). En effet, l'opération étant une copie de droits utilisateur vers un autre utilisateur, les droits que possède l'utilisateur via une appartenance à un groupe ne sont pas pris en compte.
Toujours dans cette hypothèse, pour que des droits d'accès sur G soient spécifiquement attribués à U_Dest il faudrait attribuer les droits de Grp à l'utilisateur U_Dest.
Une autre solution, toujours dans cette hypothèse, serait de ne pas passer par cette fonctionnalité et d'ajouter U_Dest dans les liste des utilisateurs de Grp.
Bien sûr, pour ces deux précédents exemples d'attribution de droits et à l'instant t, il faut être certain que U_Dest peut bien avoir exactement les mêmes droits d'accès que Grp.
Merci de bien vouloir vérifier cela.
Cordialement.
Mis à jour par Stéphane Sallé il y a presque 10 ans
Bonjour,
Oui désolé autant pour moi, sur ce point là, le user_source avait les droits par un groupe.
Merci
Mis à jour par Stéphane Sallé il y a presque 10 ans
- Fichier droit.jpg droit.jpg ajouté
- Fichier droitbis.jpg droitbis.jpg ajouté
Bonjour,
Après avoir bien vérifié, si je donne les droits d'un user à un autre, ça ne fonctionne pas.
Ex : je veux donner les droits de Karl MARTIN à Silvaine VIOLINI.
Je sais auparavant que KMARTIN a accès àl'espace >GROUPE>FINANCE>Investissements>ZB Investissements comme lecteur.
Dans profil, je selectionne SVIOLINI, je lui attribue les droits "ajout" de l'utilisateur KMARTIN, aucun message d'erreur et pourtant l'utilisateur SVIOLINI n'a aucun accès.
Ci-dessous une capture d'écran des droits utilisateurs de l'espace concerné.
Merci de votre aide
Mis à jour par Cécile Bonin il y a presque 10 ans
Bonjour,
Je ne vois pas bien pourquoi ça ne fonctionne pas.
Pourriez-vous refaire la manip puis nous donner les traces du serveur d'application JBoss (server.log) ainsi que les traces de Silverpeas ?
Merci d'avance
Mis à jour par Yohann Chastagnier il y a presque 10 ans
Bonjour,
Effectivement, nous fournir les logs correspondantes à votre cas de test nous permettrait d'avoir plus d'éléments d'investigation.
Aussi, est-ce que la fonctionnalité se comporte bien dans un cas de test simple ?Par exemple :
- créer 2 utilisateurs A et B
- créer un nouvel espace, avec pourquoi pas des sous-espaces, sans ajouter d'application
- affecter l'utilisateur A au rôle de lecteur au niveau de l'espace nouvellement créé de plus haut niveau
- attribuer les droits de l'utilisateur A à l'utilisateur B
- vérifier les droits de lecture au niveau des espaces nouvellement créé
Les résultats de tests avec 2 utilisateurs et des espaces/applications créés uniquement pour vérifier cette fonctionnalité permettront, par la suite, de mieux analyser votre cas de test qui porte sur un périmètre de données conséquent.
Cordialement.
Mis à jour par Stéphane Sallé il y a presque 10 ans
- Fichier server.log server.log ajouté
- Fichier traces.txt traces.txt ajouté
- Fichier Droits_apres.png Droits_apres.png ajouté
- Fichier Droits_avant.png Droits_avant.png ajouté
- Fichier execution.png execution.png ajouté
Bonjour,
Voici les logs comme demandé.
Je n'ai pas la possibilité de créer des utilisateurs (nous nous identifions sur un annuaire), malgré tout j'ai essayé avec un nouvel espace.
Mais toujours aucune modification des droits ou plutôt du droit que j'avais posé dans l'espace.
Je me suis assigné le droit de lecteur sur le nouvel espace, et voulu ajouter à Emmanuel Grange les mêmes droits que moi-meme.
Mais aucun droit pour Emmanuel Grange sur l'espace.
Voici une capture des droits avant :
L'execution de l'évolution :
Une capture des droits après lancement :
Mis à jour par Cécile Bonin il y a presque 10 ans
Merci de votre retour.
Après analyse, il n'y a pas de traces d'erreurs dans les logs.
Et il n'y a pas toutes les traces d'exécution de la fonction. Il y a donc bien un souci.
Pour que nous puissions le reproduire, quel navigateur web utilisez-vous ?
et quelle est sa version ?
Mis à jour par Stéphane Sallé il y a presque 10 ans
J'ai essayé avec Firefox v31.4, Iceweasel v31.2, et Internet Explorer 8.
Mais notre navigateur officiel est Firefox.
Mis à jour par Stéphane Sallé il y a plus de 9 ans
Bonjour,
L'évolution fonctionne très bien et répond à nos attentes.
Néanmoins nous souhaiterions que vous lui apportiez les 2 corrections suivantes :
- Ne donner exclusivement la possibilité d'utiliser l'attribution de droits aux administrateurs du portail.
- Et lors de l'ajout ou du remplacement de droits, que l'espace personnel de l'utilisateur ne soit pas inclus.
Nous souhaitons que chaque utilisateur garde son propre espace personnel.
Mis à jour par Cécile Bonin il y a plus de 9 ans
Ok, nous vous tiendrons au courant dès que ces 2 développements seront disponibles.
Mis à jour par Stéphane Sallé il y a plus de 9 ans
Bonjour Cécile,
Pourriez-vous me donner une date approximative de la mise à jour de l'évolution ?
Merci
Stéphane
Mis à jour par Stéphane Sallé il y a plus de 9 ans
- Fichier pom.xml pom.xml ajouté
- Fichier userpanel.jsp userpanel.jsp ajouté
- Fichier MGISettings.xml ajouté
Messag d'orgine déplacé dans projet client.