Grouper Developers Forum

[Chris Hyzer <>]

Then I would show it on the screen, and if there were a capability to go to 
the nth page, then I would have paging buttons :)

I don't think this is easy/possible with ldap or it would be in there :)

Thanks,
Chris

-----Original Message-----
From: Tom Barton 
[mailto:]
 
Sent: Monday, December 12, 2011 11:11 AM
To: Chris Hyzer
Cc: 

Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011

Chris,

What would you do if the fact that there are actually 5278 results was
available to the UI?

Tom

On 12/12/2011 10:05 AM, Chris Hyzer wrote:
> Let me explain again.
>
> If you search for something that returns a lot of results, lets say "th".
>
> The subject source will now return the max page size, which you configure, 
> lets say it is set to 100.  Maybe of your 4 sources, you get a combined 137 
> results.  Lets say your page size on the UI is set to 50.  The UI will say:
>
> Please narrow your search, too many results, showing a partial listing of 
> results 1-50 of 137 items.
>
> However, there are actually 5278 items that match "th"... but there is 
> nothing in the subject API to tell the API the actual number.  All the 
> API/UI knows is that there is more than 137.  Also, when you page through 
> on the UI, you will only be able to see the 137.  So it looks like to the 
> user there are 137 results, and it seems like they can page through all the 
> results.  This is misleading and wrong, so we need to remove paging buttons 
> from the UI, and if you want to have an option to keep them, feel free.
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Tom Barton
> Sent: Monday, December 12, 2011 10:21 AM
> To: 
> 
> Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>
> I agree that the UI should enable the partial result to be viewed, and
> that the user may want to alter page size for viewing the partial result
> set. It seems the rest of the concern is what text and numbers are
> displayed on screen how, to ensure that the user has the right idea. It
> sounds like Gary's got the right places and controls - is there a
> wording issue? Here's what I think Gary said is there now:
>
> Error: Too many results returned by one or more data sources -
> displaying  truncated result set. Please narrow your search
>
> Showing 1-50 of 74 items (truncated result set)
>
> That's pretty good. Maybe reword slightly?
>
> Note: Too many results were found. Please refine your search. Displaying 
> partial result set.
>
> Showing 1-50 of 74 items (partial result set)
>
> On the point about max results per subject source or max results across
> subject sources, from a user perspective I think max overall is what is
> simplest, though I know source adapters don't work that way. But I
> wonder if the distinction is largely immaterial for deployments that
> rely primarily on a single subject source (beyond GSA), and so not a top
> priority for us to deal with right away.
>
> I think that the difficulty we're having with search & display is a
> consequence of how we've structured the source and subject interfaces,
> as Gary will recognize going back a long ways. Until we find time to
> redo all that in some presumably better way (which isn't easy - we've
> tried before!), we'll have to do our best with an imperfect situation.
>
> Tom
>
> On 12/12/2011 8:51 AM, GW Brown, Information Systems and Computing wrote:
>> --On 12 December 2011 08:31 -0600 Tom Barton 
>> <>
>>  wrote:
>>
>>> Gary & Chris,
>>>
>>> From here on the sideline it seems as though something is missing from
>>> your approach to this problem. Are you working on the same underlying
>>> data set, ie, does Gary's have 74 Jo*'s and Chris' 8125 (or 8435)? Or
>>> why are you each seeing two such different numbers?
>> I'm working against the QuickStart database, but I don't think the numbers
>> are that critical. I'm sure on screen text can do away with any ambiguity.
>>
>> By default the UI pages 50 results at a time - user can change to 10, 25,
>> 50, 100. Independently, a source can be configured for a maximum number of
>> results it will return (new feature). I don't see any problem with allowing
>> a user to page up to that maximum - it is what I would expect.
>>
>> The JIRA description is:
>>
>> We need to remove paging buttons from subject search in admin ui, and if
>> there are too many members (the SubjectFinder.findPage() method will tell
>> you), then perhaps a message could be displayed that the user should narrow
>> their search, and it should also show whatever members it found (e.g. the
>> first 200 or whatever number is configured in the source).
>>
>> I agree that it is worth letting the user see however many results are
>> returned - but it would, in that example, be wrong to show all 200 in one
>> page if the UI page size is set at 50.
>>
>> If you search across all sources (the default) you could have too many
>> results from only one of the sources, but not get to see the results from
>> it.
>>
>> Gary
>>> Tom
>>>
>>> On 12/12/2011 6:45 AM, Chris Hyzer wrote:
>>>> Is the resultset truncated because it is showing 50 of 74 items, or is
>>>> it truncated because it is showing 50 of 8125 items?  When you click
>>>> "next", are you going to the next page of all results, or are you going
>>>> to the next page of a partial result set?  It is misleading and we need
>>>> it removed (though as I said, if you want it there, leave an option so
>>>> that you can enable it no problem)...  :)
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: GW Brown, Information Systems and Computing
>>>> [mailto:]
>>>>   Sent: Monday, December 12, 2011 4:01
>>>> AM
>>>> To: Chris Hyzer; Emily Eisbruch; Grouper Dev
>>>> Subject: RE: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>>>>
>>>> The changes I checked in lead to the following:
>>>>
>>>> Top of screen
>>>> -------------
>>>> Error: Too many results returned by one or more data sources -
>>>> displaying  truncated result set. Please narrow your search
>>>>
>>>> The summary
>>>> -----------
>>>> Showing 1-50 of 74 items (truncated result set)
>>>>
>>>> I would have thought that was pretty clear...
>>>>
>>>> Gary
>>>>
>>>> --On 11 December 2011 20:24 +0000 Chris Hyzer 
>>>> <>
>>>> wrote:
>>>>
>>>>> IF you do a search for "jo", and there are 8435 results, and the UI says
>>>>> "There are too many results", and it say "displaying 1-50 of 149
>>>>> results", that is misleading and incorrect.  If there are really 8435
>>>>> results, and the user sees that there are 149 results, and pages
>>>>> through, and doesn't see the one they are looking for, it is really
>>>>> bad.  There is no reason to show the paging if we don't know how many
>>>>> results there are (we got 149 results, but we don't know there are 8435
>>>>> since that is not in the subject API), and if we cant page through all
>>>>> the results.  IF you disagree, then we need an option to not show the
>>>>> paging on the screen, and it must default to not show the paging.  We
>>>>> do not want something on the UI that we know is misleading and
>>>>> incorrect, but if you want to show it at your school, you have the
>>>>> option to do that.  Ok?  :)
>>>>>
>>>>> Thanks,
>>>>> Chris
>>>>>
>>>>> -----Original Message-----
>>>>> From: GW Brown, Information Systems and Computing
>>>>> [mailto:]
>>>>>   Sent: Saturday, December 10, 2011
>>>>> 11:23 AM
>>>>> To: Chris Hyzer; Emily Eisbruch; Grouper Dev
>>>>> Subject: RE: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>>>>>
>>>>> --On 09 December 2011 22:02 +0000 Chris Hyzer 
>>>>> <>
>>>>> wrote:
>>>>>
>>>>>> Also, in addition to my previous email, I forgot to respond to your
>>>>>> email below:
>>>>>>
>>>>>>> I think Chris was saying to ignore maxResults - in which case it
>>>>>>> should be  removed from the sample sources.xml. I can then see that
>>>>>>> you can do:
>>>>>> Well, maxResults is useful if people do a SubjectFinder.findAll() as
>>>>>> opposed to SubjectFinder.findPage().  Since the UI and WS will do the
>>>>>> paging one, we can essentially ignore the masResults and focus on
>>>>>> maxPageSize, though I think it should still be in the
>>>>>> sources.example.properties in case people do the API findAll and in
>>>>>> general for belts and suspenders (if a subject source returns too many
>>>>>> results you can run out of memory on the server).
>>>>> I haven't delved into the code to se where and how you are doing the
>>>>> cutoffs, but is maxResults configured at the wrong level? i.e shouldn't
>>>>> it  relate to 'sources' rather than a specific subject source?
>>>>>
>>>>> Gary
>>>>>> Thanks,
>>>>>> Chris
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: 
>>>>>> 
>>>>>> [mailto:]
>>>>>>  On Behalf Of GW Brown,
>>>>>> Information Systems and Computing Sent: Thursday, December 08, 2011
>>>>>> 4:16 PM
>>>>>> To: Emily Eisbruch; Grouper Dev
>>>>>> Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
>>>>>>
>>>>>> --On 07 December 2011 16:07 -0500 Emily Eisbruch 
>>>>>> <>
>>>>>> wrote:
>>>>>>
>>>>>>> [AI] (Gary) will look at the issue of paging in the Admin UI
>>>>>>> https://bugs.internet2.edu/jira/browse/GRP-716
>>>>>> I've looked at this again and still don't see a *paging* issue - The UI
>>>>>> appears to correctly page based on whatever number of results are
>>>>>> returned  by the API - it doesn't care about what may have been
>>>>>> discarded.
>>>>>>
>>>>>> I did find one inconsistency in the code. The UI does subject searches
>>>>>> in two classes:
>>>>>> 1) DoSearchSubjectAction
>>>>>> 2) SearchNewMembersAction
>>>>>>
>>>>>> The former has:
>>>>>>   results=source.search(processedSearchTerm);
>>>>>> but should have:
>>>>>>
>>>>>> results=SubjectFinder.findPage(processedSearchTerm,sourceId).getResult
>>>>>> s( );
>>>>>>
>>>>>> I'm not convinced by the semantics of:
>>>>>>
>>>>>> <!-- if more than this many results are returned, then throw a too many
>>>>>> subjects exception -->
>>>>>>      <init-param>
>>>>>>        <param-name>maxResults</param-name>
>>>>>>        <param-value>1000</param-value>
>>>>>>      </init-param>
>>>>>>
>>>>>>     <!-- on a findPage() this is the most results returned -->
>>>>>>     <init-param>
>>>>>>       <param-name>maxPageSize</param-name>
>>>>>>       <param-value>40</param-value>
>>>>>>     </init-param>
>>>>>>
>>>>>> (I set maxPageSize to 40 down from 100 for testing.)
>>>>>>
>>>>>> I think Chris was saying to ignore maxResults - in which case it should
>>>>>> be  removed from the sample sources.xml. I can then see that you can
>>>>>> do:
>>>>>>
>>>>>> SearchPageResult spr = null;
>>>>>> spr = SubjectFinder.findPage(searchTerm);
>>>>>> results = spr.getResults();
>>>>>> if(spr.isTooManyResults()) {
>>>>>>   request.setAttribute("message",
>>>>>>  new Message("error.too.many.subject.results",true));
>>>>>> }
>>>>>>
>>>>>> That way the retrieved results are shown but the user is alerted to the
>>>>>> fact the result set was truncated (error message might make that
>>>>>> clearer)
>>>>>>
>>>>>> Chris: if that is what you want it is an easy enough change. If you
>>>>>> still think there is a UI paging issue you'll have to come up with a
>>>>>> screenshot...
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>> ----------------------
>>>>>> GW Brown, IT Services
>>>>>> 
>>>>> ----------------------
>>>>> GW Brown, IT Services
>>>>> 
>>>> ----------------------
>>>> GW Brown, IT Services
>>>> 
>>
>> ----------------------
>> GW Brown, IT Services
>>