mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 23:15:57 +03:00
[GH-ISSUE #1293] Agent assigned Automation Policy - patch policy not used. #2746
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#2746
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 @af7567 on GitHub (Sep 23, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1293
Server Info (please complete the following information):
Installation Method:
Agent Info (please complete the following information):
Describe the bug
When an automation policy which includes a patch policy is applied to an agent by right click > Assign Automation Policy the patch policy is not used. Instead the Client or Site patch policy is used.
In the agent edit screen the correct automation policies are shown, but the effective patch policy used is the one from the site/client.
Each agent can have its own "patches" settings applied which can be used as a workaround, but I expected the patch policy from the automation policy to be used. It's also a lot easier to assign an automation policy to a few agents than to edit the patches section in each :)
@silversword411 commented on GitHub (Sep 23, 2022):
How are you determining that it's the Client/Site policy, and not the Agent policy that's being applied?
@af7567 commented on GitHub (Sep 23, 2022):
The Agent policy patch policy has a different installation time to the Client policy but patches had not been getting installed at that time. So I checked by right clicking the agent > Edit and looked in the Automation Policies - Effective Patch Policy section and can see the time shown there is the one from the Client policy.
The Agent policy above is shown correctly, only the effecive patch policy is wrong.
@af7567 commented on GitHub (Sep 23, 2022):
I think the problem is here:
github.com/amidaware/tacticalrmm@5a1cbdcd3b/api/tacticalrmm/agents/models.py (L627-L634)It seems to be going through the policies in the order agent, site, client, default. But since there is no break after finding a valid policy it always continues through to the end even if a valid agent policy is found. Since I don't have any default policy set, it ends up with the client policy.
I haven't really tested that theory though :) If that is the problem wouldn't it also affect site and client policies?
@af7567 commented on GitHub (Sep 28, 2022):
I have tested adding that
breakin the loop and now updates are getting installed when I expect them to. It was also preventing the site automation patch policy from overriding the client automation patch policy for me. So I suspect anyone who has default policies set wil have them in effect rather than any patch policy set in site/client/agent.Since then, one problem I noticed is that on the frontend, the "Effective Patch Policy" displayed on the right click > edit menu still shows the client patch policy even though it is actually executing the agent patch policy (I can see it is executing at the right time from DebugLog messages I added). Is this frontend data cached or something? It should be getting the data fromNevermind, I guess I needed to restart more than just the celery service for changes to take effect on the frontend :) So now that seems OK too.agent.get_patch_policy()as far as I can tell.@wh1te909 commented on GitHub (Oct 2, 2022):
@af7567 thanks so much for debugging this, would you be able to submit a PR with the fix?