Skip to Content.
Sympa Menu

grouper-dev - GRP-7 approaches

Subject: Grouper Developers Forum

List archive

GRP-7 approaches


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To:
  • Subject: GRP-7 approaches
  • Date: Fri, 09 Nov 2007 17:32:51 +0000

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



  • GRP-7 approaches, GW Brown, Information Systems and Computing, 11/09/2007

Archive powered by MHonArc 2.6.16.

Top of Page