Bug 582179

Summary: Disambiguated parents not refreshed when size of the search results page changes
Product: [Other] RHQ Project Reporter: Lukas Krejci <lkrejci>
Component: Core UIAssignee: Charles Crouch <ccrouch>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: low Docs Contact:
Priority: medium    
Version: 3.0.0CC: hbrock, hrupp, lkrejci
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-10 09:13:10 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 678340    
Attachments:
Description Flags
Odd page, size 15
none
Even page, size 15
none
Page, size 30 none

Description Lukas Krejci 2010-04-14 06:57:42 EDT
Description of problem:

The search results can have 15,30 or 45 rows per page. When changing that number, the parent column should be re-evaluated to check that all the resources on the new - larger - page are unique.

How reproducible:

always

Steps to Reproduce:

1. With page size 15, find an odd-numbered page followed by an even-numbered page where one of them contains just a single parent and the other more than one parent in the parent column.
2. Change the page size to 30, navigate to the "same" page (i.e. if the found odd page was n-th in the original results, navigate to the (n + 1)/2 page in the results with page size 30).
3. Notice that the parents still look the same as they did for the smaller page size even though they all should contain more than one parent now.
  
Actual results:

Half of the results on the larger page size contain more than one parent, the other half doesn't

Expected results:

All rows on the larger page size should contain more than 1 parent.
Comment 1 Lukas Krejci 2010-04-14 07:00:22 EDT
Created attachment 406469 [details]
Odd page, size 15
Comment 2 Lukas Krejci 2010-04-14 07:01:28 EDT
Created attachment 406470 [details]
Even page, size 15
Comment 3 Lukas Krejci 2010-04-14 07:02:38 EDT
Created attachment 406472 [details]
Page, size 30
Comment 7 Heiko W. Rupp 2013-12-07 10:21:53 EST
I think this has been fixed meanwhile?
Comment 8 Lukas Krejci 2013-12-10 09:13:10 EST
This is no longer applicable.

In the meantime, we changed the implementation such that the ancestry of resources is precomputed, so we no longer suffer from the complexity and general brokenness of the previous approach.

Closing as this no longer is an issue.