mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 06:55:52 +03:00
[GH-ISSUE #333] Feature Request: remove "red" status of client when snoozing an issue #2155
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#2155
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 @manc74 on GitHub (Mar 18, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/333
Originally assigned to: @sadnub on GitHub.
Currently when an alert is snoozed for a period, the red status of the host still shows, as well as it appearing at thr top of the list.
Can we have the option to stop the highlighting of an item when it's snoozed?
@sadnub commented on GitHub (Mar 19, 2021):
That's a good idea! Will work on this
@sadnub commented on GitHub (Mar 20, 2021):
I was checking into this a bit more and the snoozing of the alert actually just silences the notifications. The check/task is still continuing to run and will report the status regardless of being snoozed or not. This was by design.
You could exclude the agent from the alert template or just uncheck the alert boxes and it won't report as being down.
@manc74 commented on GitHub (Mar 20, 2021):
Yes I saw thats how it works. The current issue is that if a check looks at the event log for the last 24 hours, even when it's fixed there's no way to clear the issue unless you remove the check, this then means if the check fails again it won't trigger (and easy to forget to put the check back in place after 24 hours expires)
@dinger1986 commented on GitHub (Mar 21, 2021):
Can always change the checks to only look at 1 hour or something.
To be fair having written most of the event viewer checks I have defaulted to 24 hours but doesn't mean everyone needs to the checks can be customised.
@sadnub commented on GitHub (Mar 21, 2021):
I believe the resolve option should fix that. If the issue is still present it will open another alert thoughOn Mar 20, 2021 7:53 PM, manc74 @.***> wrote:
Yes I saw thats how it works. The current issue is that if a check looks at the event log for the last 24 hours, even when it's fixed there's no way to clear the issue unless you remove the check, this then means if the check fails again it won't trigger (and easy to forget to put the check back in place after 24 hours expires)
—You are receiving this because you were assigned.Reply to this email directly, view it on GitHub, or unsubscribe.
@sadnub commented on GitHub (Mar 21, 2021):
For this particular issue, it might make sense to adjust the check run interval to match how far the back the event log check searches. That way it won't trigger on the same event multiple times.
@dinger1986 commented on GitHub (Mar 21, 2021):
For bluescreens, viruses etc probably better to have it running regularly.
I was going to suggest that we could change the scripts to only check in the last hour or so however that would mean it would auto clear from the rmm and maybe not have been resolved.
Unless the rmm would keep it open until the issue is resolved which would need to be configurable because for example the speedtest script clears when it goes back over the threshold and that's good.
Another option would be that you snooze the issue and that automatically pauses that check for a day or whatever amount of time? So it doesn't show up red? Don't know if that's a headache though?
@sadnub commented on GitHub (Apr 16, 2021):
I added a clear check status that will be in the next release. This might be a better option than snoozing