[Feature]: AccessList inheritance

[alehaa]

NetBox version

v4.3.5

Feature type

Change to existing model

Proposed functionality

I propose implementing inheritance for ACLs. This means that an ACL can have a parent ACL, and the rules of the parent ACL will be automatically inherited by the child ACL.

This proposal involves several model changes:

1. Adding an optional parent field to the AccessList model or using MPTT.
2. Including the rules of the parent ACL when querying the rules of a child ACL.
3. Allowing an ACL to be abstract, meaning that the assigned_object field can be optional.

Use case

When managing a large number of devices, Access Control Lists (ACLs) can become repetitive, as all access lists might include rules like allowing administrator access. This proposal aims to reduce such repetition.

External dependencies

None.

---

I volunteer to implement this proposal.

[github-actions[bot]]

Thanks for opening this Issue! We really appreciate the feedback & testing from users like you!

[alehaa]

This PR is somewhat related to #72. However, while #72 focuses on reusing a specific ACL on multiple devices, this PR focuses on abstraction, such as reusing the first 10 rules for five different ACLs.

[pheus]

Thanks for the proposal and for volunteering to implement it - much appreciated. One point to clarify: how will sequence-number collisions be handled during inheritance? For example:

parent: 10, 20, 30
child : 30, 40, 50

Would you (1) reject duplicates with a validation error (perhaps with a "renumber" helper), or (2) allow them and have the child's 30 override the parent's 30 when computing the effective list? Also, what would be the default merge order - parent-first or parent-last?

[alehaa]

Reviewing tools like Cisco’s FirePower Management Center access lists (policies) can have two sections, with the child sections being merged in between the parent ones to control correct merging. However, this would involve significant changes to the plugin and is therefore not feasible.

I believe the best option would be to implement validation to ensure that a sequence number is unique not only per ACL but also for its ancestors and descendants. This check can be implemented with low overhead in the clean() method. In this case, since the sequence number is unique, the merge order does not matter.

[pheus]

That sounds like a pragmatic solution. Thanks for explaining your approach!

Would you mind sharing your thoughts on the options in #72? See this comment.

[alehaa]

Given that the feature request https://github.com/netbox-community/netbox/issues/20116 has been declined, I’m curious to know if we can implement a basic version of this feature using MPTT, similar to how NetBox currently handles tree models. Alternatively, is this feature blocked until NetBox decides on its future approach to tree models?

[pheus]

Thanks again for digging into this, @alehaa. As you may know, I’m not a maintainer here, so this isn’t a decision - just my perspective. A minimal, opt‑in MPTT approach in the plugin seems feasible if we keep it low‑impact. My main concern is long‑term maintenance and alignment with NetBox’s direction, especially since netbox-community/netbox#20116 was declined.

I’d value your view on any pitfalls or guardrails that would keep a future migration low‑risk.

[alehaa]

Personally, I would vote for using MPTT, as this concept is widely known in the NetBox community. If NetBox core switches to a different concept, the migrations can be easily copied. Even if there were no alternative, reusing the parent field from MPTT could implement inheritance using a while loop. However, this would increase the number of database queries from 1 to N.