Object Hierarchy Constraints in NetBox Permissions #15426
-
In NetBox, the ability to set permission constraints is crucial for maintaining access control within the platform. However, there seems to be a limitation when it comes to addressing related objects within these constraints. Specifically, while it's possible to define permissions based on attributes of the object, such as Device tags ( Consider the scenario where granting a user permission to edit a Device should inherently grant access to all Interfaces assigned to that device.
This limitation hinders the effective management of permissions within NetBox, as it restricts the granularity of access control that can be applied. Therefore, I'm reaching out to the community for insights and examples on how to overcome this limitation and implement object hierarchy constraints effectively. Have you encountered similar challenges in managing permissions within NetBox? Do you have any examples or suggestions for achieving hierarchical permissions, particularly when dealing with related objects like interfaces? Let's collaborate and share our experiences to enhance the access control capabilities of NetBox. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Can you clarify exactly what you're trying to do? On dcim.Interface, it seems you are saying that constraint
|
Beta Was this translation helpful? Give feedback.
Can you clarify exactly what you're trying to do?
On dcim.Interface, it seems you are saying that constraint
"device__tags__name"
works but"device__tag__name"
doesn't work. Isn't that expected?device
has an attributetags
but nottag
.