Grouper Users - Open Discussion List

["Black, Carey M." <>]

The page seems to reference some “phases”(AKA: 2, 2.5, 3) of the rule logic… ( and the page is from 2012 ) What phase describes the current behavior of the system?

 

 

 

Would the “grouperIncludeExclude.requireGroups.use = true” feature also be an option? It would guard adding members.

                I think there is something that cleans up users that need removed too. ??

                Was it the “rules.quartz.cron”( or was it “changeLog.enabledDisabled.quartz.cron” ? )  would on your schedule to clean up the memberships when the users are “no longer in the group” right?

 

 

--

Carey Matthew

 

From: <> On Behalf Of Hyzer, Chris
Sent: Thursday, April 18, 2019 3:47 PM
To: Crawford, Jeffrey <>; Grouper Users <>
Subject: RE: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership

 

That use case is documented here, try it out

 

https://spaces.at.internet2.edu/display/Grouper/Grouper+rules+use+case+-+Veto+if+not+eligible+by+folder

 

 

From: Crawford, Jeffrey <>
Sent: Thursday, April 18, 2019 2:59 PM
To: Hyzer, Chris <>; Grouper Users <>
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" <>
Date: Thursday, April 18, 2019 at 10:08 AM
To: "Crawford, Jeffrey" <>, Grouper Users <>
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 <>; Grouper Users <>
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: <> On Behalf Of Crawford, Jeffrey
Sent: Thursday, April 18, 2019 11:41 AM
To: Grouper Users <>
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.