Bug 634648
Summary: | Advanced Settings for Metric Display Range do not work | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Larry O'Leary <loleary> | ||||||
Component: | Core UI | Assignee: | Lukas Krejci <lkrejci> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | urgent | ||||||||
Version: | 3.0.0 | CC: | dlackey, hrupp, lkrejci, mazz, sdharane | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 4.2 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: |
Server:
JON 2.4.0.GA - fresh install
Client:
Windows XP SP3, IE 7.0.5730.13
Windows XP SP2, IE 8
Fedora 11, Firefox 3.5.9
Fedora 13, Firefox 3.6
|
|||||||
Last Closed: | 2013-08-31 10:46:13 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: | 734807 | ||||||||
Attachments: |
|
Description
Larry O'Leary
2010-09-16 15:51:32 UTC
I tried with Safari 5.2 on rev 10860 and it worked there (a GA_QA release) and then on 10927 , the GA release where the interval picker fails. It looks like org.rhq.enterprise.gui.common.metric.AdvancedMetricSettingsUIBean#execute is not called when clickin on 'ok' . The reason for this is the validation in advanced-metrics.js:validateFields, which calls form.submit() at the end and not the execute() method of the bean. Commenting out line 78 document.advancedMetricsValuesForm.submit(); seems to fix this. in GWT we have a new component to set this metric display range. Created attachment 501055 [details]
IE7 popup page error
Tested on rhq-server-4.1.0-SNAPSHOT build# e89bbe0 Test result on Firefox v3.6.17 ------------------------------ First time when I changed the advanced setting for the number of hours it did not seem to take effect. I went back in to the advanced settings again and changed it and second time it took effect. From there on I had no issues. I then tried the date range. Again, there was no effect the first time I changed. However, second time, when made the changes, it reflected correctly. Test result on IE7 ------------------ Firstly, the URL redirection to coregui did not happen. i.e., http://<JoN_Server_IP>:Port did not redirect to http://<JoN_Server_IP>:Port/coregui After I added the coregui to the url, it gave me the login window. For testing this bug, when I clicked on the "Advanced Settings" I did not get a pop up but got an error on page message. I'm attaching the screen shot. Moving this bug to ON_DEV. This used to work - I had even tested that changing the range in the GWT component also showed up in the JSP component and vice versa! something must have changed since my last checkin to that GWT component. Currently looks broken in both worlds Created attachment 526438 [details]
Exception in GWT ui when trying to set a time range in advanced mode
This can't store preferences exception only rarely shows
We have just agreed on the call to make things easier (for development), especially as the Struts UI is going away in the future: - Remove the range controls from the metric graphs pages - fix range controls on GWT page - document that users will need to go to monitoring->tables to change the metric display range and then back to graphs to see graphs with modified display ranges. Really? Wow! But this is just temporary, right? Seems like from a usability stand point that a graph with a fixed range of "2000-01-01 @ 00:00:00 to 2000-12-31 @ 23:59:59" when it is 2011 would be bad if there was no obvious connection between what I am seeing on the graph and how I can change the range. What you are saying is that I would read the documentation to see that I need to go to some table thingy to control what I see in a picture? (In reply to comment #10) > Really? Wow! But this is just temporary, right? Well, the current monitoring graphs are temporary from the actual PoV, as they will go away (and will be replaced by a GWT version) > > Seems like from a usability stand point that a graph with a fixed range of > "2000-01-01 @ 00:00:00 to 2000-12-31 @ 23:59:59" when it is 2011 would be bad > if there was no obvious connection between what I am seeing on the graph and > how I can change the range. What you are saying is that I would read the This is a good point - the graphs page should have a note that to change the range, users should use the "tables" page. Most of the time, users are interested in the "last X" display anyway. I am assuming this, as we did not get (any?) feedback about the broken settings on the advanced page. The solution I'll commit later on today just replaces the JSF based range picker with the GWT one on the Monitoring->Graphs and Monitoring->Calltime subtabs. I.e. there will be no functional regression.. commit 28340ed95e6822674a1df6db4456eef4e66242b9 Author: Lukas Krejci <lkrejci> Date: Thu Oct 6 18:27:35 2011 +0200 BZ 743632, BZ 634648 634648 - Removed the JSF-based metric time range picker and replaced it with the GWT based one even on the JSF pages (compositing the page from a JSF iframe and the GWT picker). 743632 - Made the group tables view refreshable. Only the metrics table is being refreshed so that the list of members isn't reloaded when merely updating the metric time range. Added the "Refresh" buttons to both the metric table and the member table for the page to be inline with the resource-specific counterpart that does show them, too. verified 10/6/2011 Fixed and verified long time ago, so closing. |