Grouper Developers Forum

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

As per blair`s request I`ll detail the API calls made by the UI, and also 
ask some questions.

By way of background, when browsing (apart from `All Groups`) the UI tries 
to only show stems which lead to groups relevant to the current context

--On 06 July 2007 12:45 -0400 Shilen Patel 
<>
 wrote:

> Hi all,
>
> It was great to meet everyone.  I just want to mention some of the issues
> we discussed in our meeting last week, so that they're documented here.
>
> We have two main types of groups in Grouper.
>
> 1.  Dynamic Groups - These are groups determined by an LDAP filter.
> 2.  Class Roster Groups - We have 3 groups per class (instructors,
> students, and TAs).
> There is also a TAAdmins group that has an admin privilege to all of the
> TA groups.
>
> The issues we raised are the following.
>
> 1.  Navigating through the stems viewable in the "My Memberships" section
> in the UI takes about 2-3 seconds per page.
This seems slow. how many groups are average individuals a member of?

API
---
Member.getGroups()
 Foreach group returned
   Group.getName()
   Group.getParentStem().getName()

I make a Map of all the stem names (including all their parts) so that I 
can check if stems at the current browsing location lead to `relevant` 
groups.

At one point I cached the results of doing this, however, a user would then 
have to logout and login to see the results of changes.

> 2.  If you are a member of the TAAdmins group, the "Manage Groups"
> section takes about 10 minutes to load.

API
---
groups.addAll(member.hasAdmin());
groups.addAll(member.hasUpdate());
groups.addAll(member.hasStem());    //returns stems
groups.addAll(member.hasCreate());  //returns stems

Each group/stem is treated as in `1`.

For my purposes API calls such as:

boolean subjectHasDescendantAdminOrUpdatePriv(Subject subj,Stem stem)

and

boolean subjectHasDescendantCreateOrStemPriv(Subject subj,Stem stem)

Would ease the burden on the UI. In principle the API could have such 
calls, however, the privilege model is intended to be pluggable and it 
would not be so straightforward for an external plugin to optimise such an 
approach.


> 3.  If you're not a member of the TAAdmins group and have no memberships
> and no privileges, the "Manage Groups" section still takes about 30
> seconds to load.
That seems very odd. I would expect the member.hasXXXX methods to return 
very quickly if they had nothing to return. Grouper flattens all these 
relationships in order to make such lookups quick.

> 4.  Performing a group search takes about 20-30 seconds even if no
> results are returned.
That is less surprising. Given the number of groups you have any search is 
likely to return a large number of results - however, depending on the 
context the UI will then try to filter* the list - which may result in no 
results.

*By checking if the current Subject has a specific privilege, or one of a 
set of privileges.

I think the API is doing a %term% type match which may not be efficient 
against a large database

If you do a search which cannot possibly return a result e.g. ZZZZZZZ, how 
long does that take?

> 5.  Listing group members also takes a long time.  If a group has X
> members and you want to see the first Y members, listing the group
> members causes at least X database queries and 2Y LDAP queries.
A subject may be a member of a group by several indirect paths. The 
Group.getMemberships methods may, therefore, return a subject several times 
at different points in the result list. The UI processes the whole list in 
order to determine a unique list of subjects.

Tom will have a better idea of what is happening at the LDAP level

> 6.  Adding a member to the TAAdmins group takes hours.
That is an API issue due to the number of effective list entries generated

> 7.  The xml-import takes about 3-4 days for us and requires 4 GB of
> memory allocated to the Java process.
> 8.  The only way to restrict FERPA protected data is to prevent users
> from having read access to specific groups and stems that may have FERPA
> protected data.  It would be nice if Grouper had a way of honoring FERPA
> protected data in a way such that if a user has a FERPA flag set in LDAP,
> people viewing members of the group would see something like "Anonymous
> User" instead of the user's name.
Does this apply to everyone or ought some privileged users have access to 
the data?

I`m sure we could come up with something but I would like to understand the 
use case better before proposing a solution.
> Thanks,
>
> -- Shilen
>
>
>
> Celeste Copeland wrote:
> > Hello, all.
> >
> > I met many of you at CAMP last week, and as per your recommendation, I
> > got on this mailing list.  It was a pleasure to meet everyone who
> > participated in the Grouper discussions during CAMP.  The IdM
> > technical group at Duke looks forward to working with you and
> > participating in conference calls in the near future.
> >
> > - Celeste



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