Bug 804303 - Graphs view does not consistently retain selected graphs or new views
Graphs view does not consistently retain selected graphs or new views
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.2
All All
urgent Severity high (vote)
: ---
: RHQ 4.4.0
Assigned To: Larry O'Leary
Mike Foley
:
Depends On:
Blocks: jon310-sprint11/rhq44-sprint11
  Show dependency treegraph
 
Reported: 2012-03-17 12:07 EDT by Larry O'Leary
Modified: 2013-03-14 11:06 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-14 11:06:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 82443 None None None Never

  None (edit)
Description Larry O'Leary 2012-03-17 12:07:42 EDT
Description of problem:
When customizing the default view on a resource's Monitoring > Graphs tab it reverts back to the original default after navigating away from the graphs view. This also affects the creation of a new graphs view.

Some examples:

  * Add the "Transactions Rolledbacks per Minute" graph to a JBoss AS resource graphs view, navigate away, and then come back and most of the time, it will get removed from the view.
  * Create a new view named My New View. Navigate away, and come back, it will be gone.

Version-Release number of selected component (if applicable):
JON 3.0 / RHQ 4.2

How reproducible:
Most of the time


Steps to Reproduce:
1.  Start JON system
2.  Import platform, agent, and server into inventory
3.  Navigate to the RHQ Server resource
4.  Select it's *Monitoring >> Graphs* tab
5.  From *Action* drop-down, select *Create New View*
6.  For *View* enter a name for the view such as `My New View`
7.  Click the *OK* button 
8.  Confirm *Action* drop-down contains *Go to View:* *Default* and *My New View*
9.  From navigation tree, select *Alert Subsystem*
10.  Navigate back to the RHQ Server resource
11.  Select it's *Monitoring >> Graphs* tab
12.  Confirm *Action* drop-down contains *Go to View:* *Default* and *My New View*
13.  Select the *Default* view
14.  Right click on the RHQ Server resource and select *Measurements -> Transactions Rolledbacks per Minute -> Add Graph to Monitor View*
15.  Confirm the *Transactions Rolledback per Minute* graph appears at the bottom of the graph view
16.  From navigation tree, select *Alert Subsystem*
17.  Navigate back to the RHQ Server resource
18.  Select it's *Monitoring >> Graphs* tab
19.  Confirm the *Transactions Rolledback per Minute* graph appears at the bottom of the graph view
  
Actual results:
My New View disappears and the graph for Transactions Rolledbacks per Minute is removed from the Default View

Expected results:
My New View should remain after navigating away and between UI sessions.
Transactions Rolledbacks per Minute should remain on the Default View after navigating away and between UI sessions.

Additional info:
There doesn't seem to be anything written to the server log indicating any kind of failure occurred. Also, the behavior is not consistent. I was sometimes able to add two or three graphs to the Default View. However, when I added another one that failed (disappeared) the Default View was returned to its default and even the successfully added metric graphs went away.
Comment 1 Larry O'Leary 2012-03-19 11:47:12 EDT
Please note that this issue occurs most of the time. On rare occasions it works as expected. However, the next time it fails, all prior configuration is lost. This has a very huge impact to usability.
Comment 3 Charles Crouch 2012-03-20 12:03:11 EDT
Lets do some initial investigation into whats going on here, prior to committing to a fix/workaround/doco etc.
Comment 5 Lukas Krejci 2012-03-29 12:15:55 EDT
After much pondering on this and staring in disbelief on what was happening I finally found out:

On any change of a view, the GWT user interface saves the user preferences. But because it saves the preferences it "sees", it doesn't take into account the fact that the preferences might have been changed by a inlined JSF page. I.e. you show a monitoring page, create a new graph view. This saves the prefs. Then you navigate to another resource, which changes the GWT view and thus saves the prefs as GWT last saw them. Once you go back to your original resource, the graph view you created no longer exists because it has been overwritten.
Comment 6 Lukas Krejci 2012-03-29 12:20:50 EDT
master http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=f125951729ef398cfb32a1365ef059e39273b467
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Thu Mar 29 18:19:01 2012 +0200

    [BZ 804303] - Instead of saving the whole set of preferences when changing
    the view in the GWT UI, just persist only the prefs that have actually
    changed in GWT.
Comment 7 Lukas Krejci 2012-03-29 12:21:42 EDT
Simeon, could you please review the above commit and comment on the change I made to the LDAP login?
Comment 8 Simeon Pinder 2012-03-29 23:25:29 EDT
The changes look good from the LDAP login side.  

We kind of have to do this approach because we still allow preference changes from both UI systems.  Is seems like we need some sort of Configuration.merge mechanism .  However the update preference map seems pretty solid. The only question I have is does this mean that every method that is updating preferences in the UI now have to keep track of all of their modified fields to generate an appropriate changeset map or is this automatically handled?  It seems like you've modified the Login usages, but is the Dashboard preference mechanism affected by these changes also?  Other than that if you've tested that the GWT and JSF integration changes are being properly persisted then this seems fine.
Comment 9 Lukas Krejci 2012-04-02 09:36:31 EDT
master http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=0a1e7be5fe4aa4776a55f257192cb31a43f89513
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Mon Apr 2 15:33:44 2012 +0200

    [BZ 804303] - Make sure to hang on to the changed config that we need to
    persist.
Comment 10 Lukas Krejci 2012-04-02 09:43:18 EDT
To answer Simeon's questions: The LDAP call to save the prefs is somewhat special, because it both needs to update the subject AND the prefs at the same time.
Other code in GWT GUI uses the UserPreferences interface to CRUD the user preferences, which takes care of tracking of the changed properties automagically.
Comment 12 bkramer 2012-05-14 04:12:43 EDT
Changing status to VERIFIED as the issue explained in this bugzilla is resolved. 
Please note that this will allow user only to create a default view with a new name but no additional metric graphs would be added to the newly created view due to the new bug 821100 [1].


[1] https://bugzilla.redhat.com/show_bug.cgi?id=821100
Comment 13 Charles Crouch 2012-05-21 17:39:30 EDT
Setting Target Release correctly.

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