Grouper Users - Open Discussion List

[Martin van Es <>]

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 
about 
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. 
Our 
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 
pollute 
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.

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

and:
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 
course).

The above described marker-list query should thus also be group-type 
specific, 
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.


Regards,
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
E: 

W: www.igi.nl
----------------------------------
Op deze email is de disclaimer die te vinden is op webpagina 
"www.igi.nl/disclaimer" van toepassing.
For this email the disclaimer as stated on the webpage 
"www.igi.nl/disclaimer" 
is applicable.