Grouper Users - Open Discussion List

[Jeffrey Crawford <>]

Sorry lost track of this one, I'm not entirely sure I understand the point 2. can you outline an example of the problem?

Jeffrey E. Crawford
Enterprise Service Team

Both pilots and IT professionals require training and currency before charging into clouds!

---------------------------------------

On Sat, Aug 13, 2016 at 11:33 AM, Shilen Patel <> wrote:

This was actually partially working in Grouper 2.3, but there were a couple of issues.

1.  The shorthand method of creating rules (e.g. RuleApi.groupIntersection) was indeed using direct members.  That said, it is possible to create rules with effective memberships by either changing the rule after creation or using the longhand method.  The trick is that instead of specifying "RuleCheckType.membershipRemove.name()" as the check type, you would specify "RuleCheckType.flattenedMembershipRemove.name()".

The way that the flattened membership rules work is that they use a built in change log consumer (grouperRules) to fire the rules.  As long as you're running the Grouper Daemon and you haven't disabled that change log consumer, this should work.

2.  Doing the above would get your rules to fire properly with effective memberships.  But there's still another problem.  There's a rules daemon that runs with the Grouper Daemon.  In the case of group intersection, if somebody got added to the first group but they weren't a member of the second, it is the rules daemon that would remove the membership in the first group.  However, in 2.3 the rules daemon wasn't set up for flattened membership removes (only for direct membership removes).

So anyways, I added a fix in Grouper 2.4 to address these issues.  All newly created rules (except veto rules) created via the shorthand method will default to effective memberships.  Existing rules won't change automatically, but we may need to discuss whether there should be an easy way to change existing rules during the 2.4 upgrade.  And also, the rules daemon is fixed (again in 2.4).

I opted to put this fix in 2.4 since it's a change in requirements for having the rule work properly (you need to run the grouperRules change log consumer).  But if it's needed in 2.3, let me know and I'll create a patch in 2.3.

Thanks!

- Shilen

From: Jeffrey Crawford <>
Date: Friday, July 1, 2016 at 8:35 PM
To: Gouper Users List <>
Subject: [grouper-users] Re: composite-ng intersection

okay quick update, it looks consistent that RuleApi.groupIntersection will only work when the user is a "direct" member of the mustBeInGroup, if the member is an indirect member it fails to trigger.


Jeffrey E. Crawford
Enterprise Service Team

Both pilots and IT professionals require training and currency before charging into clouds!

---------------------------------------

On Fri, Jul 1, 2016 at 5:14 PM, Jeffrey Crawford <> wrote:

Hello,

I have a request that users are removed from groups when they are no longer eligible for a service using RuleApi.groupIntersection(subjectActAs, ruleGroup, mustBeInGroup)



if the mustBeInGroup is a group where the user is removed from directly it seems to work correctly, if however mustBeInGroup is a nested group it and a user is removed via being removed from one of its sub groups it seems to ignore the rule (I haven't tried this with composites).



I'm not sure if that the intention or if its a bug, however if its intentional it seems like you would have to maintain two lists, one with the rule api and the other in the tested group.



I hope I'm making sense. Let me know if I'm missing something.


Jeffrey E. Crawford
Enterprise Service Team

Both pilots and IT professionals require training and currency before charging into clouds!

---------------------------------------