Bug 582179 - Disambiguated parents not refreshed when size of the search results page changes
Summary: Disambiguated parents not refreshed when size of the search results page changes
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 3.0.0
Hardware: All
OS: All
low vote
Target Milestone: ---
: ---
Assignee: Charles Crouch
QA Contact: Mike Foley
Depends On:
Blocks: jon3
TreeView+ depends on / blocked
Reported: 2010-04-14 10:57 UTC by Lukas Krejci
Modified: 2015-02-01 23:26 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2013-12-10 14:13:10 UTC

Attachments (Terms of Use)
Odd page, size 15 (94.60 KB, image/png)
2010-04-14 11:00 UTC, Lukas Krejci
no flags Details
Even page, size 15 (93.94 KB, image/png)
2010-04-14 11:01 UTC, Lukas Krejci
no flags Details
Page, size 30 (158.24 KB, image/png)
2010-04-14 11:02 UTC, Lukas Krejci
no flags Details

Description Lukas Krejci 2010-04-14 10:57:42 UTC
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:


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 11:00:22 UTC
Created attachment 406469 [details]
Odd page, size 15

Comment 2 Lukas Krejci 2010-04-14 11:01:28 UTC
Created attachment 406470 [details]
Even page, size 15

Comment 3 Lukas Krejci 2010-04-14 11:02:38 UTC
Created attachment 406472 [details]
Page, size 30

Comment 7 Heiko W. Rupp 2013-12-07 15:21:53 UTC
I think this has been fixed meanwhile?

Comment 8 Lukas Krejci 2013-12-10 14:13:10 UTC
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.

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