Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

I missed this email first time round - belated responses below.

Gary

--On 30 June 2009 11:10 -0400 Chris Hyzer 
<>
 wrote:

> > 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?
This is partly semantics. I'm used to the idea of an object associated with 
a type(s) which define a set of named and typed attributes. It seems like 
you are trying to encode everything as special kinds of attribute and in so 
doing inventing new, or changing established, vocabulary which makes it 
harder to follow the approach. Some of this may be implementation detail 
and appropriate method naming may hide that e.g. you say 'Going further, we 
could have an attribute type called "type", so the complete choices for 
attribute type would be: attribute, permission, limit, type.', so I would 
advocate specific methods for querying, adding and removing types - as we 
do for the current setup rather than the public API treating everything as 
attributes.

I'm still not sure about trying to make our new attributes multi-purpose in 
the way you are suggesting. I can see having 'types' for permissions, 
limits and scopes which are encoded through generic attributes. You would 
then have to be able to add multiples of types to a group etc - which you 
can't do at the moment with group types. At this point I would think of 
permissions, limits and scopes as being typed objects and you could attach 
multiple objects to a group, stem etc.
> > > 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?
Yes - each grouper_groups would have a field which specified the subject 
type - null would indicate no restriction.

We're supposed to be moving away from subject types (which I was never 
happy with) and relying on source to provide clues to treat subjects 
distinctly, in which case a source would need to have a type as names are 
variable...
> > 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.
OK
> > 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.
The difference is that lists are only there if you you define them for a 
type and assign the type to a group. Actions are always there and are 
permission specific - but that just comes back to whether we should be 
loading attributes in this way.
> > 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...
Not sure I follow - but I think it is related to your idea of 'privilege 
set' - which to me is a role.
> > > 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.
As I indicated above I prefer the idea of assigning a type or typed object 
rather than an attribute which makes other attributes available
> Chris



----------------------
GW Brown, Information Systems and Computing