Grouper Users - Open Discussion List

["Black, Carey M." <>]

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.

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



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

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