Bug 804303
Summary: | Graphs view does not consistently retain selected graphs or new views | ||
---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Larry O'Leary <loleary> |
Component: | Core UI | Assignee: | Larry O'Leary <loleary> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
Severity: | high | Docs Contact: | |
Priority: | urgent | ||
Version: | 4.2 | CC: | bkramer, hrupp, lkrejci, spinder |
Target Milestone: | --- | ||
Target Release: | RHQ 4.4.0 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-03-14 15:06:40 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: | 782579 |
Description
Larry O'Leary
2012-03-17 16:07:42 UTC
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. |