Grouper Developers Forum

[Colin Hudler <>]

Greetings,

In the standard grouper user interface (1.5.2), when a stem contains 
many groups (more than the page size), clicking next does not advance 
the page.  Instead, it loads the same first page of groups.  It was soon 
discovered that manually setting the "start" parameter to a much higher 
value, like

https://grouper/browseStemsAll.do?start=200&currentNode=3e59f943-4d04-4a90-b102-d9218b8295d4&pageSize=10

Actually did take the user to the next page.  I went looking, and I 
found a likely source of the problem.  Please advise if you prefer some 
other troubleshooting (it is easily reproducible).  Skip to the very end 
for my conclusion.

Ultimately, the stem browsing ui calls

edu.internet2.middleware.grouper.uiAbstractRepositoryBrowser#getChildren(java.lang.String, 
int, int, java.lang.StringBuffer, boolean, boolean)

defined as

  public Set getChildren(String node,String listField,int start,int 
pageSize,
      StringBuffer totalCount,boolean isFlat,boolean isForAssignment,
      String omitForAssignment,String context,HttpServletRequest 
request) throws Exception{

There's a bunch of logic, which in this case comes down to

        List<GroupAsMap> listOfMaps = getChildrenAsMaps(s, stemName,
          (start/pageSize)+1, pageSize, resultSizeArray);

Note that it takes the "start" and divides it by page size to get the 
current page.

getChildrenAsMaps() calls another getChildren with a different arity in 
the same file.  It is defined as

  public List<GroupOrStem> getChildren(GrouperSession s, String stemId,
      int start, int pageSize, int[] resultSize) throws 
StemNotFoundException{

Here it finally starts to get the children, and uses paging in a 
conditional block:

    QueryOptions queryOptions = null;
    if (this.pagedQuery()) {
      QueryPaging queryPaging = null;
      queryPaging = new QueryPaging();
      queryPaging.setPageSize(pageSize);
      queryPaging.setFirstIndexOnPage(start);
      queryOptions = new QueryOptions().paging(queryPaging);
      queryOptions.retrieveCount(true);
    }
    children=getChildGroups(stem, queryOptions);
    if (GrouperUtil.length(resultSize) >= 1) {
      if (this.pagedQuery()) {
        resultSize[0] = queryOptions.getCount().intValue();
      }
    }

It is calling "queryPaging.setFirstIndexOnPage(start);" with the start 
parameter converted already by the other getChildren().  Let's take a 
look at what 
edu.internet2.middleware.grouper.internal.dao.QueryPaging#setFirstIndexOnPage 
does with it:

    this.pageNumber = (startIndex / pageSize) + 1;

HMMM, looks like it will always be "1" unless our "start" parameter is 
one extra pageSize magnitude larger.  I hope you enjoyed this journey, 
and I hope the problem is clear.

It appears that the start parameter should not be converted into a page 
number by getChildren.  I haven't bothered to examine the consequences 
of changing 
edu.internet2.middleware.grouper.uiAbstractRepositoryBrowser#getChildren

Let me know if I can clarify further, or it is completely wrong direction!