Skip to Content.
Sympa Menu

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

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] veto if not eligible

Chronological Thread 
  • From: Shilen Patel <>
  • To: Chris Hyzer <>
  • Cc: Tom Barton <>, "" <>
  • Subject: Re: [grouper-dev] veto if not eligible
  • Date: Fri, 28 Jan 2011 16:14:36 -0500

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


-- 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? :)


-----Original Message-----

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


-----Original Message-----

On Behalf Of Tom Barton
Sent: Friday, January 28, 2011 2:26 PM

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.


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...


-----Original Message-----

On Behalf Of Tom Barton
Sent: Friday, January 28, 2011 11:24 AM

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.


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.


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.




Archive powered by MHonArc 2.6.16.

Top of Page