Grouper Developers Forum

[Shilen Patel <>]

Yes, I'm still planning to get that in for 2.0. :)

Thanks!

-- Shilen

On 1/28/11 3:37 PM, Chris Hyzer wrote:
> 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
> > >
> > >        
> >      
>