[ZBX-9993] "stime" parameter value in graph url may get strange values Created: 2015 Oct 25 Updated: 2019 Dec 10 |
|
Status: | Open |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Frontend (F) |
Affects Version/s: | 2.0.15, 2.2.10, 2.4.6, 3.0.0alpha4 |
Fix Version/s: | None |
Type: | Incident report | Priority: | Trivial |
Reporter: | Oleksii Zagorskyi | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 1 |
Labels: | graphs, timeperiodselection, url | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
Open a graph, check an URL for generated png and for "stime" parameter notice correct value like 20151025140523. The same happens if you drag and drop a slider on right to the arrow or when try to expand the slider to right on the arrow. Another way to reproduce: one a graph, click All to expand the slider to full available period, refresh the page, click left arrow or expand time slider on left. Looks like it doesn't affect the png graph rendering in any bad way, but that still not very good as it may mislead zabbix users, which just has happened with me. When try to display different graph periods, difference between good and bad values is a bit "similar", for example: 19998990001 19999000001 19998990000 Reproduced on all versions listed in Affects Version/s, using Chrome and Opera under Linux. |
Comments |
Comment by Oleksii Zagorskyi [ 2015 Nov 09 ] |
This issue has been mentioned in Here is similar and part related to current issue: UPDATE profiles SET value_str='20161106161804', type=3 WHERE userid=1 AND idx='web.auditlogs.timeline.stime' Note the same stime word used in idx and time stamp from far future 20161106161804. |
Comment by Oleksii Zagorskyi [ 2016 Jan 29 ] |
a backward link - |
Comment by Aleksandrs Saveljevs [ 2016 Jan 29 ] |
Observed a similar issue yesterday in screens. Suppose we have a screen with the time slider at "Now". Hovering over a graph shows "stime" of "20170128095907" (one year into the future). If we move the slider back a bit, allow the screen to reload, and then move the slider back to "Now", then "stime" will be two years in the future: "20180128100047". We have discussed this with sasha and he acknowledged that this is a hack we currently have for the slider. The idea for the hack is that if the slider is currently at "Now", then when a user comes back after a month, for example, such an "stime" of far in the future would cause the slider to still be at "Now". Admittedly, this is a hack, but this is what we currently have. A more proper approach might be to simply default to "Now" when there is no "stime" and also start counting "period" not from "stime" forward, but from "stime" (or other parameter) backward. |