Grouper Users - Open Discussion List

[Peter DiCamillo <>]

Thanks. I'm working with Steve, and I've been testing this, with the 
goal that from below a given folder in the tree, an admin group retains 
privileges to create and manage additional levels of folders and groups. 
I set up a structure like this:

ACL-TEST folder
  admins group
  CUSTOM folder
    new-folder
    new-group

The ACL-TEST folder has rules for reassignGroupPrivilegesIfFromGroup and 
reassignStemPrivilegesIfFromGroup. The admins group is given create 
group and create folder privileges for the CUSTOM folder. With that set 
up, working as a member of the admins group, I created the new folder 
and new group under CUSTOM. The admin privilege for the new group was 
assigned to the admins group, as expected. Also, the create folder 
privilege for the new folder was assigned to the admins group. However, 
the create group privilege for the new folder remained assigned to me. 
Is that expected? Do I need to do something differently? I did this 
using Grouper 2.2.1.

Peter

On 1/26/15 5:49 PM, Chris Hyzer wrote:
> For #1, you just put it on an ancestor stem, you dont have to put it on the substeams, 
> it will inherit.  The rule fires immediately, I believe its in the same transaction as 
> the group or stem create.  Is that what you meant by "cycle".  This use case 
> is what the rule is for, I would use that :)  In general this is what sites generally 
> need, otherwise it is difficult to have multiple local admins and when individuals 
> leave you have a lot of individual privileges pepperred throughout the registry when 
> most of them should have been group privileges.
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: 
>
>  
> [mailto:]
>  On Behalf Of Steven Carmody
> Sent: Monday, January 26, 2015 5:25 PM
> To: Grouper-Users
> Subject: [grouper-users] rights inheritance ...
>
> Hi,
>
> we're making a major push giving Depts the authority to create and manage 
> groups within Grouper. Each Dept has an Admins group with privileges within 
> the Dept STEM.
>
> The default permissions assigned when a group is created, tho, is that the 
> person who created the group gets rights. We want the members of the Admins 
> group to get those rights. They work as a group, and they all need to be able 
> to see and manage the new group.
>
> We can think of two ways to obtain the outcome we want. But, we're sure we're 
> not the only campus encountering this issue, and we're keenly interested in 
> hearing how other campuses are approaching this problem.
> The two approaches we can think of are:
>
> 1) use Grouper's Rules functionality. There's a nice example in the Grouper 
> doc:
>
> https://spaces.internet2.edu/display/Grouper/Grouper+rules+use+case+-+Reassign+group+privileges+if+from+group
>
> This is really clever. Our concern about this approach, tho, is its lack of 
> transparency. You can't see or set these Rules via any known GUI. Its 
> there... but no one in the Depts would ever see the Rules. Also, we don't 
> know on what cycle the Rules would be implemented.
>
> 2) Use a process outside of Grouper to reset the permissions when a group is 
> created. We're thinking that the Change Log Consumer, when it saw a Create 
> Group Msg, could reach back into Grouper and change the permissions, if 
> appropriate. The Depts wouldn't see this either, but we'd be able to easily 
> see the logic.
>
> How are other sites dealing with this issue ? Do you have a different 
> approach ? Thoughts on these two ideas -- which would you prefer ?
>
> Thanks very much !