Bug 589791

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 UIAssignee: Joseph Marques <jmarques>
Status: CLOSED NOTABUG QA Contact: Corey Welton <cwelton>
Severity: medium Docs Contact:
Priority: high    
Version: 1.4   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-18 13:20:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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):
version: 3.0.0-SNAPSHOT
build number: 88b808d 

How reproducible:

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
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.

Comment 8 Corey Welton 2010-05-18 13:20:09 UTC
QA Closing as NOTABUG - can reopen later if we decide to make changes as referenced in comment #7 above.