Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Attributes and permissions around them....

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Attributes and permissions around them....

Chronological Thread 
  • From: "Hyzer, Chris" <>
  • To: "Black, Carey M." <>, "" <>
  • Subject: RE: [grouper-dev] Attributes and permissions around them....
  • Date: Sat, 11 May 2019 16:32:03 +0000

Its very annoying not to be able to delete things. If you can remove an
attribute assignment, and don't have access to remove the metadata, it should
just do it (as it does). I think generally if you can unassign an attribute
you have some ownership on the metadata even if you configure privileges
contrary to how we normally do (equal privs on attrs and metadata). Right?

Was there something else? It's a little confusing...


-----Original Message-----
From: <>
On Behalf Of Black, Carey M.
Sent: Friday, May 10, 2019 3:00 PM
Subject: [grouper-dev] Attributes and permissions around them....

Ultimately I think I found a bug. However, I suspect some will call this a
As will all things attributes. Language makes it difficult to follow. So I
will do my best to setup the conditions. (and here are more than a few.)


2 Attribute Definitions.
Each with a single(could have more) Attribute Name.
Each with slightly different permissions.
3 groups:
A) Wheel (or some other "elevated" priv level)
B) "usersOfSystemX"
C) "groupWithAttributes_attached_to_It"

AttrDef #1:
Name = attachedToGroup ( type = Attr ), Assignable to Groups, ( multi
assigned, but I don't think this matters), Values are "String".
Has an Attribute name called "attached".
Group A: Admin
Group B : Def Read, Def Update, Attribute Read

AttrDef #2:
Name = metaDataOnGroupAssignment ( type = Attr ), Assignable to
attribute assignments on Groups, ( single assigned, but I don't think this
matters), Values are "String".
Has an Attribute name called "meta1".
Group A : Admin
Group B : Def Read, Attribute Read

User from Group A adds attributes onto group
"groupWithAttributes_attached_to_It" as follows:

Assign "attached" to the group
Add a value of "Group B can edit this string" to "attached" "
Assign "meta1" to the assignment of "attached"
Add a value for "meta1" = "A Value to show a user, but not
let them change. It drives business logic in Hooks/Change Log Consumers".
Group A : Admin
Group B can Read, Update, Attr Read, Attr Update this group.

When a user of Group B views "Attribute Assignments" for they group they see
both assignments and the values. (So far, all good.)
If the user tries to change the value of "meta1" ( Any of the Actions
menu options) the UI gives the user a screen, then fails on Submit, or delete
attempt, or update attempt. ( Again.. all good. But it would be a nice
enhancement if they could not see the Actions button in this case. :) )
The user can remove the value of "attached", add a new one, and update an
existing value. ( Still all good.)

Here is where things go sideways. ( IMHO )
If the user deletes the assignment of "attached" the UI does
something very odd.
It successfully deletes the "meta1" attribute assignment for
the user. (But they can not edit/update/delete it directly themselves! )
Then it deletes the "attached" attribute assignment too. (
Ok, they can likely do that part. )
I find two parts of this odd;
The user said "Delete the attached attribute" but the "meta1" is
deleted for them first.
Given that Grouper does not like to delete objects with
"child objects" I guess the order makes some sense.
However, the privilege escalation is a bug. ( IMHO )
And I was not able to see an "attributeAssignmentPreDelete()"
for "attached" before the delete of "meta1" started. So I could not hook the
action the user took. ( Grumble...)

Two: I have not found a permission combination that allows a user to
edit an attribute assigned to an attribute assignment without also having
edit on the attribute attached to the grouper object.
AKA: Can edit meta1, but not edit "attached".
Technically not something I want right now, but it seems like
it should be possible to do that too. I am ok if this is a design choice. It
is just not documented anywhere that I can find.

FWIW: After enough experimentation, I have a custom
AttributeAssignHooks.attributeAssignPreDelete() that will validate that the
logged in user has Admin or Update on the AttrDef of the attribute assignment
being deleted, or throws.
So I have a stop gap for the current behavior of the system.
I would rather the system change to honor the permissions of the meta
assignments consistently.

I model this on the GrouperDemo server 2.3


(And I suspect you can get Wheel on your own. :) )

Carey Matthew

Archive powered by MHonArc 2.6.19.

Top of Page