Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

On this page:

 

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

 

I added the top part:

 

FROM:

penn:community:employee:org:TOPU:UNIV:UCAC:UUAC:USCH:56XX:56YY:5600

 

TO:

penn:community:employee:org:5600:5600

 

the hierarchies are in the same folder.  So for example:

 

 

I think I need to redo the docs on grouper orgs to be what we do now at penn.  Sound like a good idea?

 

Thanks

Chris

 

 

 

From: Stephen A Sazama [mailto:]
Sent: Thursday, March 02, 2017 11:43 AM
To: Hyzer, Chris <>
Cc: Dave Churchley <>;
Subject: Re: [grouper-users] SQL Loader Groups Membership Persistence

 

Thanks for the suggestions. Both of these look promising for helping our situation.

 

Chris, are you saying you got rid of the hierarchy-related folders entirely? What you said about using the code instead definitely makes sense (right now, we're using the org full name as the group ID, should change that to org code), but how is the hierarchical relationship maintained if you change penn:community:orgs:TOPU:OTHERPLACE:IT:SOMETHING:4972 to penn:community:orgs:4972? Is the fact that 4972 exists under SOMETHING still stored somewhere?

 

Thanks,

Stephen

 

On Thu, Mar 2, 2017 at 10:24 AM, Hyzer, Chris <> wrote:

We had out groups setup in hierarchical folders.

 

penn:community:orgs:TOPU:WHATEVER:IT:SOMETHING:4972

 

Then IT moved to something else, which changed to:

 

penn:community:orgs:TOPU:OTHERPLACE:IT:SOMETHING:4972

 

this messed up a lot of things.

 

So we changed so that orgs are now:

 

penn:community:orgs:4972

 

Now if it is moved, then we are all good.  If it is renamed to a different org number, then the problem you describe will happen.  We only put the code in the group system name (well, its actually a folder and a group name).  So if an org is renamed to a different name, still good.  Only if the org code changes (which hopefully is rare) will there be problems.

 

Thanks

Chris

 

From: [mailto:] On Behalf Of Dave Churchley
Sent: Thursday, March 02, 2017 3:48 AM
To: Stephen A Sazama <>;
Subject: RE: [grouper-users] SQL Loader Groups Membership Persistence

 

This scenario bit us a few years ago. Just as you describe, new groups were created, groups with the old names were deleted and, as a result, people lost access to resources. (This was before I was working with Grouper myself so some of the details might be a bit sketchy.)

 

We’ve now got it set up so that new groups are created but the old groups are not deleted so, in effect, we have two groups of the same set of people, one with the old name and one with the new name. At that point the membership of the old group becomes static (the loader ignores it) so any resources relying on that group are still available to the right people initially but over time, as people should join or leave the group, the membership becomes wrong. We then need a manual process to associate the resources with the new groups instead of the old groups and manually delete the old groups when they are no longer needed.

 

If anyone has a better way of handling this, I’d be very interested!

 

Dave

 

From: [] On Behalf Of Stephen A Sazama
Sent: 01 March 2017 21:04
To:
Subject: [grouper-users] SQL Loader Groups Membership Persistence

 

Hi All,

 

We have an Org Hierarchy of groups generated by SQL Loaders, similar to the Penn structure described on the wiki. A big concern for us right now is what happens when one of those organizational units gets renamed in the source database. When the loader runs again, a new group would be created and the one with the old name would get deleted along with all of its memberships in other roles/groups. Grouper has no way of knowing that a rename happened.

 

Have others faced this problem and found any good solutions?

 

Thanks,

Stephen Sazama

University of Maryland, College Park