Subject: Grouper Developers Forum
- From: Chris Hyzer <>
- To: Grouper Dev <>
- Subject: built-in attribute/hook for folder level security
- Date: Thu, 20 May 2010 11:26:39 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
I know we are focusing on the release, but I just wanted to start thinking about a simple builtin folder security attribute.
Use case: I want all subgroups in a folder to have a READer of group a:b:c without having to remember to add it to each group.
Proposed solution: Stem attribute where you can set the privileges and groups which should have those privileges on subobjects. Then some hooks would make it happen.
i.e. an attribute:
folderSecurity, is multi-assignable, marker attribute
There is an attribute on the assignment which is folderSecurityPrivileges. Multi-valued strings of privileges e.g. STEM or UPDATE
There is an attribute on the assignment which is folderSecuritySubjects. Multi-valued subjectIds (which could be groups)
A hook on attributes:
If the folderSecurityPrivileges or folderSecuritySubjects changes, the look at all subgroups and stems and make sure they all have the subjects in the certain privileges
A hook on groups/stems:
If a group/stem is created, see if any superstem has the folderSecurity attribute, and if so, assign the appropriate privileges.
Note, two things can happen here:
1. If the user who assigns the folderSecurity doesn’t have ADMIN or STEM on the subgroup or substem, then those wont be assigned. If GrouperSystem or wheel assigns it, then its all good
2. If an ADMIN or STEM of a group or stem removes the security that the folderSecurity assigned, then it will be a little out of sync. I think this is a feature… J
Note that the stem attribute assignment can be done with web services, GSH, or API at the moment…
Ps. Note, Im not sure we have hooks on the new attribute framework yet, so this might be a 1.6.1 thing… J
- built-in attribute/hook for folder level security, Chris Hyzer, 05/20/2010
- Re: [grouper-dev] built-in attribute/hook for folder level security, Mirko Tasler, 05/26/2010
Archive powered by MHonArc 2.6.16.