Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Loading SQL Group List but where members are grouper groups

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Loading SQL Group List but where members are grouper groups


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Kelly Lankford <>
  • Cc: Rob Gorrell <>, "" <>
  • Subject: RE: [grouper-users] Loading SQL Group List but where members are grouper groups
  • Date: Thu, 22 Oct 2015 15:04:18 +0000
  • Accept-language: en-US

If you use the group name for the members, the column should be “subject_identifier”, if you are using the uuid, then it should be “subject_id”

 

Thanks,

chris

 

From: Kelly Lankford [mailto:]
Sent: Thursday, October 22, 2015 10:36 AM
To: Chris Hyzer
Cc: Rob Gorrell;
Subject: Re: [grouper-users] Loading SQL Group List but where members are grouper groups

 

Chris,

 

Your option1 is what we are trying to work with. Performance may actually be an issue, but we really want to see just how much of an issue before tackling database exposure. Where we are currently is that the views have been written for our organizational structure, and the loader jobs created. The groups of Campus -> Division -> Unit -> Department are being created, but they are empty. So, basically group membership is not being reconciled. 

 

The views are written such that the group_name is the text name of the group (let's say Division 1) and the subject_id is the text names of the Units within the Division. The subject_source_id is "g:gsa".  

 

Rob and I are thinking that to use your Option1 to make the reconciliation, we may need to modify the Group Source Adapter segment of the sources.xml file. Is this the case? If so, can you offer some guidance on the best way to do so? 

 

Thank you

 

Kelly Lankford

Business and Technology Specialist

UNCG ITS-MIS
336.334.5540

 

On Mon, Oct 19, 2015 at 2:51 PM, Chris Hyzer <> wrote:

Option1: go by group name (system name), and the column is subject_identifier.  This has worse performance than ID, but might be the only thing possible

Option2: join across a database link to the grouper DB, and get the Id.  You will need to experiment with hints (driving site), to make performance good

 

Thanks,

Chris

 

From: Rob Gorrell [mailto:]
Sent: Monday, October 19, 2015 2:13 PM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-users] Loading SQL Group List but where members are grouper groups

 

admittedly, i'm not a DBA, but does this require both databases (Banner and Grouper) to be on the same server? in the same schema?

-Rob

 

On Mon, Oct 19, 2015 at 11:48 AM, Chris Hyzer <> wrote:

Yes, we do this at penn.  The best thing is to join to the grouper_groups table and use the id (or uuid) of the group to be the subject id to be in the loaded group, and the source id would be g:gsa

 

https://spaces.internet2.edu/display/Grouper/Organization+hierarchies+via+the+grouper+loader

 

ok?

 

Thanks,

Chris

 

 

 

 

From: [mailto:] On Behalf Of Rob Gorrell
Sent: Monday, October 19, 2015 11:39 AM
To:
Subject: [grouper-users] Loading SQL Group List but where members are grouper groups

 

We would like to configure grouper loader job(s) to load the 4-tier organizational hierarchy existing in our ERP, Banner Finance... Campus -> Division -> Unit -> Department. We have already made a loader group to load the bottom 4th level, Departments, where people are directly assigned. But now we would like to roll up and load levels 3, 2, 1 and rather than normalize/flatten them out where users are their members, we would like load the existing level 4's grouper groups as members of the level 3's, and level 3's as members of level 2's, and so on and so forth to automatically create a nested group structure.

But I've never made a grouper loader job where the subject source isn't our external ldap database where user objects are. I assume we can make the subject source to point back at grouper's internal database and then could we send the group name as the subject id?

Am I on the right track of thinking in how to approach such a load?

-Rob


--

Robert W. Gorrell
Systems Architect, Identity and Access Management

University of NC at Greensboro
336-334-5954
PGP Key ID B36DB0CA




--

Robert W. Gorrell
Systems Architect, Identity and Access Management

University of NC at Greensboro
336-334-5954
PGP Key ID B36DB0CA

 




Archive powered by MHonArc 2.6.16.

Top of Page