mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 06:55:52 +03:00
[GH-ISSUE #1174] Issues with "Reboot Later" #725
Labels
No labels
In Process
bug
bug
dev-triage
documentation
duplicate
enhancement
fixed
good first issue
help wanted
integration
invalid
pull-request
question
requires agent update
security
ui tweak
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tacticalrmm#725
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @azulskyknight on GitHub (Jun 15, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1174
Originally assigned to: @sadnub on GitHub.
Server Info (please complete the following information):
Installation Method:
Agent Info (please complete the following information):
Describe the bug
Firefox displays a different UI tool to select the date time stamp passed for the scheduled reboot. Firefox only shows the calendar portion, no time selector is available.
If a reboot is scheduled for a time that has already passed, a 400 timeout error is returned. This may be intentional, but seems like it should be handled a little more gracefully.
During the scheduling process, if any of the elements are typed in manually the scheduling event returns a 400 invalid date error.
If on Firefox, once this corruption is revealed the only way to clear it is to refresh the browser and try again without actually typing anything in. Which limits the user to changing the date alone.
If on a Chromium browser the mangled date time can be fixed by clicking the day on the calendar intended. If a manual date is typed in, both today and that date will be selected on the calendar, and clicking the correct day will result in a working time stamp that successfully schedules.
On both browsers if the seconds value on the time is reduced to 00, it will simply vanish once a date is chosen on the calendar. Firefox doesn't display the time selector tools at all and will return an invalid date error when such a shortened timestamp is used. Chromium based browsers lose the seconds column in the time selector portion of the UI but seem to schedule properly assuming a date is selected on the calendar as a final action first.
To Reproduce
Steps to reproduce the behavior:
(See above for using the UI to "fix" things)
Expected behavior
I expect to be able to type in a proper date / time string, or select one from the UI and have it work the first time. It would also be nice if I could copy / paste the entire date time string into the reboot time box so I can rapidly schedule multiple reboots quickly.
Screenshots
Additional context
Silversword was assisting me (AzulSkyknight) in #Support on Discord, searching for myself for comments from today 6-15-2022 around 9am Arizona time will find the conversation.
@azulskyknight commented on GitHub (Jun 15, 2022):
Please note, this behavior existed on two different tacticalrmm installations, the first was Ubuntu 20.04 LTS based, and the second Debian 11. I rebuilt my server onto the Debian OS over the weekend in an effort to clear up some lingering redis issues. Redis is now quite happier! But the UI bug remains. :)
@eCloudJTuttle commented on GitHub (Jul 12, 2022):
Using chrome developer tools to inspect the patch command, the date/time being passed is invalid format.
@wh1te909 commented on GitHub (Jul 18, 2022):
I have fixed the 400 timeout error when date is in past in
e8e19fede7(this was actually causing the agent to crash LOL which is why the timeout).As for the invalid date issue, I am having a hard time reproducing it, I have tried typing the values by hand instead of using the GUI but don't get any errors. Only time I get error is if I type an invalid year. Any way to record a GIF or video of how to consistently reproduce? Thanks.
@silversword411 commented on GitHub (Jul 18, 2022):
Those are screenshots from firefox...different date picker than chrome, but I can't get it to do it either now. Maybe it's fixed?
@wh1te909 commented on GitHub (Jul 18, 2022):
Yes I tried both firefox and chrome, probably was fixed in a quasar update
@eCloudJTuttle commented on GitHub (Jul 18, 2022):
I can also confirm that the issue has gone away in chrome.
@silversword411 commented on GitHub (Jul 18, 2022):
Post if found to be a problem still
@azulskyknight commented on GitHub (Aug 2, 2022):
Issue still exists, at least in small part. (v0.14.5)
Please note the behavior is drastically improved, it's far more consistent now and typing into the date time field doesn't break the UI nearly as frequently.
There are circumstances I cannot fully duplicate with New Edge and Firefox where the time field doesn't contain seconds. The UI is passing a timestamp missing those digits, instead of as zeros. As a result, invalid timestamp and 400 error.
You can see here Firefox is still using a different picker, and because it lacks the time it cannot add the seconds to the time required to "work around" this issue.
New Edge simply doesn't give you the seconds selector when the time has no seconds too, which also results in invalid timestamps being passed.
Firefox date only selector:
New Edge Can work showing selector:
Again New Edge will at times vanish the seconds counter, but not every time. I was able to schedule a reboot at 0 seconds just a moment ago. Might be old browser cache garbage?
@wh1te909 commented on GitHub (Aug 9, 2022):
Fixed (again lol) in Release 0.14.6
@JSuenram commented on GitHub (Apr 25, 2023):
Same issue here in v0.15.7, did not test in v0.15.9...
@silversword411 commented on GitHub (Apr 25, 2023):
Maybe reboot has the same TZ logic problem as
github.com/amidaware/tacticalrmm@9f95c57a09?