Grouper Developers Forum

[Tom Barton <>]

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.

Tom

--

https://mail.internet2.edu/wws/arc/grouper-dev/2005-01/msg00002.html

> > > /populateGroupSummary
> > >
> > > 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="/populateEditGroup.do" 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