starred/tacticalrmm

Fork 0

mirror of https://github.com/amidaware/tacticalrmm.git synced 2026-04-26 15:05:57 +03:00

[GH-ISSUE #401] Feature Request: Parent/child link between policies #245

New issue

Open

opened 2026-03-02 02:14:47 +03:00 by kerem · 6 comments

kerem commented

2026-03-02 02:14:47 +03:00

Owner

Originally created by @alexandremottier on GitHub (Apr 16, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/401

Originally assigned to: @sadnub on GitHub.

Is your feature request related to a problem? Please describe.
It's possible to copy policies, but not to allow parent/child inheritance.

Describe the solution you'd like
Implementation of policy inheritance: A change to a parent policy affects all child policies. For each setting in the policies, allow to inherit from the parent or force a setting.

Describe alternatives you've considered
Currently, I delete policies when a setting no longer fits and recreate a copy of the policy I want to base it on.

Originally created by @alexandremottier on GitHub (Apr 16, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/401 Originally assigned to: @sadnub on GitHub. **Is your feature request related to a problem? Please describe.** It's possible to copy policies, but not to allow parent/child inheritance. **Describe the solution you'd like** Implementation of policy inheritance: A change to a parent policy affects all child policies. For each setting in the policies, allow to inherit from the parent or force a setting. **Describe alternatives you've considered** Currently, I delete policies when a setting no longer fits and recreate a copy of the policy I want to base it on.

kerem added the

enhancement

label

2026-03-02 02:14:47 +03:00

kerem commented

2026-03-02 02:14:48 +03:00

Author

Owner

@sadnub commented on GitHub (Apr 16, 2021):

I think the policies are in need of some rework. Some ideas I have had are only a single policy can apply to a container or agent. Inheritance could be explicitly set from within the policy as well.

Another option is being able to disable inheritance on containers and agents.

@sadnub commented on GitHub (Apr 16, 2021): I think the policies are in need of some rework. Some ideas I have had are only a single policy can apply to a container or agent. Inheritance could be explicitly set from within the policy as well. Another option is being able to disable inheritance on containers and agents.

kerem commented

2026-03-02 02:14:48 +03:00

Author

Owner

@alexandremottier commented on GitHub (Apr 16, 2021):

That is a good idea.
The goal is : I'm adding a check on the root policy, so the child policies must inherit the new check, unless the child policy is configured to force a parameter.
In the case of some customers having more options than others, a check could be added to privileged customers but not on the others.
My vision of the policy is :

Root policy : no checks, no tasks, no patches
|--> Second level policy : checks, tasks and patches according to the customer contract
|--|--> The customer's policy with special parameters if needed.

Must be different policies for servers and workstations. It's possible to add another policy between root and second level policy to match the operating system.

For example :

Root servers policy
|--> Default Windows Servers Policy
|--|--> Privileged Customers Windows Server Policy
|--|--|--> Customer's servers policy

@alexandremottier commented on GitHub (Apr 16, 2021): That is a good idea. The goal is : I'm adding a check on the root policy, so the child policies must inherit the new check, unless the child policy is configured to force a parameter. In the case of some customers having more options than others, a check could be added to privileged customers but not on the others. My vision of the policy is : Root policy : no checks, no tasks, no patches |--> Second level policy : checks, tasks and patches according to the customer contract |--|--> The customer's policy with special parameters if needed. Must be different policies for servers and workstations. It's possible to add another policy between root and second level policy to match the operating system. For example : Root servers policy |--> Default Windows Servers Policy |--|--> Privileged Customers Windows Server Policy |--|--|--> Customer's servers policy

kerem commented

2026-03-02 02:14:48 +03:00

Author

Owner

@sadnub commented on GitHub (Apr 25, 2021):

Being able to block policy inheritance at the client, site, and agent level should be in the next release!

@sadnub commented on GitHub (Apr 25, 2021): Being able to block policy inheritance at the client, site, and agent level should be in the next release!

kerem commented

2026-03-02 02:14:49 +03:00

Author

Owner

@wh1te909 commented on GitHub (Apr 27, 2021):

Released in 0.6.3

@wh1te909 commented on GitHub (Apr 27, 2021): Released in 0.6.3

kerem commented

2026-03-02 02:14:49 +03:00

Author

Owner

@alexandremottier commented on GitHub (Apr 29, 2021):

Hello @wh1te909 ,
After testing, the result does not exactly match my original idea. The update does the opposite.
For my part, I wanted to allow a legacy, like Russian dolls. In my company, we have several SLA levels for our customers, each giving access to different services. The NinjaRMM monitoring tool we currently use allows us to manage one policy per SLA level, with one policy per customer, inherited from the SLA level. On the customer policy, we then add any change requirements. But if there is a change on the SLA policy, the client policies below it must incorporate the settings that have not been changed on the client.
For example, I have a 24/7 SLA policy that 150 customers (out of 400 customers) depend on. If I change a setting on this policy (e.g. change the disk space alert from 95% to 90%), I don't want to have to go through all 150 affected customer policies to change. More importantly, I want inheritance to ensure that policies whose settings have not been changed explicitly apply the update immediately.

If I take the example of our current tool, NinjaRMM, I have a policy "SRV - NORMANDIE LOGISTIQUE (ENL)" (which concerns the servers of a client) which inherits the policy "0 SRV (Default) (noAV) (noPatch)". It can be seen that all the parameters of the client policy come from the parent policy except for the "Device has not rebooted in 90 day(s)" control.
If any other parameter changes on the parent policy, for example the CPU alert reset time, the client policy will automatically have this new setting applied.

This was the purpose of my feature request...

@alexandremottier commented on GitHub (Apr 29, 2021): Hello @wh1te909 , After testing, the result does not exactly match my original idea. The update does the opposite. For my part, I wanted to allow a legacy, like Russian dolls. In my company, we have several SLA levels for our customers, each giving access to different services. The NinjaRMM monitoring tool we currently use allows us to manage one policy per SLA level, with one policy per customer, inherited from the SLA level. On the customer policy, we then add any change requirements. But if there is a change on the SLA policy, the client policies below it must incorporate the settings that have not been changed on the client. For example, I have a 24/7 SLA policy that 150 customers (out of 400 customers) depend on. If I change a setting on this policy (e.g. change the disk space alert from 95% to 90%), I don't want to have to go through all 150 affected customer policies to change. More importantly, I want inheritance to ensure that policies whose settings have not been changed explicitly apply the update immediately. <img width="1440" alt="image" src="https://user-images.githubusercontent.com/40338703/116599128-f4c06400-a927-11eb-8d25-acb59fd3be4d.png"> If I take the example of our current tool, NinjaRMM, I have a policy "SRV - NORMANDIE LOGISTIQUE (ENL)" (which concerns the servers of a client) which inherits the policy "0 SRV (Default) (noAV) (noPatch)". It can be seen that all the parameters of the client policy come from the parent policy except for the "Device has not rebooted in 90 day(s)" control. If any other parameter changes on the parent policy, for example the CPU alert reset time, the client policy will automatically have this new setting applied. This was the purpose of my feature request...

kerem commented

2026-03-02 02:14:49 +03:00

Author

Owner

@wh1te909 commented on GitHub (Apr 30, 2021):

reopening

@wh1te909 commented on GitHub (Apr 30, 2021): reopening

kerem referenced this issue

2026-03-14 02:30:24 +03:00

[GH-ISSUE #245] Bug: Excess Python.exe Instances #2096