Grouper Developers Forum

[Chris Hyzer <>]

> GB: 6/30/09: Sounds like we ought to think of this as adding objects
> where
> an object type definition defines the attributes. permission, limit,
> type
> etc would simply be object types with specific attributes


Im losing you here... can you give a clear and precise example and use case 
for a custom object, so we are talking about the same thing?

> > Yes, I have thought about this we could have an attribute, when
> applied
> > to a group, would activate a trigger to restrict which types of
> subjects
> > can be added
> GB: 6/30/09: I think you would want it as part of the group definition
> i.e
> a system may create empty groups intended for a specific purpose which
> are
> only allowed Subjects of a particular type (or groups with the same
> restriction)

Are you saying you want a Group field vs an attribute? 


> GB: 6/30/09: Having attributes attached to a Membership row would make
> them
> dependent on that individual Membership, which may be what you want,
> but is
> also susceptible to loss if a process drops memberships and recreates
> them
> - I'm not saying it shouldn't be possible but users should be aware of
> the
> maintenance issues

Yes,  that is why they can be attached to memberships.  Then the group math 
(user isn’t an employee anymore) would drop all their access...  Yes, we need 
to make users aware of this.


> GB: 6/30/09: I'm all for 'extending' a group to make a role - just want
> to
> be clear on what the members are - and as Members are Subjects that
> implies
> that objects/attributes are subjects - otherwise you are creating a new
> mechanism for inheritance?

The members are the subjects: people logging in (or groups or whatever).  The 
privileges are attributes on the group/role.  Need to keep them in separate 
places so things are clear.

> GB: 6/30/09: I think this is where privileges are 'polluting' the
> attribute
> framework. If we have an object type which is a privilege, it can have
> generic attributes one of which is 'actions' - a multivalued String
> i.e.
> every attribute def shouldn't have implied actions

All the actions do is allow a three-way assignment.  If you don’t want that, 
then the default is just one action.  Just like groups and lists.  Most 
groups don’t need lists, they only need "members", but it isn’t a problem, 
just don’t use them.


> GB: 6/30/09: So what is the 'role set' mechanism? An additional
> inheritance
> mechanism?
> > mechanism.  If sites want to provide sources, they can use the
> loader.
> > e.g. your org structure could be loaded in with the loader.
> GB: 6/30/09: I was thinking of subject sources - a way of referencing
> external data without having to pull it into Grouper

I think subjects for privs are fine, and they are in the design.  But if you 
want a hierarchy where one privs implies another, then they need to be in the 
system, not external...


> > custom validators on attribute validators, and link up attributes
> with
> > the assignment of another attribute, which is like the current
> > implementation of type
> GB: 6/30/09: Not quite sure I follow this - are you talking about
> targets
> for a permission?


This means, an attribute (or permission), is only assignable if another 
attribute is assigned.  So like the current attributes.  First you assign the 
group type "grouperLoader".  Then you are allowed to assign the 10 
grouperLoader attributes.  Same thing with the next implementation: you 
assign the attribute "grouperLoader", and that allowed you to assign the 
other 10 attributes.

Chris