paging does not work correct with groups and stems

________________________________________
From: Colin Hudler
Sent: Friday, April 30, 2010 2:51 PM
To: grouper-dev
Subject: [grouper-dev] Problem Paging A Stem Containing Child Groups (start parameter)

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!