Hi,

I can't reproduce this. For me, graphs update according to my choice. Be it in a list or the detail view of an object.

instead of the default "1 day"

The default is "1 Hour". Is this is an error or is this really your default?

tested with previous versions

There were several JS changes in recent updates of this module. Have you made sure to not get outdated/cached JS anytime you switched a version? Perform a hard-reload to ensure this (Ctrl+R, Ctrl+F5, ...) after a version change and report back please.

Hello.

The defaults we use are 1 day, but setting it to 1 hour still occurs. I've recorded a video of it happening, since I might not have explained well how to trigger it, with the following module configuration (in this case it should be the same as the default, but please confirm):

Here's the video:
https://user-images.githubusercontent.com/13053489/216336887-97f300bf-3a71-4997-a154-53d72b6bd673.mp4

Notice that at first, all is OK. Then I select a different range, wait about 10 seconds, graph image disappears. Then select some more ranges, graph reappears only to disappear after 10 seconds. At some point (mouse disappears), is when I go trigger a refresh (ended up pressing F5...), graph reappears and image stays (refreshes correctly). Then change the range again, trigger the issue after more 10 seconds.

Can't be a cache issue, since we have this happen in multiple installations, including a freshly installed one that never had other icinga versions, happens in multiple client machines, both in firefox and chrome (didn't test other browsers, but not relevant I think). Also, reverting to icingaweb2 2.11.2 (via yum downgrade) the issue consistently stops occurring,

As for the servers, should it be relevant (I thought it wouldn't be but...) I can give some examples where I consistently reproduced this:

• centos 7 with icinga repository rpm packages, for icingaweb2 and icinga; apache server (all using distribution and icinga repo rpm packages); the graphite module was placed in /usr/share/icingaweb2/modules by cloning the repository there, naming the directory as /usr/share/icingaweb2/modules/graphite and switching to the v1.2.1 branch before activating the module; all rpm packages are updated
• another centos 7 server similar to the above, but the graphite module was downloaded as a ZIP from the github releases pages and placed as /usr/share/icingaweb2/modules
• a rocky linux 9 with self made icinga/icingaweb2 rpm packages for internal use (all on latest versions, no special modifications); graphite module installed from zip file, same as above, latest release

The defaults we use are 1 day, but setting it to 1 hour still occurs.

Aye, wasn't aware anymore that this is configurable.

I've recorded a video of it happening

Thanks. Though, I did exactly the same and hadn't an issue.

Because of that I can't help you directly, I'm afraid.

Try to pin down the issue yourself, a few hints:

• Open the browsers console (hit F12) and look for repeated messages related to graphite. If there are any, show them here
• Check the network log (again, hit F12) and look for errors loading images

Good morning.

Nothing appears on the javascript console, there are no errors on network tab either. Maybe there's some icingaweb2 debug setting I could enable on my side that could help? (I see a this.icinga.logger.debug method called in public/js/icinga/behavior/form.js so that's why I'm asking)

I'm sending my user settings in the following image, maybe is relevant since this won't happen if you have auto-refresh disabled (and as far as I know, it's enabled by default) or the refresh speed isn't the default - this is important for the issue to happen in about 10 (to 15?) seconds:

Other way I've been able to reproduce: you don't even need to change the value on the form, it's enough to click on a select box and leave it that way until the page auto-refreshes for the graph to disappear: as long as one of the elements of the form has the focus, the issue is triggered. Maybe when you're trying, for some reason there is some other element on your browser that takes away the focus (maybe some other extension you have?), because here - tested in firefox and chrome (linux, windows) and edge (windows) - the select box of the form always keeps the focus, and that 100% triggers the issue in every of our instances for us, which I'd say it makes sense if you look at the code I mentioned above at:

Note: we didn't test this in master version of icingaweb2, do you think that could be relevant we try that instead? It always happens with the official packages for 2.11.3 and 2.11.4, and not for 2.11.2 and below...

Reproduced it now. I have another module active that interferes in a way that prevents this issue. Though, it definitely needs a fix in Icinga Web.

Hello together
I ran into the same issue on my productive environment. Is there a roadmap when this bug will bi fixed?

@nilmerg Do I understand correctly that the issue will be resolved in the upcoming version of Icinga Web?

Maybe. It's not planned yet.

Having the same issues here, pretty annoying, a fix would be fantastic! :)

Just add in ../TimeRangePicker/CommonForm.php -> function createSelect() ->

$element -> setAttrib('onchange','$(".timerangepicker-container").load(window.location.href + " .timerangepicker-container")');

This will only reload the div and the Graph will no longer disappear.

Just add in ../TimeRangePicker/CommonForm.php -> function createSelect() ->

element−>setAttrib(′onchange′,′(".timerangepicker-container").load(window.location.href + " .timerangepicker-container")');

This will only reload the div and the Graph will no longer disappear.

Thanks, dunno if it's correct but atleast it fixes it here, clean patch:

--- graphite/application/forms/TimeRangePicker/CommonForm.php      2023-09-21 14:41:07.000000000 +0300
+++ graphite/application/forms/TimeRangePicker/CommonForm.php   2024-02-05 09:22:30.733709599 +0200
@@ -134,6 +134,8 @@
             'Zend_Form_Decorator_ViewHelper'    => $decorators['Zend_Form_Decorator_ViewHelper']
         ]);

+        $element->setAttrib('onchange','$(".timerangepicker-container").load(window.location.href + " .timerangepicker-container")');
+
         return $element;
     }

Open for a year already, can paying customer plead for official fix?

or a year already, can paying customer

Actually the same as in my post ;o)