Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

> 
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  
> On Behalf Of Black, Carey M.
> Sent: Saturday, September 09, 2017 10:49 PM
> To: 
> 
> Subject: [grouper-users] Does this make sense? or am I not looking at this 
> right?
> 
> Sorry for the long post.... you were warned. ( If you can just answer the 
> questions 
> at the top that would be really helpful.)
> 
> A general question about retrieving value(s) of an attribute on a 
> folder/group.
> Q) Is the order of the attribute values stable? ( FIFO, LIFO, or random?) 
> If needed I 
> could prefix the string values with an "order integer and a separator" to 
> sort the 
> values into the correct order at runtime.

Not ordered

> 
> Another general question... ( After poking at the Grouper code with a few 
> searches... )       
> Q) How exactly do you get ahold of the list of attributes on a 
> folder/group? Could someone 
> share a GSH script/Java code as an example?

attributeDefName = 
AttributeDefNameFinder.findByName("school:attr:students:artsAndSciences", 
true);
group.getAttributeDelegate().retrieveAssignments(attributeDefName);

> Q) How exactly do you get ahold of the attribute value(s) from an attribute 
> that is on a 
> folder? Could someone share a GSH script/Java code as an example?
>       Note: I did find this in the Hook.stemPreInsert()  but it does not 
> appear to do 
>       exactly what I want..... 
>                   
> preInsertBean.getStem().getParentStem().getAttributeDelegate().getAttributeOrAncestorAttribute(
>  
>                   attrDefName, (true|false) )
>               // if true = user current user credentials, if false, use 
> GrouperSystem 
>               credentials     (IMHO: A neat feature.)
>               // @return true if group or stem has attribute   
>               // yet it returns an AttributeAssignable object ??? ( not 
> really a Boolean 
>               value there. :) )
>               // not throwing rocks... just trying to kick some over to 
> figure things out 
>               for myself.
> 
> 

you can get the attribute value delegate on an attribute assignment and see 
methods from there, or group/folder has an attribute value delegate too...

> 
> Here is what I want to generally do:
> 
> I have a folder(stem) that I want to "force" some things to be true about 
> as users are 
> managing it over time.
> 
> Things like :
>       Folder structure below the stem ( auto create and guard against user 
> changes)
>       ID and name constraints (for both groups and folders), vary by layer 
> in the structure.
>       Simplifying user UI work:
>               When a group is added to a special folder, create a composite 
> group 
>               in another folder that excludes a "exclude group" 
> automatically.
>               Think of user creates a "Include Group" and the System 
> creates the 
>               "Access Policy" composite group for them.
>                       I did look at the "addIncludeExclude" functionality. 
> It mostly 
>                       does "the right thing", but not exactly. ( It is also 
> a pain 
>                       in the UI for users too. )
> 
> I think this is all fairly "normal stuff", but I am not clear on how to 
> limit/control 
> this level of detail in the system at this time.
>  
> I think I can do most, if not all, of this from the Hook pre/post methods.
>       I could do it with all kinds of hard coding and implement all of the 
> logic. But 
>       I would prefer to make data driven options with attributes on parent 
> stems.
>       Well, when I can get my head wrapped around the API to fetch and 
> process attributes..... 
>       but ... that task looks... interesting.... at this point.
> 
> Ideally I am thinking that a "few" attributes and a "few" custom Hooks 
> could get all of this 
> done for anyone.
>       My thought is to stick attributes on the "root" folder (stem) and on 
> constructed 
>       folders/groups inside the constructed sub folders(stems) to implement 
> the constraints.
> 
> 
> 
> If you want to know my current wish list... here it is: (WARNING:  Lots of 
> details, might 
> be half baked at this point....)
> 
> Here is what I am thinking for attributes and their functions( Hook 
> responses ):

After a quick read I dont really know how these attributes would be used with 
hooks.  Maybe some simple examples of attribute values and what the hook 
would do...  

thanks
Chris

