Grouper Developers Forum

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

--On 21 January 2005 08:52 -0600 Tom Barton 
<>
 wrote:

> GW Brown, Information Systems and Computing wrote:
> > I started experimenting with custom group types and came across some
> > things I didn't expect:
> >
> > 1) A new custom group type did not 'inherit' all the base type
> > attributes, I had to explicitly add them to the grouper_typedef table
> > before I could create a group of custom type because the attribute
> > checking didn't recognise 'name' etc.
> >
> > I thought that the reason for having a base type was to ensure that all
> > groups would automatically have the essentials Grouper needed to
> > function internally.
>
> Bugzilla #271 is to complete support for groups having multiple types.
> Until that's there, the single type they're allowed must have everything
> in it.
>
> > 2) The uniqueness of the 'name' attribute is not enforced - two groups
> > with different types can have the same name.
> >
> > I can see that a stem (implemented as a group) might have the same name
> > as a group, but having actual groups be able to have the same name would
> > be confusing and create problem instantiating a group by name, as
> > discussed in 3.
>
> Witrhout looking into the specifics, I know that we arrived at the final
> naming model too late to get it all baked into the 0.5 release. I assume
> this issue is an aspect of that fact.
>
> > 3) The GrouperGroup.loadByName(GrouperSession s, String name, String
> > type) requires that you know the type of a group before you can load it.
> > In the UI I have been using the group name as the identifier to pass
> > around - it makes debugging a lot easier. I can't use this approach if
> > group names are only unique to their type - unless I start passing the
> > type around as well, but I don't really want to do that.
>
> Name uniqueness will return with completion of support for the final
> naming model, but even if they're unique, names can change (maybe during
> a UI session). The only unambiguous way of referring to a group is by its
> guid (value of GrouperGroup.id). Use GrouperGroup.loadById and consider
> 'name' as a changeable attribute of the group.
As it happens loadByKey and loadById both require me to know the group type 
in advance - or accept the default type of 'base'. GrouperBackend appears 
to do the lookup correctly, but GrouperGroup forces a type assignment on 
the returned group.

> Tom



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