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: Chris Hyzer <>
  • To: Tom Barton <>, "" <>
  • Subject: RE: [grouper-dev] veto if not eligible
  • Date: Fri, 28 Jan 2011 14:20:28 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

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


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

Archive powered by MHonArc 2.6.16.

Top of Page