Grouper Developers Forum

["Black, Carey M." <>]

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