Grouper Developers Forum

["Hyzer, Chris" <>]

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...

Thanks
Chris

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

Ultimately I think I found a bug. However, I suspect some will call this a 
feature.
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.)

Setup:

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".
        Permissions: 
                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".
        Permissions: 
                Group A : Admin
                Group B : Def Read, Attribute Read

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

"groupWithAttributes_attached_to_It"
        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".
        Permissions:
                Group A : Admin
                Group B can Read, Update, Attr Read, Attr Update this group.

Tests:
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

 userFolders::groups:groupWithAttributes_attached_to_It
 userFolders::groups:usersOfSystemX

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


-- 
Carey Matthew