Grouper Users - Open Discussion List

["Gettes, Michael" <>]

Sorry for the delayed reply…

I am not a fan of tagging.  With 100K or more groups, this is truly unworkable.  Grouper knows which groups are not viable - if user1 or user2 are an indirect member of the group, don’t show that group (provide a filter mechanism that by default filters out groups of indirect membership - but to debug a problem between 2 users being able to see even the indirect groups will be useful.  Groups with indirect memberships should NOT be able to be healed in this UI.

As for loader jobs - grouper knows which groups get generated by loader jobs… group should be tagging groups created by loader jobs so it can know for operations such as this.  These groups should also be able to be filtered as described above.  I will note adding a user to a loader managed group shouldn’t be a big deal because the next time the loader job runs, user1/2 will be left alone (they should be a member) or removed - so healing a loader managed group is temporary until next loader run.  Nonetheless, I appreciate why we wouldn’t want to include groups from loader jobs as part of healing operations.

/mrg

On Jul 10, 2017, at 11:45 PM, Black, Carey M. <> wrote:

Just some quick thoughts….

 

It might be safer (and ultimately more configurable) if the groups needed to be “tagged” to support this “magic”. That way the local instance needs to be told (configured) what groups are ok for this magic. 

Instead of trying to magically figure out what groups to not do it for. (And rules could be used to auto tag groups by stem too.)

 

It might be possible that some “loader jobs” might be suspect for various reasons in a local environment. ( timing of updates in grouper vs the upstream system, failures to complete the data loads, etc..) So if a local instance wants to include such a group for this kind of manual/scripted comparison, it would be more useful to explicitly need to identify the groups that are “OK” than to try to auto-magically know which groups are “not ok to fix”.

 

 

Maybe via a new attribute named something like: “grouperOkToDiffUsers” ?  ( Assuming the feature is called something like “What’s the diff between two users?” (WTD2U) J

 

 

 

 

The idea could also be extended to dynamically support the idea of WTD2G ( between two groups J ).

                Which might be a nice way to evaluate if two groups are “the same by membership”. ( Seems like a useful function to me. Yea this could be done with two complement composite groups, but a “simple UI” that could allow an admin to “push users” from one group to another could, maybe, be useful if the groups being compared are not composite groups. )

 

 

I kind of have a two column UI in my head.

                Right/Left columns ( with a user or a group value in each column)

                values in the columns would be a “check list” of values that are not in the other list.)

                Arrow buttons to move items from Right to Left, or Left to Right.

                Save/Cancel buttons.

 

                Maybe the UI works for all groups, but the “change/check” buttons are disabled if the groups are not tagged, or if the groups are composite groups?

                                That way you could see the difference and maybe “get a clue” about upstream system data that is driving the difference too?

 

 

OR automatic functions to auto move “Group1 à Group2”, “Group2 à Group1” and maybe even “Group1 ßàGroup2” options to skip the UI lists and “just do it”. ( That would be more like what Michael was asking for. )

 

--

Carey Matthew 

 

From:  [] On Behalf Of Hyzer, Chris
Sent: Monday, July 10, 2017 3:26 PM
To: Gettes, Michael <>; Bill Thompson <>
Cc: 
Subject: RE: [grouper-users] Differencing tool with healing capabilities...

 

Bill, I think grouper needs to keep track of which groups are managed by the loader via internally used attributes to make this happen right?

 

Thanks

Chris

 

From:  [] On Behalf Of Gettes, Michael
Sent: Monday, July 10, 2017 3:22 PM
To: Bill Thompson <>
Cc: 
Subject: Re: [grouper-users] Differencing tool with healing capabilities...

 

Right.  You are absolutely correct.  If grouper can figure all this out and “do the right thing”, that would be outstanding.  I guess this would mean the “healing” capability shouldn’t attempt to fix indirect memberships.  Would that do it?

/mrg

 

On Jul 10, 2017, at 3:17 PM, William G. Thompson, Jr. <> wrote:

 

Just wondering about the scope of the feature and the use case.  If one is following the deployment guide then "fixing/healing" a user who needs access like another user may not necessarily involve manually updating direct members assignments. It could be an issue with upstream data for a reference group, could be an exception/addition to authZ policy, etc.

 

Best,

Bill

 

 

On Mon, Jul 10, 2017 at 3:07 PM, Gettes, Michael <> wrote:

Well, there is no real indication of how a group is being used in grouper - so I’m looking for a tool to do so independent of use.  Now, of course, it would be awesome if grouper could determine the use of a group and show differences and either automatically exclude certain differences (due to policy) or other constraints - but I think this is a wee bit further in the future.  Do I understand you correctly?

/mrg

 

On Jul 10, 2017, at 2:54 PM, William G. Thompson, Jr. <> wrote:

 

Mike, 

 

This would work for ACL-like membership groups, but not for policy driven ones, right?  

 

Best,

Bill

 

 

 

On Mon, Jul 10, 2017 at 2:37 PM, Gettes, Michael <> wrote:

I was thinking (I know, always dangerous)… 

 

If there was a grouper tool to show the differences of group memberships between 2 users and then 2 magic options (make user1 like user2, or make user2 like user1) - this would be a nice way of healing users who should have all the abilities of another.

 

Also, with the above UI tool, give me the option of selecting which groups to “heal” for the 2 users involved with checkboxes on each group.

 

I hope this makes sense and would be useful to others.  Maybe this has already been thunk up and in the hopper for some future development?

 

Thanks for your consideration.

/mrg