|Summary:||Pagination through multi-page resource pages appears to share state across different RHQ users|
|Product:||[Other] RHQ Project||Reporter:||John Sefler <jsefler>|
|Component:||Core UI||Assignee:||Joseph Marques <jmarques>|
|Status:||CLOSED NOTABUG||QA Contact:||Corey Welton <cwelton>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-05-18 13:20:09 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||585306, 591531|
Description John Sefler 2010-05-06 21:30:09 UTC
Description of problem: It appears that if multiple users are paginating through the browse resource pages at the same time, the most recent user to click to the "next page" sets the current page for the other user. This is very bad. Version-Release number of selected component (if applicable): RHQ version: 3.0.0-SNAPSHOT build number: 88b808d How reproducible: always Steps to Reproduce: 1. open a browser and login to an RHQ server as rhqadmin (or any other user). Lets call him "user1". 2. open a second browser (on the same machine or any other machine) and login to the same RHQ server as rhqadmin (or any other user). Lets call him "user2". 3. navigate both user1 and user2 to Resources > Services (or any other highly populated table like a platform's content) at this point both users appear to be paginated to page 1 4. have user1 click to the next page at this point user1 is on page 2 5. have user2 click to the next page BANG! although user2 started on page 1, his click to the next page went to page 3. Actual results: The next page that user2 lands on depends on where user1 last paginated to. Expected results: Each user should paginate to the next page from where their current position, not somebody else's position. Additional Info: Moreover, if user1 sorts a table column, user2 will see the same column sorted on his next page load even though user2 did not sort anything.
Comment 4 Joseph Marques 2010-05-13 20:36:17 UTC
This would be a regression because the inventory browser (replacement for ResourceHub.do) is new and users on previous versions of the application would not see this oddity with their inventory browser. The JSF-based pagination across the entire site was designed to be specific to the user. The custom table components automatically provide isolation per user, and should make this transparent to the user of any table. Given how critical proper operation of the inventory browser is, I would think this should get high/urgent priority to determine the root cause and see if there is a systemic regression against all JSF-based tables (well over 100 of them).
Comment 5 Joseph Marques 2010-05-13 20:56:26 UTC
FYI, I just tested this and can't reproduce. I log in as two **different** users and there is entirely no interaction between the search/filter, pagination, sorting of one user on the other session, and vice versa. QA, can you review the reproduction steps and add any more detail that might be missing. I want to either find the root cause of this or have a reasonable explanation why you might have seen it even thought it's not an issue now.
Comment 6 John Sefler 2010-05-14 20:53:21 UTC
False alarm... my apologies. Pagination state appears to be working as designed: Table pagination state is preserved on a per user basis regardless of how many places that user is simultaneously logged in from. My mistake occurred when trying to log into rhq from the same browser/host as two different users (a less likely scenario). What actually happened is that I logged into rhq as user1 in browser window1 and then logged into rhq as user2 in browser window2. After I paginated in window2 as user2 and then switched to window1 and paginated, user1 was replaced with user2 and I did not realize it. So now both browser window 1 and 2 where occupied by user2 without me knowing and consequently shared the pagination state. Moral of the story... RHQ only supports a single user login per browser session. Now I ask... Is this working as designed?
Comment 7 Joseph Marques 2010-05-17 22:13:14 UTC
John, yes, this is working as designed. This state data is cached at the user-level, and not at the page-level. I'm thinking that this can change in the future. If we move to scroll-tables and provide reasonable sorting defaults, we probably don't need to cache sorting/pagination info at all. This is especially for any GWT-based UI we write, because state is naturally stored client-side (a.k.a, on a page-by-page basis). Regardless of which we decide is the ideal solution, we should be consistent across our various UI pages (whether they be written in JSF or GWT) so that the user doesn't have an inconsistent experience.