Grouper Users - Open Discussion List

[Michael R Gettes <>]

On Jul 28, 2016, at 5:10 PM, Hyzer, Chris <> wrote:

Look at the grouper_rules_v view and see if there are other rules that might be affecting these objects?

Only 3 rules for Identity: in that view.

 Also see if there is a grouperLoaderGroupQuery attribute on the loader job? I know you said no other attributes set, just confirming.

Nope, only attributes set were as described below.

 Is it related to the loader or is it any group created there?

if i create an arbitrary group at the Identity: layer, it does not have this problem.

 

I hate to ask you to do this if the previous questions don’t uncover the problem, but is there a way to go to a different folder and setup a very simple example that shows the problem and explain what you did so I can reproduce it?

I will go about doing something simpler in a new top-level folder.  will report back on the results and what I did to make it happen.  I will do my best to keep it as simple as possible.

thanks for the quick response.

/mrg

 

Thanks

Chris

 

From:  [] On Behalf Of Michael R Gettes
Sent: Thursday, July 28, 2016 12:20 PM
To: Gouper Users List <>
Subject: [grouper-users] 2.3 Loader and Inheritance Rules

 

I am seeing some strange behavior and need to see if either I am doing something wrong or if others see it.

Grouper version 2.3 latest (as of 2 weeks ago)

 

I have two top-level folders:  Campus and Identity.  Campus has no inheritance rules but 

Identity does with 3 rules, Levels=All, 2 Group assignments, 1 folder and 3 assignments involve 

2 Groups being Identity:Admins and Identity:Admins-Readonly).  Image attached shows these rules.

 

I have a Loader job populating a bunch of members.  When I create the resulting group from the loader job into

Identity:NotStudents - Identity:Admins and Identity:Admins-ReadOnly end up as members of the group - an unexpected result.  

When I change the loader job to create Campus:NotStudents, Identity:Admins and Identity:Admins-ReadOnly groups are NOT members.

Creating Identity:Foo:NotStudents is without the Admins groups as members as intended.

 

The loader job looks something like (using Admin UI, no other attributes set)

 

grouperLoaderQuery =           select distinct 'Campus:NotStudents' as GROUP_NAME, SUBJECT_ID from GROUPER_MEMBERSHIPS_V where SUBJECT_SOURCE = 'psuperson' and lower(GROUP_NAME) like lower('Identity:Affiliations:eduPerson:ByAllAffiliations:%') and ( lower(GROUP_NAME) != lower('Identity:Affiliations:eduPerson:ByAllAffiliations:faculty') and lower(GROUP_NAME) != lower('Identity:Affiliations:eduPerson:ByAllAffiliations:retiree') and lower(GROUP_NAME) != lower('Identity:Affiliations:eduPerson:ByAllAffiliations:employee') and lower(GROUP_NAME) != lower('Identity:Affiliations:eduPerson:ByAllAffiliations:student') and lower(GROUP_NAME) != lower('Identity:Affiliations:eduPerson:ByAllAffiliations:staff') )

grouperLoaderType = SQL_GROUP_LIST

grouperLoaderDbName =       grouper

 

Is this a bug involving Inheritance Rules and groups created at the top level of where Inheritance Rules are defined?  Can anyone else replicate this problem? I hope I have provided all the info for someone to replicate the problem.

 

/mrg

 

<image001.png>