Grouper Users - Open Discussion List

[Thomas M Goerger <>]

On Wed, 23 Jul 2008, Chris Hyzer wrote:

> Im sure someone with ldap subject source knowledge will correct me, but let 
> me take a stab:
>
> > 1. Right now, I'm using the searchSubject search on our cn attribute,
> > and this finds people fine.  I'm not sure how the 
> > searchSubjectByIdentifier
> > or search functions work however.  No matter how I change these, the
> > people search doesn't seem to change the results sent back.  What are 
> > these
> > functions used for?
>
> A subject has one id.  This is the primary thing that determines the 
> subject (in tandem with sourceId), and it's the determining thing that 
> grouper keeps in the grouper_members table.  However, a subject could have 
> multiple identifiers (other things that determine the user).  At penn a 
> person's id is the pennid, e.g. 12345678, but an identifier is their 
> pennkey (or loginid), e.g. jsmith.  So when grouper is searching by id 
> (would be more efficient), it will run searchSubject, and when it is 
> searching by identifier, it will run searchSubjectByIdentifier (more 
> inclusive, accepts pennids and pennkeys).  When you are searching from the 
> UI, it is probably using the "search" sources.xml query anyways... which 
> queries all attributes.
>
The search function that I'm seeing my install go with is the
searchSubject function.  I don't see any way to get the UI to search in
any other fashion.  Are these searches used by Grouper from somewhere
else?  Is there a way to get the UI to see these search options?

> >
> > 2.  I'm also wondering why my install is doing an ldap query each time
> > I want to list the members of a group.  When I click the manage members
> > or add members button, Grouper is hitting my ldap source to pull
> > information about these users.  Shouldn't this be hitting my backend 
> > Oracle DB
> > instead?  How would I go about doing this?
>
> Grouper doesn't duplicate user info from the "source" into the grouper 
> registry, it only stores the subjectId.  So each time a user is displayed 
> it needs to either go to the source in your case ldap), or perhaps a local 
> cache.
>
Okay, that's understandable.  Is there a way then to just have Grouper
look at only the subjectID as the description when displaying the
membership of a group?  When you're displaying something like 2000+ group
members, its a bit slow on the LDAP side, so doing something like this,
and hitting the Oracle DB would be a lot quicker.  Would Grouper recognize
SubjectID as a valid description anywhere?

> >
> > 3.  I would like to have more than one attribute show up in the
> > description for a member.  So that, if I list a group membership, I
> > could list both the person's name attribute, and their uid attribute.  Is
> > there any way to do something like this?
>
> At penn we show: Michael Christopher Hyzer (chyzer, 12345678) Pennpay, Staff
> This is so when choosing people, the more info, the higher probability the 
> user will pick the right person.  Anyways, we do this by filling the 
> subject "description" attribute with this string, but we do this from a SQL 
> source.
>
> Its this part in the sources.xml:
>
>     <init-param>
>       <param-name>Description_AttributeType</param-name>
>       <param-value>description</param-value>
>     </init-param>
>
Could you do something like displaying two param-values in this section?
I tried this, and only got the last one referenced, but perhaps someone
that knows xml better than I might know how to do this.

The other problem with this that I'm running into is that when I change
the description attribute, the members that I've already got loaded are no
longer recognized.  It seems like Grouper is hanging onto this information
somewhere, so it doesn't want to display the change.  So, if I've changed
the Description attribute from say, OfficialName to UID, and try to
display a group, I get a 'not found' message.  I can search for one of
these members using the search, and it displays correctly, but choosing
this user gives a 'not found' message again.  Seems like the group
information for this user is messed up somehow, and I'd have to reload the
database to get it to sync up again.  It doesn't seem like this should be
necessary.  Even restarting Tomcat and emptying browser cache doesn't seem
to fix this issue.  Has this been seen before?

> The string in the description attribute of the subject is the string 
> displayed.  Assuming in your media.properties (or rather a custom 
> media.properties, see the wiki about customizing the UI, or ask us) you 
> have this:
>
> # Prior to V1.2 sites could do little to control how subjects, groups or 
> stems were displayed
> # in the UI, beyond the display of stem/group search results, unless they 
> created dynamic tiles
> # It is now possible to control the display of stems, groups and subjects 
> in different contexts
> # In the case of subjects, an attribute can be configured based on the 
> subject's SourceAdapter
> # Provides backwards compatability - it was assumed that all Subjects woud 
> have a 'description' attribute
> subject.display.default=description
>
> Hopefully you can tweak those params and your ldap attributes to make it 
> display what you like.
>
> Kind regards,
> Chris
>