Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Grouper 1.5 planning

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Grouper 1.5 planning

Chronological Thread 
  • From: Martin van Es <>
  • To: Chris Hyzer <>
  • Cc: Tom Barton <>, "" <>
  • Subject: Re: [grouper-users] Grouper 1.5 planning
  • Date: Thu, 17 Sep 2009 11:42:48 +0200
  • Organization: IGI Group

Hi Chris,

On Thursday 17 September 2009 06:39:36 Chris Hyzer wrote:
> Hmmm, Im not sure if this will be available in 1.5 in WS... can you wait
> for 1.5.1 a month or two later? Maybe use the API in the meantime?

Forgive my ignorance, but how would I use the Java API in a PHP script? If
that's possible I see no reason to prefer WS or REST calls. Both the new GUI
and the Grouper server will run on the same machine (for the time being, as
long as load will permit). Would you suggest cmd calls to grouper-client and
parsing the result maybe?

> Would the only services you need be:
> 1. Assign an attribute value to an object (e.g. group)
> 2. Query groups which have certain attribute values

If with 'query' you mean FIND Groups that HAVE a certain attribute value(s?),
then yes. Apart from that, I would like to be able to show the values. So I'd
need to retrieve the complete multi-value list as attribute per group as well.
Apart from that, I would want to offer the end-user a selection of all
possible labels (probably an ajax drop-down suggestionbox) so I would need to
fetch a list of possible labels (for that group-type, see further) as well.

> Well, what I mean is the attribute framework will have a given type for an
> attribute. The ideal type is a "marker" type, where all values are
> registered in the grouper registry. So if a user wanted to free form
> write one in, then your UI would have to register that value as acceptable
> with the grouper registry before assigning.

My first reaction to this was "NO" I want a free-field! But then I realised I
want to fetch a list of already used labels from Grouper (to offer to the end-
user), so then the best (most consistent) way would be to inform Grouper
the labels used and so this solution would be only way to go?
I assume having Grouper manage markers would enforce global consistency as
well, as that would be a big advantage over keeping track of labels out-of-
Grouper. Eg. removing a label from the marker list, would remove it from all
groups that have it applied as well? Likewise for renaming?

The reason I want to offer all defined labels is to prevent users from making
up new labels on the fly if a similar (and applicable) one already exists.
intention is to discourage the creation of new labels a bit by only offering
it in a separate label maintenance part of the GUI, so that they won't
the label list (too much) we hope.

Also, the Grouper instance will be used by two separate end-user groups, for
which we will instantiate a different version of the GUI that will operate on
a different stem. Labels of one instance should not come up in the other GUI
and vice versa. My idea would be to create different grouptypes for that. The
markers would have to be group-type specific then.

Group-type: Students
Attribute: label, type: marker

Group-type: Faculty
Attribute: label, type: marker

Both groups have an attribute called "label", but should never share their
list of possible marker values. But groups sharing the group-type should (of

The above described marker-list query should thus also be group-type
or could be returned as a part of a get group-type call.

Hope my ramblings make any sense to you ;)

And again, I can not stress enough that we are still in the Functional Design
phase of the GUI, so a lot of requirements (among which labels) are still in
motion! One things we're sure of is that we're not going to use stems apart
from the end-user group separation.

Martin van Es
IGI Group
Identity management | Security | Webbased diensten

Vondellaan 136
3521 GH Utrecht
KvK: 30219986

T: +31 30 2800002
M: +31 621 212890
F: +31 84 2274415

Op deze email is de disclaimer die te vinden is op webpagina
"" van toepassing.
For this email the disclaimer as stated on the webpage
is applicable.

Archive powered by MHonArc 2.6.16.

Top of Page