Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Action Items: Grouper Call 24-Jun-09

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Action Items: Grouper Call 24-Jun-09

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Chris Hyzer <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] Action Items: Grouper Call 24-Jun-09
  • Date: Wed, 08 Jul 2009 14:44:01 +0100

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


--On 30 June 2009 11:10 -0400 Chris Hyzer

GB: 6/30/09: Sounds like we ought to think of this as adding objects
an object type definition defines the attributes. permission, limit,
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
> to a group, would activate a trigger to restrict which types of
> can be added
GB: 6/30/09: I think you would want it as part of the group definition
a system may create empty groups intended for a specific purpose which
only allowed Subjects of a particular type (or groups with the same

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
dependent on that individual Membership, which may be what you want,
but is
also susceptible to loss if a process drops memberships and recreates
- I'm not saying it shouldn't be possible but users should be aware of
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
be clear on what the members are - and as Members are Subjects that
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
framework. If we have an object type which is a privilege, it can have
generic attributes one of which is 'actions' - a multivalued String
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
> mechanism. If sites want to provide sources, they can use the
> 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
> 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
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


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page