Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
None
-
None
Description
From: Crawford, Jeffrey <jcrawford@it.ucla.edu>
Sent: Tuesday, May 14, 2019 4:25 PM
To: Hyzer, Chris <mchyzer@isc.upenn.edu>; Grouper Users <grouper-users@internet2.edu>
Subject: Re: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
That works for me. The project is long term anyway
Thanks
Jeffrey C.
From: "Hyzer, Chris" <mchyzer@isc.upenn.edu
>
Date: Tuesday, May 14, 2019 at 10:07 AM
To: "Crawford, Jeffrey" <jcrawford@it.ucla.edu>, Grouper Users <grouper-users@internet2.edu>
Subject: RE: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
We could get that working in a 2.4 patch in the next couple of months if you like…
From: Crawford, Jeffrey <jcrawford@it.ucla.edu>
Sent: Tuesday, May 14, 2019 12:57 PM
To: Hyzer, Chris <mchyzer@isc.upenn.edu>; Grouper Users <grouper-users@internet2.edu>
Subject: Re: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
Bump 😊.
From: <grouper-users-request@internet2.edu> on behalf of "Crawford, Jeffrey" <jcrawford@it.ucla.edu>
Reply-To: "Crawford, Jeffrey" <jcrawford@it.ucla.edu>
Date: Friday, May 10, 2019 at 8:17 AM
To: "Hyzer, Chris" <mchyzer@isc.upenn.edu>, Grouper Users <grouper-users@internet2.edu>
Subject: Re: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
Morning (Probably Chris),
So how much work is it to implement Phase 2.5? I keep running into problems trying to embed groups and then also keep subjects out of eligibility groups using RuleApi.groupIntersection The structure we are working with is based on our organization structure. Therefore if someone is assigned at a higher level than a department we embed the groups so they have access all the way down. However they could also be added at the bottom level, so the group nesting is important. The issue is that in order to embed groups with RuleApi.groupIntersecton I have to add the group itself to the eligibility group. However now If I add a subject to one of these groups they become eligible based on the embeded group, so I can’t remove people from eligibility. However the RuleApi.vetoSubjectAssignInFolderIfNotInGroup allows you to only apply the rule to specific object type. This sounds complicated so I’ll give an example:
Root Group
|-> Level 1 Group
|. |-> Level 2 Group
|. |. |-> Level 3 Group
|. |. | |-> Level 4 Group
So if someone is in the Level 2 Group they should also be indirect members of Level 3 and Level 4. However if you apply RuleApi.groupIntersecton to each of them so that you eject any users no longer eligible the Level 1,2,3, groups must also at least be in the eligibility group. However no if you add someone to the Level 2 group, they also show up in the eligibility group, so you’ve just defeated your process.
I think if we can implement Phase 2.5 on RuleApi.vetoSubjectAssignInFolderIfNotInGroup then I don’t have to worry about embeding the groups in the eligible group.
What do you think?
Jeffrey C.
From: <grouper-users-request@internet2.edu> on behalf of "Crawford, Jeffrey" <jcrawford@it.ucla.edu>
Reply-To: "Crawford, Jeffrey" <jcrawford@it.ucla.edu>
Date: Thursday, April 18, 2019 at 3:44 PM
To: "Hyzer, Chris" <mchyzer@isc.upenn.edu>, Grouper Users <grouper-users@internet2.edu>
Subject: Re: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
Phase 2.5 is a change log consumer that sees if subjects are removed from groups. Would be useful but I can also see expanding RuleApi.groupIntersection to apply to subfolders. Right now I’m adding that rule to every group, but that creates a ton of changes that have to move from the temp changelog to the changelog.
I can appreciate that someone may want to veto membership without automatically removing the users if they fall out of eligibility.
Thanks
Jeffrey C.
From: "Hyzer, Chris" <mchyzer@isc.upenn.edu>
Date: Thursday, April 18, 2019 at 2:30 PM
To: "Crawford, Jeffrey" <jcrawford@it.ucla.edu>, Grouper Users <grouper-users@internet2.edu>
Subject: RE: RuleApi.vetoMembershipIfNotInGroup only works with direct membership
We have not done any of the phases, are you interested in it? 😊
From: Crawford, Jeffrey <jcrawford@it.ucla.edu>
Sent: Thursday, April 18, 2019 4:11 PM
To: Hyzer, Chris <mchyzer@isc.upenn.edu>; Grouper Users <grouper-users@internet2.edu>
Subject: Re: RuleApi.vetoMembershipIfNotInGroup only works with direct membership
Hi Chris,
What are the “phases” are these future improvements?
Thanks
Jeffrey C.
From: "Hyzer, Chris" <mchyzer@isc.upenn.edu>
Date: Thursday, April 18, 2019 at 12:47 PM
To: "Crawford, Jeffrey" <jcrawford@it.ucla.edu>, Grouper Users <grouper-users@internet2.edu>
Subject: RE: RuleApi.vetoMembershipIfNotInGroup only works with direct membership
That use case is documented here, try it out
From: Crawford, Jeffrey <jcrawford@it.ucla.edu>
Sent: Thursday, April 18, 2019 2:59 PM
To: Hyzer, Chris <mchyzer@isc.upenn.edu>; Grouper Users <grouper-users@internet2.edu>
Subject: Re: RuleApi.vetoMembershipIfNotInGroup only works with direct membership
This does help but there is a specific requirement that when people are no longer eligible they should be removed, and added back If needed. This is to handle job transitions and such. I think rules are the way to go in that case.
Has it ever been considered to add a veto and intersection rule that takes the mustBeInGroup and applies it to all groups under a folder?
Jeffrey C.
From: "Hyzer, Chris" <mchyzer@isc.upenn.edu>
Date: Thursday, April 18, 2019 at 10:08 AM
To: "Crawford, Jeffrey" <jcrawford@it.ucla.edu>, Grouper Users <grouper-users@internet2.edu>
Subject: RE: RuleApi.vetoMembershipIfNotInGroup only works with direct membership
The image might display better on a wiki…
https://spaces.at.internet2.edu/display/Grouper/Penn+team+collaboration+eligibility
From: Hyzer, Chris
Sent: Thursday, April 18, 2019 1:02 PM
To: Crawford, Jeffrey <jcrawford@it.ucla.edu>; Grouper Users <grouper-users@internet2.edu>
Subject: RE: RuleApi.vetoMembershipIfNotInGroup only works with direct membership
We are doing a lot of eligibility work at penn too.
The rule is for an ad hoc direct membership group where you want people to fall out if something happens (not active anymore). If they are eligible in the future they will not be put back in the ad hoc group unless someone adds them (go through an intake process).
The composite will remove the person from the overall group if they are no longer eligible, but then if they become eligible again, they will be in the overall group.
I have been using composites recently and rely on a deprovisioning process (largely through attestation) to remove individual assignments when people leave.
An example is the project to implement banner. To get access to resources someone needs to be in an da hoc list for the team, needs to be an active employee or contractor, needs to be enrolled in two-step authentication, needs to have done three trainings, and the FERPA training is yearly. For each of these we have overrides to grant temporary access in a pinch. E.g. if someone is having trouble with the LMS, if a BA let someone’s contractor affiliation lapse when it shouldn’t, etc. It’s a complex visualization, but here goes
The three groups on the left are the ad hoc team groups. The next stuff is the eligibility and exceptions. The ngssTeamAll is the reference group that is used in all the policy groups to the right of it (box, confluence, jira, email, Clarizen, banner, etc)
Does this help? What would make it easier? 😊
From: grouper-users-request@internet2.edu <grouper-users-request@internet2.edu> On Behalf Of Crawford, Jeffrey
Sent: Thursday, April 18, 2019 11:41 AM
To: Grouper Users <grouper-users@internet2.edu>
Subject: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
Morning Grouper Team,
We’ve been working on applications with large number of groups, each of these groups however should have memberships based on eligibility. We’ve been playing with two concepts, vetoMembershipIfNotInGroup and groupIntersection. However the veto one seems to require the source group to only have direct memberships. This however defeats the purpose of using reference groups to inform the system of the eligible population. Oddly enough the groupIntersection seems to work but it relies on the changlog to trigger.
Is this expected behavior for veto?
Thanks
Jeffrey C.