Grouper Developers Forum

["Hyzer, Chris" <>]

Lets say you create a group.  And you grant privs to let other people READ 
it.  and someone else assigns a priv to that group to their group so your 
group can UPDATE their group.  But you don't have ADMIN on that other group.  
Are you allowed to delete your group?  In my view yes since you own it and if 
someone else uses it, they are at the ADMIN of the group's mercy since the 
ADMIN owns it.  In your view, maybe not, since you cant unassign that 
privilege assigned to your group.  You would have to go around and ask 
everyone to remove the references to it or maybe beg a grouper admin to 
delete it...

-----Original Message-----
From: Black, Carey M. <> 
Sent: Saturday, May 11, 2019 11:03 PM
To: Hyzer, Chris <>; 
Subject: RE: Attributes and permissions around them....

Chris,

You summarized the point better than I could. Thank you.


I think that systems should not contradict themselves.
        So I hold to:   "I would rather the system change to honor the 
permissions of the meta assignments consistently."
                I have my preference for which "consistency" I want the 
system to go with. But any consistency is better than inconsistency.



RE: "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). "

If privileges are configured, then they should be honored. ( <-- This point 
should win the day for the "current state is a bug" camp. )
        If configured privileges are "ignored" because the system thinks they 
are an "error" ( or an annoyance to a user ) then they should not be 
configurable. Or at the very least, Well known to be "ignored, some of the 
time".
        And
        If privileges are "implied" ( by system design/will ) then the system 
behavior should be consistent in all cases. <-- ( the system is not doing 
that now.)
                AKA: If all meta data privileges are driven from the 
attributes they are assigned to, then the system should know that and allow 
the "implied" actions under all "action" contexts.
                So if the user can "delete" they should be allowed to delete 
it ( the meta data) with the "delete" button on the meta data too. ( The 
system is not doing that now. And I think correctly so, because I configured 
the privileges to not allow it. See point one.)


Sounds like the behavior that I expected the system to enforce is not a 
design of the system.  ??!??


Maybe this design of the system needs:
        better documentation
        more consistent UI functionality to support/communicate the design

        Or reconsidered?


I guess I need to plan on my current approach breaking, and come up with a 
"better idea".... (Some way to "auto fix it" when the user "breaks it".    
hum...)
        Though I think my hook should be able to essentially requiring the 
meta data attributes permissions to be honored. ( Even if the "delete" button 
is enabled in the UI....) 
        Maybe both approaches can have their our cake and eat it too?

-- 
Carey Matthew 

-----Original Message-----
From: Hyzer, Chris <> 
Sent: Saturday, May 11, 2019 12:32 PM
To: Black, Carey M. <>; 
Subject: RE: Attributes and permissions around them....

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