Group membership visibility by entity in Group view.

geoalbi · 2013-04-18 17:58:44

A minor issue, but still:

GLPI setup:
Root Entity + 2 sub etities: X and Y.
A group is created in the Root Entity and set to be visible downstream in child entities.
X contains 2 users (imported from AD if this is relevant). We add the 2 users to the above group.

Login as GLPI (Super-Admin) in Root Entity.
Visualize the group with 2 members: Administration>>Groups: go to "Users" tab.
1. Selecting the Y entity, the group users list is empty (normal behaviour, the 2 users are in the X entity).
2. Selecting the X entity, the group users list has the 2 members (normal behaviour, the 2 users reside here).
3. Selecting the "Root entity>> Show all" from the top menu, we see the two users. (normal behaviour, the 2 users reside downstream and we have selected "Show all")
4. Selecting only the "Root entity" from the top menu, we still see the two users.

As far as I understand GLPI, 4 from above is not normal. The 2 users should be visible only in the entity they reside in and not upstream, unless >>Show all is selected.

Also tested this in the Administration>Users menu to validate if my understanding of object visibility is correct: an object should be visible in its entity and upstream if "Show all" is selected.
Result: the 2 users are only visible in their entity and upstream when >>Show all is selected, so hypothesis is confirmed.

yllen · 2013-04-19 08:56:04

When you select Root entity, do you click on the name Root entity or on the >> at the right of the name ?
Which version of GLPI do you use ?

geoalbi · 2013-04-19 09:37:57

yllen wrote:

When you select Root entity, do you click on the name Root entity or on the >> at the right of the name ?
Which version of GLPI do you use ?

GLPI version 0.83.7

This is exactly my point. When I select the Root entity with "Show all" by clicking on the ">>" I get the expected result, I see the two user group members.
When I only select the Root entity I should see only the group, because the users are not there, are downstream in child entities.

There is a problem in the select that produces the group members users list. It should have an additional filter.

yllen · 2013-04-19 14:26:11

If your users are defined in entity child but also members of a group of root entity, you will see them when you are on root entity.
The filter is in Member of not Created in x entity.

With this system, you can assign user to a group entity and when you select this group as assign in a ticket, they only can work on this ticket.
In my job, we have lot of entities. We define group in root entity so they can be visible in all sub entities.
In this group, we affect users from entity X or Y and they are technicians only for this group, but for all sub entities (we have groups Linux, Windows, active Directory, spécific software...).

geoalbi · 2013-04-19 15:56:47

yllen wrote:

If your users are defined in entity child but also members of a group of root entity, you will see them when you are on root entity.
The filter is in Member of not Created in x entity.
With this system, you can assign user to a group entity and when you select this group as assign in a ticket, they only can work on this ticket.
In my job, we have lot of entities. We define group in root entity so they can be visible in all sub entities.
In this group, we affect users from entity X or Y and they are technicians only for this group, but for all sub entities (we have groups Linux, Windows, active Directory, spécific software...).

Thanks for the reply Yllen. I'm not sure if I understood correctly, but we agree on pretty much every point regarding how to use entities and groups. I'm only afraid I did not explain the issue right.

What I am stating is that we have objects from child entities visible in a parent entity when "Show all" >> was not selected.
This normally does not occur, but it does in the group object properties.

We use entities to model companies and departments, to isolate rights management.
We use groups to isolate ticket visibility by assigning tickets to groups and configuring ServiceDesk operators to only see tickets they created, assigned to them or to the groups they are members of.

Usually, in the ServiceDesk application, this filtering of tickets to groups of technicians is done by introducing the concept or skills sets. You would have a normal user that can be configured to be an GLPI operator by assigning him skills and the right to be assigned tickets.
Then, you have the services from the Service Catalog (Categories of Tickets in GLPI). Each in order to be solved requires a list a skills.
Then using skills you link your operators to your services in the Service Catalog (Categories of Tickets in GLPI).

You did this in GLPI by grouping the operators and assigning tickets to groups.

Then, judging by the sum of skills, you can set a cost per hour per operator. It will cost you 20euro per hour for a general IT tech, but 40euro per hour for a PHP expert. The operators may enter hours worked but GLPI may compute costs in Euros in the back stage. From this you can have your financials/invoicing.

And so on...

(many years of CA ServiceDesk and ITIL consultancy speaking)

But I digress.
The issue above is minor. So you might as well forget about it.

Last edited by geoalbi (2013-04-19 16:04:19)

Forum GLPI-Project

Announcement

#1 2013-04-18 17:58:44

Group membership visibility by entity in Group view.

#2 2013-04-19 08:56:04

Re: Group membership visibility by entity in Group view.

#3 2013-04-19 09:37:57

Re: Group membership visibility by entity in Group view.

#4 2013-04-19 14:26:11

Re: Group membership visibility by entity in Group view.

#5 2013-04-19 15:56:47

Re: Group membership visibility by entity in Group view.

Board footer