Bug 703279 - Cumin does not return to beginning of page list when a search filter is applied
Summary: Cumin does not return to beginning of page list when a search filter is applied
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: cumin
Version: 2.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: 2.0.1
: ---
Assignee: Chad Roberts
QA Contact: Jan Sarenik
URL:
Whiteboard:
Depends On:
Blocks: 723887
TreeView+ depends on / blocked
 
Reported: 2011-05-09 20:08 UTC by Trevor McKay
Modified: 2011-09-07 16:42 UTC (History)
2 users (show)

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.
Clone Of:
Environment:
Last Closed: 2011-09-07 16:42:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1249 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Grid 2.0 security, bug fix and enhancement update 2011-09-07 16:40:45 UTC

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


Note You need to log in before you can comment on or make changes to this bug.