Group managers' actions

[rmiccoli]

What actions can a group manager do?

• see their managed groups in their dashboard
• see the members of each managed group (limited view including name, surname, uuid, username, email, status, created, updated, end time, labels)
• approve/reject membership requests
• delete users from their managed groups
• add users to their managed groups → this implies that the group manager should have visibility of all users

If a managed group has subgroups, what actions can a group manager do on them? Considering a group A and a subgroup B, the group manager of A can:

• also be manager of group A/B (and any other subgroups of A)
• add users of group A to A/B
• view members of A/B
• approve/reject membership requests for A/B
• delete users from group A/B

[giacomini]

In the above description, assume that group A is not at the top level.

Consider also the following use case.
Given a manager of group A/B, but not of group A

1. the manager adds a user to B. The user is now automatically added also to A, since a subgroup is included in a group
2. the manager removes the same user from B

Should the user be removed also from A? the current implementation does not remove the user from A and we propose to keep it like that.

[hshort]

I'm struggling to think of why a manager of group A would have full edit access on the members of subgroup B. At CERN the group A manager is able to add any group as a subgroup but not able to edit its members unless given permission independently. This has not caused issues for us though does occasionally raise concerns by a Group A manager that they don't have full visibility of who is in their group if they can't see the subgroup members. In response to @rmiccoli I'm not sure I see a good use case for your section "If a managed group has subgroups, what actions can a group manager do on them?"

In response to @giacomini question, if a user is removed from B they would no longer be in A in our normal model. The fact that this is a question implies to me that nested group membership is calculated and stored rather than being evaluated "live" - is that right?

[deesto]

What are "subgroups" in this context? In the VOMS VO implementation, "A" is a VO and "B" is a VO/country group (e.g., '/atlas/usatlas'); in order to manage members in "B", one must also have the "group manager" privilege in "A". I am not saying I'm in favor of that model, just that it exists. Do you also anticipate another level of VO grouping ('/atlas/usatlas/some-sub-group')?

[giacomini]

What are "subgroups" in this context? In the VOMS VO implementation, "A" is a VO and "B" is a VO/country group (e.g., '/atlas/usatlas'); in order to manage members in "B", one must also have the "group manager" privilege in "A". I am not saying I'm in favor of that model, just that it exists. Do you also anticipate another level of VO grouping ('/atlas/usatlas/some-sub-group')?

In general there can be an arbitrary number of nesting levels. If there are only two of them (like it is for Atlas) it's indeed possible that nothing of the above applies.

[jouvin]

@deesto in fact in your example there is only one group level as the first term in your "path" is the VO name, not a group. So there is no nesting involved in this case (atlas level will not exist in the IAM side).

[deesto]

@deesto in fact in your example there is only one group level as the first term in your "path" is the VO name, not a group. So there is no nesting involved in this case (atlas level will not exist in the IAM side).

Right, thus the second part of the question, on whether there will be a need for /vo/group/sub-group -- sounds like not likely, unless as @giacomini said they are treated arbitrarily as N number of possible levels.

[vokac]

Be aware that /atlas/usatlas/production is also group in the IAM (with a special flag wlcg.optional-group) and list group managers for this group is different than list for parent /atlas/usatlas.

[norealroots]

* add users to their managed groups → this implies that the group manager should have visibility of all users

Could, perhaps, a group manager be able to invite a user to the group via an email address?

If the user is already within IAM, it could either:

• automatically add the user to the group
• prompt the user to accept the invite
  Not sure which would be preferred there.

If the user is not within IAM, would it be possible to have the system email them with a registration link that add the user to the group at registration time? I remember Andrea (a long time ago now) previously talking about invite/registration links with group membership attached, and this seems a good use of that?

It does also avoid giving the manager full membership view.

Thoughts?