Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Group management lite UI

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Group management lite UI

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Niels van Dijk <>
  • Cc: Grouper Users Mailing List <>
  • Subject: RE: [grouper-users] Group management lite UI
  • Date: Tue, 7 Jul 2009 10:10:24 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

> Some comments on the page:
> - How many groups do you assume a user has? How many uses will a group
> have? Some of the features you propose seem a bit tricky if you have
> say, several 1000's of users and a equivelent number of groups.

I don't make any assumptions, we have a fairly large deployment where it took
work with the existing UI to make it work well for large groups or people
with a large number of groups. I believe we have all that figured out. If
there is a query you need to run, let me know, it is probably possible. The
one gap that I hope to fix at some point is it is not possible to sort and
page a large membership list by a person's name. This is because the subject
API could be ldap and would need to fetch all members (something that goes
against paging). I think the fix is to store a little more info (which could
get a little stale) in the grouper_members table so we can have a sort string
to join in one query.

> - What do you mean with 'Will not (at least initially) have information
> about immediate/effective, will be simple'?

I mean, you cant see why a member is a member, i.e. which groups are in which
groups which makes the result that the user is a member. You will only see
if they are a member, and removable.

> - 'Externalized text' will allow for translations?

Yes, at least one, but hopefully resource bundles so you could have multiple

> - the ability to filter the user list is required if the number of
> users
> is large


> - Why introduce new, undocumented WS and not just use the ones already
> there? If you feel these are currently not sufficient, would it not be
> a
> better idea to fix that problem (so fix the ws's)?

Well, yes, I will use the existing calls when possible, but in some cases
not. It would be great if the existing or augmented WS could be used for a
UI. However, in this UI all communication to the server will be WS. So when
I need to get the templates or externalized text, etc, it doesn't make sense
to have a generic WS for that. There is no WS for searching subjects (we
need to add this). Also, I need to get up and running quickly and on 1.4.2,
so I wont have the opportunity to change any WS. Finally, I picture needing
to tweak the information in/out for the UI, and versioning the WS is tedious
and I try not to change them once a version of grouper is released. But
hopefully this exercise will identify some ways to expand the current WS to
make it more powerful. E.g. we will add a json2 format (assuming one person
out there wants to keep the existing JSON... I would be surprised and
sympathetic if anyone happens to be using that :) ).

> One feature that seems to be missing for me is the ability to provide
> federated authentication as a basis for login into the gui.

How would this work? I think you need a custom subject source where you can
enter in ID's, and then link that up on login. It would be better if the app
could add new authenticated users to the custom source table so there is no
mistyping. I think this would not be hard unless there is more to it. :)
Penn is in process to shibbolizing, once we are I can do a proof of concept.
How do you picture it working?


Archive powered by MHonArc 2.6.16.

Top of Page