Some operations in Grouper could be made possible or more efficient if more data were available in the Grouper DB.

  1. Browse a group's members and sort by name, and page results - currently in Grouper this is not possible for large groups without getting all members and resolving all subjects.  An example here is the Grouper UI and looking at members of large groups and paging through them.
  2. Search for members of a group by substring of name, sort and page results - currently you find subjects in all sources by that substring, and then filter all the results to check for members of the group.  An example here is a person finder to see people named "John" who are employees
  3. Unresolvable subjects are orphaned in Grouper and only the subjectId is known

One suggestion for addressing these use cases is to add some columns to the grouper_member table:

  • sort_string0 - keep a string for how this data is sorted
  • sort_string4 - keep multiple strings for how this data is sorted (up to 5?) [note, until the subject API is changed to take advantage of this, its not really all that useful)
  • search_string_lower - all strings which cause results to be returned for this row
  • name - to have information for unresolvable subjects
  • description - to have information for unresolvable subjects

These could be used as follows:

  1. As new subjects are added, populate the fields
  2. When subjects are resolved, if the subject data is different than the DB data, then populate the fields
  3. Have a cron which cycles through the members and resolves them.  JDBC sources could be very efficient for this
  4. Can have an interface (spml?) where subjects can be updated based on changes in the source system
  • No labels

3 Comments

  1. isgwb@bris.ac.uk

    It is worth exploring the idea of multiple sort strings further. We have never limited Grouper to the idea of only having people as subjects - indeed groups are subjects. What does it mean to sort groups by surname? On the other hand the admin UI lets you filter members by source and so could offer source specific sorting - assuming some metadata is available to provide a user-friendly name which maps to a particular sort string index. When showing subjects from multiple sources we could offer sorting by any of the user-friendly names for the sources providing subjects - which would have to be unique or steps taken to ensure they map to the same sort string index - however, subjects from other sources might sort strangely.

    I think the next step would be to flesh out what the subject api changes would look like and think through how we handle sources which don't use the  5 (or however many) sort string indexes available.  

  2. Rob Hebron

    Use case 4 (an interface to receive changes from external systems) would be welcome, meaning keeping the data up-to-date would be less of an issue. I'd propose to extend the ESB interface to support it. People could have a choice between batch updates, event driven updates or a mixture of the two.

  3. Jim Fox (washington.edu)

    1. The member table also needs the subject source id.
    2. I think we need columns for searches also 
         sort_string_1
   sort_string_2
   ...
   search_string_1
   search_string_2
   ...
      so one could search for members who are in a branch campus, for example.
    3. Extend the Source class with? 
           String getSortAttribute(int n);
     String getSearchAttribute(int n);
      so you could update the member table with something like 
           sort_string_1 = subject.getAttributeValue(subject.getSource().getSortAttribute(1));
      might want a display name for the GUI 
           String getSortName(int n);
     String getSearchName(int n);
    4. I don't see a need for the name and description columns, as the
      sort and search columns ought to give plenty enough informaton
      to identify an orphaned member.
    5. SPML may have many uses in the future, but here it is overkill.
      Grouper has immediate and easy access to subject data. All that's
      needed is to be able to indicate that a subject needs checking, e.g., 
      void SubjectHelper.updateMemberInformation(Subject subject);
      and the web APIs could expose a similar interface.