Grouper Developers Forum

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

The Grouper UI, except when in 'All groups' mode only presents the user 
with stems, for browsing, when the user has some privilege for that stem, 
or a descendant stem or group. The privileges checked depend on the browse 
option selected.

The UI makes one or more calls to Member.has<PRIV> to return all groups or 
stems where the user has at least one appropriate privilege. It then adds 
each parent stem name to a Map. When browsing each stem encountered is 
checked against the Map - if it is in the Map then the UI shows the stem.

This approach works well for users with relatively few privileges, however, 
Duke University has a use case where a group, TA Admin, is granted 
privileges to thousands of 'teaching assistant' groups for courses. This 
presents two problems:

1) Adding a member to 'TA Admin' is slow because effective privileges for 
the member are inserted into the database - for each teaching assistant 
group

2) Browsing using the UI is very slow because it takes some time to 
retrieve and instantiate thousands of groups.

So far we have looked at a couple of different approaches:
1) Constructing a SQL query which would join groups /stems to privileges
2) Using the API to recursively traverse the hierarchy

Neither is ideal as 1) is slow for someone with lots of privileges, and 2) 
is slow for someone with few privileges.

I have a couple of ideas for workarounds which could be effected as custom 
solutions by implementing API and UI interfaces, or, could, if deemed 
suitable, be made options for the core product.

1) the simpler, but less flexible approach, which would address the Duke 
use case would be to have a custom AccessAdapter implementation which 
automatically granted privileges for groups of a specific type to members 
of a specific group i.e. all teaching assistant groups are of type 'ta'. 
The implementation would cache TA Admin members and so would very 
efficiently return privileges - similar to the way the Wheel group works.

The implementation would not try to return all ta groups for the method:
        getGroupsWhereSubjectHasPriv

A custom RepositoryBrowser could query the database to determine if there 
are any ta groups below a stem.

It is now possible, in the UI, to present a new menu option for members of 
a specific group. This approach would mean that TA Admins would have 
'Manage Groups' and 'TA Groups' options.

As it would not be necessary to directly assign privileges to TA Admin to 
all ta groups, there would be far fewer records in the database and minimal 
cost to changing the membership of TA admin

2) One of Bristol's original requirements was to have the option of 
cascading privileges i.e. if some one was a departmental administrator, 
they would automatically have admin rights for groups in child stems to the 
departmental stem. This can be achieved in Grouper by direct assignment, 
but  is difficult to manage in a UI and leads to lots of database records.

It should be possible to use a specific group type and a naming convention 
for stems which would allow 'prototype' privileges to be assigned which 
would then cascade. i.e. if some one has VIEW privilege on the prototype 
group they have VIEW privilege for any* group at that level or under any 
child stem. Privileges would only be assigned once and Access/Naming 
interface implementations would have to be coded to use these 'prototype' 
objects.

*Well there could be some other rule e.g. 'of type', or 'with attribute'

This approach works with what is currently available, however, if it were 
deemed an appropriate type of approach, it could be better integrated into 
Grouper.

Thoughts?

Gary




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