Thank you for asking the question. J I
may have use for the “simple case” that the loader job could do as well. J (
I am currently doing this kind of function with some custom/specialized code. Maybe I can remove some of that code. J or
at least not duplicated the design again. J )
Just some food for thought.
However, I personally would lean toward option #4. ( AKA: a Change Log Consumer (CLC) )
Invent an attribute name (“autoNestGroups”) to mark a folder as a “source folder”. The value would be the full path to the “target group” to auto add new group into.
the CLC would see the group add event ( about every minute),
if found, get the value for the “target group” and make the new group a member of it.
If you want to get more complicated/flexible:
Invent an attribute *Definition* named (“autoNestGroups”) and make it multi assignable, and single valued.
Also add an attribute Name (“makeMemberOf”). Where you put the full path to the group(s) to make new groups a member of.
Also add an attribute Name (“Exclude”). If present, remove the group if it is already a member of the “makeMemberOf”.
When a group is added, the CLC would see the group add event, check for the attribute(s), if found and not marked as “Exclude” then get the value(s) for the “makeMemberOf” and make the new group a member of all
Also watch for attribute value add/remove ( for when “Exclude” attribute is added/removed ) and add/remove the group marked as needed.
You could even get really “crazy” and deal with the idea that some of the child groups (of a tagged folder(s) ) need to go to some makeMemberOf(s) and other child groups go to other makeMemberOf(s) with regex
to makeMemberOf maps too. ( add a third Attribute Name “IfRegExMatches” , apply to the full group path being added/updated.)
Then tightly control the privileges on the attributeDef to limit who can affect the nesting “config” in grouper. And it becomes “meta data driven” via the Grouper UI. ( Once the CLC is written and running.)
With attributes you can get to “inheritance” and “include/exclude” patterns across multiple source and target locations.
It is more design and work, and brings more flexibility too. ( IHMO )
However, I guess you could also get “fancy enough” with your SQL contortions to also let you watch attributes too. ( That is just more twisty SQL than I would want to write. J ..
Only groups with this attribute and not that attribute where the name matches this regex… Ugh…)
Pick the option that meets your needs and requires the least amount of work. J
From: <> On
Behalf Of Coleman, Erik C
Sent: Friday, March 29, 2019 4:20 PM
Subject: RE: [grouper-users] Advice on automating nested groups
Ah thanks! There’s even an example on the wiki! I was searching around and didn’t come up with anything. I think the potential delay is not a major issue as long as the interval is known.
From: Hyzer, Chris <>
Sent: Friday, March 29, 2019 2:58 PM
To: Coleman, Erik C <>;
Subject: RE: Advice on automating nested groups
I do that with the loader. Might mean some delay on how soon the groups get added to the larger group, I run mine every 30 minutes… I could picture a rule doing that, but ive never done it. If you want to go down that path I could investigate.
But with a rule someone could unassign the group. Maybe we need a rule and a loader? Or a way to hook up real time loader to the loader job?
From: <> On
Behalf Of Coleman, Erik C
Sent: Friday, March 29, 2019 3:53 PM
Subject: [grouper-users] Advice on automating nested groups
I’m curious if anyone has been challenged and found a solution to automatically “nest” groups into larger groups, based on some pre-defined matching criteria. The use-case here is that we have some applications that want to use a large
quantity of Grouper groups for some pretty specific access controls, organized in multiple folders, and then have larger groups that are an accumulation of all these smaller groups, for example, the members are all the groups in the “app:web:index” folder.
By hand, this is simple, merely add the smaller groups as members of the larger group, but it involves remembering and making sure we add any newly-created smaller groups to that group. I tried brainstorming and came up with a few approaches:
(1) Use a Loader job. It seems to me we could query Grouper itself for a match of groups,
then just insert them as members, though I’m curious what such a query and loader config would look like.
(2) Set up a rule. I don’t know much about Grouper rules, but I’ve set them up to establish
inheritance of access controls. Would seem to me, that maybe we could have a rule that if a group is created in a folder, add it as member to another group?
(3) Script it externally using GSH or Web Service. This would give greatest control to the
application to just double-insert memberships, but the learning curve for the API is a bit steep.
(4) Use custom attributes. Would probably still require one of the above methods, but you
could assign an attribute, then something queries for that attribute and inserts all groups that have that attribute set.
If anyone has accomplished this, would you be willing to share your queries or methods?
University of Illinois at Urbana-Champaign