Grouper Developers Forum

[Chris Hyzer <>]

I should mention, we should wait for the subject search part until the new 
columns (e.g. search string[s]) are added to the grouper_members table (hard 
to search subject sources for subjects in groups without this)... I think we 
said Shilen is doing that part, Shilen, are you planning that for Grouper 2.0 
in april?  :)

Thanks,
Chris

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

 
[mailto:]
 On Behalf Of Chris Hyzer
Sent: Friday, January 28, 2011 2:38 PM
To: Tom Barton; 

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

Ok, so lets revise the design...

On a folder you have the opportunity to say that subjects in the folder must 
be in a group (or subject source?  Or folder structure?).  When a membership 
is assigned, or subjects are searched for assignments, then the folder 
hierarchy will be traversed upwards until there is such an assignment.  If 
there is none found, then no restrictions.  If there is one found, traversal 
will stop, and the subject must be in that group.  We can have a change log 
process that sees when subjects are removed from groups that are used in such 
rules, they will be removed from any group/privilege/permission in that 
folder structure.  A daemon could also run to sync things up.

So I would think you would allow all g:gsa (group source), and then have a 
group of people that can be used in folders.  I wonder what the default 
subject search in the UI would do... maybe it should run in the context of a 
folder... hmmm

Thanks,
Chris

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

 
[mailto:]
 On Behalf Of Tom Barton
Sent: Friday, January 28, 2011 2:26 PM
To: 

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

that's right - so when they are searching for a Subject to put in a
group, they only see their project's Subjects.

Tom

On 1/28/2011 1:20 PM, Chris Hyzer wrote:
> 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
>>
>