Replies: 2 comments
-
|
Hi, @maxblome! Thanks for bringing this up. I think there may be a slight mismatch between the intended purpose of contacts and what you are trying to achieve here. Contacts in NetBox are meant to store contact information for people or organizations that are not NetBox users, such as vendors, support partners, or other external points of contact. Because of that, they are not connected to NetBox’s permission system, and there is currently no mechanism to use them for access control. In the example you described, those individuals already have NetBox accounts, so they are users rather than contacts in this context. For that use case, the recommended approach would be to assign those Users or UserGroups to an Owner of the relevant objects. I hope that helps clarify the distinction. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @pheus, thanks for the feedback. But how about the following example: There is a VM that is managed by Team A, and the database or application that runs on it is managed by Team B. Virtual machineOwner: Team A Even though Team B does not manage the VM, it is still an interested party that we would like to give access to. Or how could such a scenario be resolved? Of course, it is possible to create dedicated permissions here, but this would have to be done individually for each team/contact. As is the case with the owner, one permission is sufficient. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
With the new Owner feature, you can create nice permissions so that everyone can see the objects where they are the owner.
Example:
{ "owner__user_groups__user": "$user" }It would be great if this could also work with contacts.
This would allow you to link multiple contacts and give them direct access to their objects via such a permission (we have many internal contact who also have NetBox access).
Beta Was this translation helpful? Give feedback.
All reactions