Grouper Developers Forum

[Chris Hyzer <>]

That is similar to what I want.  When you say a UI show members in the all 
group, you mean when you are searching for subjects to assign to groups, 
right?  I think we would want that too, but it does sound more complicated... 
 Maybe if I make the design less flexible (i.e. less hierarchy, and maybe 
less allow/deny, just an allow list), then maybe it would be easier to 
calculate and thus better performance... hmmm

Chris

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Tom Barton
Sent: Friday, January 28, 2011 11:24 AM
To: 

Subject: Re: [grouper-dev] veto if not eligible

This is similar to a need in the CO/VO space. In that context each
project, working group, activity, or what have you is assigned a folder
in which they'll do all of their groups, attributes, & permissions.
They'd also like to limit memberships to subjects in a folder-specific
identified "all" group, ie, all the people involved in this project.

So this might go a little beyond what Chris describes, in that a UI used
by a project lead to assign group memberships should only show members
of the project folder's "all" group.

Tom

On 1/27/2011 1:18 PM, Chris Hyzer wrote:
> There is a rule available in 2.0 where if someone is not an employee,
> they aren't allowed to be added to a specific group.  I would like
> something similar, but a little different.
> 
>  
> 
> The use case, is we don't want subjects from the external subjects
> source to be added anywhere except in a specific folder.  We don't want
> Grouper users accidentally putting external users in groups.  Granted
> the app might not be shibibolized, but that's ok.  This rule could be
> done by source, or I guess it could be done by group (we could have a
> group of all external subjects) as well, or both.  We will soon have
> applicants in our person registry, and we have lots of alumni, etc which
> could also have similar restrictions.
> 
>  
> 
> i.e. I think we would like to have a bunch of ACLs on folders, and
> membership adds would have to follow the rules.  Do we do allow before
> deny on matching rules?  I guess this is configurable.
> 
>  
> 
> Example:
> 
>  
> 
> Root folder: forbid externalSubject source (or group)
> 
> Folder school:apps:federatedApps: allow externalSubject source, order:
> allow/deny (though order doesn't matter since this folder has one rule on it
> 
>  
> 
> So when a member is added to a group, it would need to traverse up the
> folder structure, looking for rules, and seeing if the there is a
> matching rule.  If there is a matching rule, then follow the order (e.g.
> allow/deny or deny/allow), and get the answer (stop traversing).   Note,
> if you do this by subject source, it would be very fast.  If you do this
> by group then it will require queries to check group memberships (as
> groupersystem of course).  However, I could imagine that it could
> traverse, see which memberships it needs to check, and do this in one
> query (assuming less than 100 groups to check J ), then process the logic.
> 
>  
> 
> So if we do this by group membership, then you could say, all users in
> groups in the app folder must be employees.
> 
>  
> 
> I wasn't planning on having a daemon  that cleans things up or a rule on
> membership remove since it would be kind of time consuming to process
> all the info, but maybe we need that as well, e.g. if someone falls out
> of employee, they could fall out of required application groups by
> folder J  Actually, I could picture a change log process that would do
> this efficiently.
> 
>  
> 
> Thoughts?
> 
> Thanks,
> 
> Chris
>