Grouper Users - Open Discussion List

[Chris Hyzer <>]

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.

>
> 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.

>
> 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>

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