Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

That sounds interesting.  Maybe be able to load an attribute on a group that identifies the parent.  And the UI could put the paths together and let you browse that way.  Having folders might be misleading in my mind because we would *not* want someone to refer to that long path or be able to get memberships from the long paths, or it defeats the purpose…

 

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

 

The only solution I can currently think of to get the benefits of both structures would be something like symbolic links for groups. eg. In addition to what you have now, another structure with the old folder hierarchy that contains group links rather than regular groups. They'd have their own paths and an additional "source group" field, but for everything else (member list, update actions) it would behave as if you were working with the linked group.

 

Not sure if that's something that would be generally useful, though. I will see what we want to do here.

 

Thanks again,

Stephen

 

On Thu, Mar 2, 2017 at 2:28 PM, Hyzer, Chris <> wrote:

Yes, I wonder if there is a UI feature we could add in there where if you mark a folder as hierarchical it could help display the hierarchy.  Does that spark any ideas about what you would like?

 

Thanks

Chris

 

From: Stephen A Sazama [mailto:]
Sent: Thursday, March 02, 2017 2:26 PM

To: Hyzer, Chris <>
Cc: Dave Churchley <>;
Subject: Re: [grouper-users] SQL Loader Groups Membership Persistence

 

Thanks for the update! I think I got it. The only downside would be that you don't have the nice hierarchical representation of orgs in the folder browser. If someone wanted to find the parent of an org group (assuming it's not obvious from the code or name) they need to view its memberships in other groups, right?

 

Stephen

 

On Thu, Mar 2, 2017 at 1:21 PM, Hyzer, Chris <> wrote:

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