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.
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.
Lets do some initial investigation into whats going on here, prior to committing to a fix/workaround/doco etc.
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.
master http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=f125951729ef398cfb32a1365ef059e39273b467 Author: Lukas Krejci <lkrejci> 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.
Simeon, could you please review the above commit and comment on the change I made to the LDAP login?
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.
master http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=0a1e7be5fe4aa4776a55f257192cb31a43f89513 Author: Lukas Krejci <lkrejci> 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.
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.
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
Setting Target Release correctly.