Grouper Developers Forum

["Gettes, Michael" <>]

i agree with chris.  (i know it doesn’t matter, but given this conversation 
and others related - i figured i would express my view).

/mrg

> On May 14, 2019, at 9:28 AM, Hyzer, Chris <> wrote:
> 
> 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 
>