Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] two attribute framework notes

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] two attribute framework notes


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Tom Zeller <>
  • Cc: "" <>
  • Subject: RE: [grouper-dev] two attribute framework notes
  • Date: Mon, 28 Sep 2009 14:21:44 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

>
> Chris,
>
> To make sure I understand, are you saying that instead of :
>
> group.grantPriv(attrDef, subject);
>
> the API will be
>
> attributeDef.grantPriv(subject, group);
>
> ? And that this way, the group object will have less (new) methods ?
>


It's a little complicated... to grant a privilege on a Group now, you call:


group.grantPriv(subject, AccessPrivilege.READ);

To see if they have a privilege, you call:

group.hasRead(subject);

This adds a lot of methods to the group object. So... to assign privileges,
instead of putting lots of methods in the group object, like this:

NO:
group.assignAttribute(attributeDefName1_1);

YES:
group.getAttributeDelegate().assignAttribute(attributeDefName1_1);

So now we can put a bunch of attribute methods in the delegate, but it
doesn't muddy the Group API.

The privileges are *very* fine grained. So in order to operate on a group,
there are privileges: ADMIN, UPDATE, READ, VIEW, OPTIN, OPTOUT. Attributes
also have those privileges (well, just like them, but not exactly the same).

So lets say a group has an attribute. If someone calls:

group.getAttributeDelegate().hasAttribute(attributeDefName1_1);

That will throw a not allowed exception. Lets say someone is an admin on the
group:

group.grantPriv(subject, AccessPrivilege.ADMIN);

Then they call:

group.getAttributeDelegate().hasAttribute(attributeDefName1_1);

It still throws a not allowed exception.

So the person also need to be able to ATTR_READ the attribute (here is how to
assign a priv to an attribute definition):

attributeDef1.getPrivilegeDelegate().grantPriv(SubjectTestHelper.SUBJ2,
AttributeDefPrivilege.ATTR_READ, true);

Now the user can read the attribute from the group.

Yes, this seems a little complex, but it will be very nice, since we will be
able to have system attributes that no one will see, and people can create
their own attributes that others don't need to worry about. Plus, when it
comes to who can assign or unassign the attribute, or edit the definition, it
will be fine grained.

Thanks!
Chris




Archive powered by MHonArc 2.6.16.

Top of Page