Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

To explain another way:

 

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

 

There are groups:

 

penn:community:orgs:4972

penn:community:orgs:SOMETHING

penn:community:orgs:IT

penn:community:orgs:OTHERPLACE

penn:community:orgs:TOPU

 

These have the hierarchy:

 

penn:community:orgs:SOMETHING   has a member    penn:community:orgs:4972

penn:community:orgs:IT has a member  penn:community:orgs:SOMETHING (direct) and penn:community:orgs:4972  (indirect)

 

So as things get reorganized, a lot of the cases will not affect applications.

 

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