Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] some attribute framework discussion topics

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] some attribute framework discussion topics

Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] some attribute framework discussion topics
  • Date: Mon, 05 Apr 2010 10:04:34 -0500

Chris Hyzer wrote:
1. If you want to query assignments on assignments, you need to query
the assignments with a special flag, or provide the assignmentId

2. Security:


- read attribute
- view group and read attribute

- assign attribute
- admin group and update attribute

I can imagine use cases in which a group's admin is not the same as the person who's responsible for some of the attributes assigned to the group, ie, there's two sources of authority to be combined: for membership and ordinary group info, and for a special attribute (maybe a priv). I think we'd need to add some new element to grouper's security structure to support this type of separation of duties. The model above doesn't do it.

More commonly, I think, attributes are available to group admins as ordinary means to decorate a group. In this case I can imagine the UPDATE priv for an ordinary attribute to be set to Everyone, and your assignment security model works fine, although it's overkill for this use case.

It seems that to cover both use cases we need a way to list which Subjects can assign an attribute to which other objects. I can see scoping the other objects by the stems in which they reside. Eg, Subject 1 can assign Attribute royal:privs:palace_key to all objects under royal:musketeer:, enabling Subject 1 to assign that priv to any group of musketeers, to any memberships in those groups, or to any substem of royal:musketeer:.

Until we implement something along those lines, is it sufficient to just let a group ADMIN assign any attribute they can READ to the group?


- read attribute
- read attribute

- assign attribute
- create in stem? and update attribute

The analog for a stem of ADMIN for a group is STEM. Like my rationale for groups, for the time being perhaps just let those with STEM who can READ an attribute assign it to the stem.


- read attribute
- read attribute

- assign attribute
- wheel or root? and update attribute

Wheel sounds right, at least for now. I don't see the need for UPDATE on the attribute here.


- read attribute
- read attributedef and read attribute

- assign attribute
- admin on attributeDef and update on attribute

Just READ on attribute, as for groups & stems above.

Membership (immediate or any): note, only members list on groups

- read attribute
- read the group and read the attribute

- assign attribute
- update the group and update the attribute

Only READ on the attribute, as above.

Assignment on attribute assignment

- read attribute
- read the underlying assignment (follow the above rules), and read the attribute

- assign the attribute
- update the underlying assignment? (follow the above rules), and update the attribute

Is "this assignment expires next Wednesday" an example of an assignment on an attribute assignment? What's a better example, to help guide our thinking about this?

3. Assignment of attributes on memberships is only on members list

... and not on privilege lists, eg, readers, updaters, etc. Agree.

4. If you want to assign an attribute to an immediate membership or an attribute assignment, you need to get the ID of it first

5. If you want to assign an attribute to an any membership, you need to provide the groupLookup and the subjectLookup

Archive powered by MHonArc 2.6.16.

Top of Page