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 UI | Assignee: | 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 | ||
Whiteboard: | |||
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: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 585306, 591531 |
Description
John Sefler
2010-05-06 21:30:09 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). 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. 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? 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. QA Closing as NOTABUG - can reopen later if we decide to make changes as referenced in comment #7 above. |