Skip to Content.
Sympa Menu

grouper-dev - background on GrouperAccess.has

Subject: Grouper Developers Forum

List archive

background on GrouperAccess.has

Chronological Thread 
  • From: Tom Barton <>
  • To:
  • Subject: background on GrouperAccess.has
  • Date: Fri, 11 Mar 2005 12:39:48 -0600

I had an action item to pull out past email leading to the GrouperAccess.has notion that holding a place in the 0.5.1 feature list. Below is a link to a message in the grouper-dev archive that captures part of that background, and below that is a snippet of a message that was sent among several of us off-list that also bears on it.

The general idea is to list a subject's read/write access to each of the fields of a group. This is a combination of the subject's privileges and the grouper_field table, in which grouper's access privs are mapped to field-level read/write privs. The desired variations need to be discussed: list all groups for which the subject has a given read or write access to a given field? List a subject's read/write privs for all fields of a specified group? Etc.




I need to think about this some more. Although, admin can be seen
as both a role and a privilege. No, I definitely need to think
about this some more.
I think the issue revolves around what is presented by the UI to a
user. The API already performs access management. My question back
to Gary & crew is what data structure would be suited to enable the
UI to avoid presenting or differentially present stuff the user has
no access to? How do you UI developer guys deal with this
ordinarily (he said terribly naively!)?
> Currently I am using JSTL tags:
> <c:if test="${groupPrivs.ADMIN || groupPrivs.UPDATE}">
> <li>
> <html:link page="/" name="group">
> <fmt:message bundle="${nav}" key="groups.action.edit"/>
> </html:link>
> </li>
> </c:if>
but <c:if test="${groupPrivs.<attribute_name>.write}"> .. </c:if>
would be better.

I'll explain the data structures in a minute, but the example, taken from actual code illustrates a point.

I now think that UPDATE privilege only gives the ability to change a group's membership and not the display name etc, so in the example I should remove || groupPrivs.UPDATE. This decision was a change to the
original policy. To make the change in the webapp I would need to go
through relevant JSP pages where permission checking takes place and
make the adjustment. If the original wider powers were returned to updaters we would have to go through the code again.

It would be preferable to change the read / write privilege in the grouper_field table so that the JSPs don't need to be changed.

In the example groupPrivs is a Java Map made available through a
Strut's action. I used: List privList = grouperAccess.has(s,group); to obtain access privileges and set these as keys with a Boolean
'TRUE' value.

What I envisage is a nested structure where the top level keys are attribute names and the corresponding values are themselves Maps (or
a simple object) which has 'read' and 'write' fields set to
TRUE/FALSE. This would allow me to iterate over a list of arbitrary
attributes and determine which ones can be displayed / modified by
the current subject

  • background on GrouperAccess.has, Tom Barton, 03/11/2005

Archive powered by MHonArc 2.6.16.

Top of Page