> 
> Attributes for folders (stems)
>       folderStructure         (def:single assignable)
>               allowFolderCreate (name: single value) values only one of: 
> "ALL"(implied by 
>               not having the attribute), "one level", "NONE"
>               allowGroupCreate (name: single value) values only one of: 
> "ALL"(implied by 
>               not having the attribute), "one level", "NONE"
>                               Use this constraint from the parent folder(s) 
> to veto user 
>                               creates.
>                       And if I really want to be hard on myself....
>               allowFolderCreateByGroup (name: multiple value) values only 
> one of: ("ALL" | 
>               "ONE"| "NONE" ),"Group ID/REF" 
>                                               Example values: 
>                                                               "All", 
> "etc:wheel"
>                                                               "NONE","*"    
>                               (NOTE: * would mean all groups)
>                                                               
> "ONE","etc:MasterOfAllStems"
>                                                               ...
>               allowGroupCreateByGroup (name: multiple value) values only 
> one of: ("ALL" | 
>               "ONE"| "NONE" ),"Group ID/REF"
>                               If any pass for the user, then ok, else veto
> 
>       FolderStructureAutoCreate (def:single assignable)
>               AutoCreateFolders (name:multi value)
>                       Values like: ("stem","Folder ID", "Folder Name", 
> "Description")
>                               Where "stem" of "." = the current folder
>                                       "stem" of ".:Child_folder" = the 
> Child_folder of the 
>                                       current folder
>                                       If "stem of" is not relative, then it 
> could create a 
>                                       folder in some other structure in the 
> tree too. With 
>                                       the access authority of 
> "GrouperSystem". (or that could 
>                                       be a config value too...)
> 
>               AutoCreateGroups (name:multi value)
>                       Values like: ("stem","Group ID", "Group Name", 
> "Description")
>                               Where "stem" of "." = the current folder
>                                       "stem" not starting with "." = some 
> root folder(stem)
>                                       "stem" of ".:Child_folder" = the 
> Child_folder of the 
>                                       current folder
> 
>                                       ( processed after AutoCreateFolders )
>               AutoCreateCompositeGroups (name:multi value)
>                       Values like: ("stem", FirstFactorGroup, Operation, 
> SecondFactorGroup)
>                               Where "stem" of "." = the current folder
>                                       "stem" not starting with "." = some 
> root folder(stem)
>                                       "stem" of ".:Child_Group" = the 
> Child_Group in the current 
>                                       folder
> 
>                                       ( processed after AutoCreateGroups to 
> do conversion processes. )
>               AutoSetPrivileges (name:multivalue)
>                       Values like: inputs to gsh's grantPriv function
>                               grantPriv(group name, subject id, privilege)
>                               grantPriv(stem name, subject id, privilege)
> 
>               AutoSetInheritedPrivileges (name:multivalue)
>                       Values like: inputs to gsh's grantPriv function
>                               grantPriv(group name, subject id, privilege)
>                               grantPriv(stem name, subject id, privilege)
> 
>       AutoApplyAttributes  (def:multi assignable)
>               ApplysTo:       (name:single value)
>                                       Value is a stem, or Group   ( maybe 
> memberships could be 
>                                       used.. but I am not sure how at this 
> point..... )
>               AddAttributes:  (Attr_name, ("values","",...) )
> 
> 
>       GroupNameConstraints  (def:single assignable)
>               ApplysTo        (name:single value), values Only one of: "one 
> level" or "ALL" 
>               UseRules        (name:multi value)
>                                       Values like: RegEx::<some reg ex here>
>                                       Values like: FORCE_LOWER(min_length, 
> max_length)
>                                       Values like: FORCE_UPPER(min_length, 
> max_length)
>                                       Values like: LENGTH(min_length, 
> max_length)
>                                       Values like: ALL_DIGITS(min int, max 
> int) maybe that should 
>                                       be bigger than an int?
>                               And if I really want to be hard on myself....
>                                       Values like: <values above> &&, || 
> together.
> 
>                               If all pass, then good.
>                               If any fail, then fail.
>                               Each could "change the value".... "FORCE_" 
> would make the value that 
>                               case. "RegEx" might be able to do subs too...
> 
>       GroupIDConstraints  (def:single assignable) 
>               Same as GroupNameConstraints  , just for the group ID value 
> tests.
> 
>       FolderNameConstraints  (def:single assignable) 
>               Same as GroupNameConstraints  , just for the group ID value 
> tests.
> 
>       FolderIDConstraints  (def:single assignable) 
>               Same as GroupNameConstraints  , just for the group ID value 
> tests.
> 
> Any conflicts from the " FolderStructureAutoCreate" vs the 
> "folderStructure" should not be allowed. 
> ( AKA: FolderStructureAutoCreate hooks would trigger the full "create 
> folder/group logic" and the 
> "folderStructure" hooks would be enforced. )
> 
> 
> 
> 
> If you read this far: Thank you.
> ( after the first read: ) If you don't think I am completely nuts, and you 
> think you like the idea 
> then please read it again. Or not. Your choice. :) 
> ( after the first or second read: If you still like the idea, at least post 
> a "me too". :) )
> 
> 
> 
> If I am really lucky, maybe someone will take pity on me and think that 
> this relates to the "TODO: 
> Collect and code use cases" (Which dates all the way back to  Oct 2009 and 
> is still on the current 
> page. :) ) part of REF: https://spaces.internet2.edu/display/Grouper/Hooks 
> . :)
>       ( Yes I was thinking about you when I wrote that. Hope it made you 
> laugh.)
> 
> -- 
> Carey Matthew Black.123
> 
>