grouper-users - RE: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
Subject: Grouper Users - Open Discussion List
List archive
RE: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
Chronological Thread
- From: "Hyzer, Chris" <>
- To: "Crawford, Jeffrey" <>, Grouper Users <>
- Subject: RE: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership
- Date: Thu, 3 Oct 2019 06:00:07 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isc.upenn.edu; dmarc=pass action=none header.from=isc.upenn.edu; dkim=pass header.d=isc.upenn.edu; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r9vNfKlDA2ZK99q32THPuibCRMk5HUHJMRg05b+bv3g=; b=Ch4+AY9kMFexlgk/7L2GEhh+BruiU9cgnBVSBGgrsfHH0gmr6+dGJckJRGvYksg9gourizjRpDCfcjysfwGEgpa9KhGxDovzy2Sbl8uG4g0h5pf2aQzaYRQU70ZMSnBKrD0P2DKtB/LaPDwookzZItIXZQ6jcaPuxFq3n1Z9wrk+30c0s+RpyW6D5ywN15FM/+WKvemtx8EC1WJHPKmigkqR6yWWbgMLT/EvZnogm1WJNcOETroFl8EuxV1QEM89bzP4a/utWtqioJnhATTtsSi9YWnhi15oH/SDNo7s69PivicSO9n4XjCqn/jH6/3DV4ShPZXvGJ8hXdB58RWs/w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Howap3pT4q5bGeL5jv98tF1CGNSy1dsSurt5yrAq3NuWcaPz4Am1VsP9THKEvMFNsQeU3f8jr99mJ+Dr7wCzlUDuFai3mjcGIlz7CoxqBzeibWwIBe1iPef9vdpjtd7j0NL7YsvVpt4Nfgjpdi5cuFs4Rx53Z79RwQKLNNU2+BKM7Qfs1Wg2Z5eyDk+ypTpEH4guaO587q4qpyT612RM9iB9weKRCofd7pMtVJCUhkOCaUviunkCzfn4fgD2LkKUizQqoOE0tXNCJlYySK7OKCYWReJ2XnkBd6O9ZScGm707DO0fsMI/lJ85r0Y8hhE6AkgJa8zN/eLxW+hWWTk3rA==
|
What you want is:
Change log consumer added to the “rule” change log consumer, which sees if:
Flattened membership removed from required group (e.g. removed from TEMP affiliation group which is a member of the employee group) -and- Has a direct membership in a group in the folder which requires the employee group -then- Remove that membership
The membership is permanently gone, and would not be added back if the entity becomes an employee again.
Right?
Thanks Chris
From: Crawford, Jeffrey <>
Wanted to send a Bump to this. We are getting to the point where we want to test this.
Any chance this can be included in a patch?
Thanks Jeffrey C.
From: <> on behalf of "Crawford, Jeffrey" <>
That works for me. The project is long term anyway
Thanks Jeffrey C.
From: "Hyzer, Chris" <>
We could get that working in a 2.4 patch in the next couple of months if you like…
From: Crawford, Jeffrey <>
Bump 😊.
From: <> on behalf of "Crawford, Jeffrey" <>
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: <> on behalf of "Crawford, Jeffrey" <>
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" <>
We have not done any of the phases, are you interested in it? 😊
From: Crawford, Jeffrey <>
Hi Chris,
What are the “phases” are these future improvements?
Thanks Jeffrey C.
From: "Hyzer, Chris" <>
That use case is documented here, try it out
From: Crawford, Jeffrey <>
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" <>
The image might display better on a wiki…
https://spaces.at.internet2.edu/display/Grouper/Penn+team+collaboration+eligibility
From: Hyzer, Chris
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
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.
|
- Re: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership, Crawford, Jeffrey, 10/02/2019
- RE: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership, Hyzer, Chris, 10/03/2019
- Re: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership, Crawford, Jeffrey, 10/03/2019
- RE: [grouper-users] RuleApi.vetoMembershipIfNotInGroup only works with direct membership, Hyzer, Chris, 10/03/2019
Archive powered by MHonArc 2.6.19.