glpi-project
Fix(Group): fix user visibilty
Since https://github.com/glpi-project/glpi/pull/11928
Users from another entity can be seen
Let's imagine the root entity with two children Entity A and Entity B
A group named Security in the root entity and recursive.
All admins in entity A and entity B see the group (OK)
The Admin in entity A adds a user from entity A to the group
The admin in entity B sees the user in entity A (NOK)
This PR fix this and corrects the user count in the tab, taking account of the entity restriction
| Q | A |
|---|---|
| Bug fix? | yes |
| New feature? | no |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | !34146 |
What about keeping the data but replacing the name with something like "Hidden user" @orthagh ?
IMO it feels weird to be able to manage a group without having some kind of hint about the users that are inside.
What about keeping the data but replacing the name with something like "Hidden user" @orthagh ?
IMO it feels weird to be able to manage a group without having some kind of hint about the users that are inside.
As far as I'm concerned, you only need to see/manage the users in your scope?
Why see/count the rest if you can't do anything with them?
As far as I'm concerned, you only need to see/manage the users in your scope?
Usually in GLPI, we listed the third party item without any links. You see the name of the name of the linked item but you cannot see any details
As far as I'm concerned, you only need to see/manage the users in your scope?
Usually in GLPI, we listed the third party item without any links. You see the name of the name of the linked item but you cannot see any details
This is currently the case :
We only see the name of the linked element when it is not in the current user's scope We see the link (url) of the linked element when it is recursive (but opening the page returns ‘you don't have rights’)
The current behaviour seems to affect (only) one customer (who uses recursive groups at the root of GLPI) (at least since 2022 this is the only one).
But the change could have an impact on others
A decision seems necessary on this part
Why see/count the rest if you can't do anything with them?
I am afraid it could lead to errors. If I am allowed to manage a group but can't see the users inside it, I might be tempted to deleted it thinking it is an useless empty group while in fact there are many users that I can't see.
Usually in GLPI, we listed the third party item without any links. You see the name of the name of the linked item but you cannot see any details
This is the issue reported by the user here, he says that revealing the users names is bad because they are in a entity that he can't see.
So even showing just the name is too revealing for their use case.
update code to not delete a property in a bug-fix release.
like discussing the internal channel,
seeing usernames that you shouldn't, because we bypass the check of your authorisations/entities, it's a bug (@flegastelois )
Ass seen IRL,
The list of users must be filtered, but not the counter (from tab). A message will be displayed if the total differs from the list
Maybe the alert message should be above the "criteria" input, unless it can appear/diseappar depending on the criteria ? I guess it doesn't need to use all the width too.
For the message, I would use Some users instead of Some people and due to your entity restrictions instead of due to your clearance (restriction per entity) but this is kinda subjective :)