Grouper Developers Forum

[Chris Hyzer <>]

> attribute creation rights are delegated. So I agree with TomZ that we
> should build this in up front, even if we don't intend initially to

Yes, we will definitely have and use namespaces... I learned the lesson from 
the current implementation of global group types...  its good for a few uses, 
but hard to do widespread across many apps that use grouper.

> Of course, namespace management is one of grouper's primary
> capabilities, so we can leverage what we've already built.

Absolutely

> And we'll need to recognize that some attributes are delivered with the
> system and so reserve a namespace for those.
> 
> I suppose we could root the namespace for attributes in the local
> grouper database under a new root stem, say attr:, or under the etc:
> root stem, as in etc:attr:. Then delegation is supported in the usual
> way.

I was thinking about this, and I would prefer it if the institution specified 
a location for Grouper builtin attributes.  For Penn it could be 
penn:etc:grouperAttrs, then grouper will auto-create the structure in 
there... maybe the default could be etc:attr, but the site could customize

> But we'll need a convention about which object type under this stem
> define attributes, probably constrained by the requirement (if we keep
> it) to enable attributes to be attached to attributes. Eg, will the
> group etc:attr:enabledate lend its name to the enabledate system
> attribute? And if Bob is delegated CREATE to etc:attr:bob:, then he can
> define attributes starting with bob:?

I think he will be able to create attributes starting with etc:attr:bob:, 
yes. 

I added a few more points to the wiki regarding this and other things... :)

Thanks,
Chris