Bug 703279

Summary:	Cumin does not return to beginning of page list when a search filter is applied
Product:	Red Hat Enterprise MRG	Reporter:	Trevor McKay <tmckay>
Component:	cumin	Assignee:	Chad Roberts <croberts>
Status:	CLOSED ERRATA	QA Contact:	Jan Sarenik <jsarenik>
Severity:	low	Docs Contact:
Priority:	medium
Version:	2.0	CC:	croberts, jsarenik
Target Milestone:	2.0.1
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	cumin-0.1.4840-1	Doc Type:	Bug Fix
Doc Text:	Cause: searching table data by applying a filter to the description field would often result in an "empty" results list (actually, the results would not be empty, but the user would need to click a results page number to see the results). Consequence: Filtering long lists (like submissions) by the description was very clumsy and crippled. Fix: When a new search filter is applied, we now reset the offset (param that controls which page is currently displayed) to zero. Result: Applying search filters now has the desired effect. The user is greeted with a pruned list that matches their search.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-09-07 16:42:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	723887

Description Trevor McKay 2011-05-09 20:08:46 UTC

Description of problem:

If a cumin table spans multiple pages and the list of items is constrained using the "Search" dialog box, the current page is not reset to "page 1".  This can lead to a blank display if for instance the current page is 14 and the search criteria reduces the page count to something less than 14.

In general, since the last of items has been pruned, it probably makes sense to set current page back to "1" in all cases.

How reproducible:

100%

Steps to Reproduce:
1.  Find a list of items that spans multiple pages, for instance slots or submissions.

2.  Go to the last page in the list.

3. Enter something in the search box which produces a pruned list.
  
Actual results:

Display will be blank.

Expected results:

Something should be displayed, preferably page 1 of the pruned list.

Additional info:

Comment 1 Chad Roberts 2011-05-24 16:46:52 UTC

Fix available in revision 4780.

Comment 2 Chad Roberts 2011-05-24 16:46:52 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:  searching table data by applying a filter to the description field would often result in an "empty" results list (actually, the results would not be empty, but the user would need to click a results page number to see the results).

Consequence:  Filtering long lists (like submissions) by the description was very clumsy and crippled.  

Fix:  When a new search filter is applied, we now reset the offset (param that controls which page is currently displayed) to zero.

Result:  Applying search filters now has the desired effect.  The user is greeted with a pruned list that matches their search.

Comment 4 Jan Sarenik 2011-07-22 07:54:06 UTC

Verified with cumin-0.1.4878-1.el5.

Comment 5 errata-xmlrpc 2011-09-07 16:42:43 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1249.html