starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add View Permissions #240

New Issue
Closed
opened 2025-12-29 16:19:58 +01:00 by adam · 18 comments
adam commented 2025-12-29 16:19:58 +01:00
Owner
Copy Link

Originally created by @dinoocch on GitHub (Jul 18, 2016).

Originally assigned to: @jeremystretch on GitHub.

It would be nice to have the ability to add the following functionality to restrict viewing of data

For example User A might not need to view Rack information, and therefore shouldn't have access to it.

(In an ideal world, we could be even more granular, specifying user group permission by global tag for example, #132, but I don't think this is necessary...)

Adding view permissions allows us to expand the users who have access to the Netbox database, which would make the tool much more flexible for us.

Originally created by @dinoocch on GitHub (Jul 18, 2016). Originally assigned to: @jeremystretch on GitHub. It would be nice to have the ability to add the following functionality to restrict viewing of data For example User A might not need to view Rack information, and therefore shouldn't have access to it. (In an ideal world, we could be even more granular, specifying user group permission by global tag for example, #132, but I don't think this is necessary...) Adding view permissions allows us to expand the users who have access to the Netbox database, which would make the tool much more flexible for us.
adam added the status: accepted label 2025-12-29 16:19:58 +01:00
adam closed this issue 2025-12-29 16:19:58 +01:00
adam commented 2025-12-29 16:19:59 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 21, 2016):

Team permissions would be great, maybe tied to device types or device type tags, such that the ops team sees servers and related info, network team sees network and circuit gear and servers, datacenter server team sees servers and network and storage gear, etc, some/all other groups can see IP address info, etc. Possibly tied to AD group membership?

@ghost commented on GitHub (Jul 21, 2016): Team permissions would be great, maybe tied to device types or device type tags, such that the ops team sees servers and related info, network team sees network and circuit gear and servers, datacenter server team sees servers and network and storage gear, etc, some/all other groups can see IP address info, etc. Possibly tied to AD group membership?
adam commented 2025-12-29 16:19:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 29, 2016):

@rekkoner You're describing object-level permissions, which is a different ballgame. NetBox supports group-based permissions and, given its nature as an internal infrastructure tool, I think that's as far as we'll go.

@jeremystretch commented on GitHub (Jul 29, 2016): @rekkoner You're describing object-level permissions, which is a different ballgame. NetBox supports group-based permissions and, given its nature as an internal infrastructure tool, I think that's as far as we'll go.
adam commented 2025-12-29 16:19:59 +01:00
Author
Owner
Copy Link

@fltchr commented on GitHub (Aug 4, 2016):

@jeremystretch, would you consider permissions on the site level? We have multiple disparate sites with folks responsible for each. Aside from our infrastructure team, there's really no need for anyone to see the other sites and we definitely don't want them to have the ability to edit the other sites. If we could assign a user to a site and allow them to only see items scoped to their site, that would take care of this. Awesome product by the way. I look forward to seeing it grow.

@fltchr commented on GitHub (Aug 4, 2016): @jeremystretch, would you consider permissions on the site level? We have multiple disparate sites with folks responsible for each. Aside from our infrastructure team, there's really no need for anyone to see the other sites and we definitely don't want them to have the ability to edit the other sites. If we could assign a user to a site and allow them to only see items scoped to their site, that would take care of this. Awesome product by the way. I look forward to seeing it grow.
adam commented 2025-12-29 16:20:00 +01:00
Author
Owner
Copy Link

@jvolt commented on GitHub (Aug 5, 2016):

I would like to strengthen their requests.
We do not trust anyone accessing any site or rack group, because the field team (hallways racks) do not know data center details.

@jvolt commented on GitHub (Aug 5, 2016): I would like to strengthen their requests. We do not trust anyone accessing any site or rack group, because the field team (hallways racks) do not know data center details.
adam commented 2025-12-29 16:20:00 +01:00
Author
Owner
Copy Link

@Lucho66 commented on GitHub (Aug 24, 2016):

Hi , This tool is great!! Just one question, once installed ,netbox allows anyone visiting the site see my inventory information. It is possible to authenticate the user first? and add view permissons ?, for example , some user can only the IPAM view

@Lucho66 commented on GitHub (Aug 24, 2016): Hi , This tool is great!! Just one question, once installed ,netbox allows anyone visiting the site see my inventory information. It is possible to authenticate the user first? and add view permissons ?, for example , some user can only the IPAM view
adam commented 2025-12-29 16:20:00 +01:00
Author
Owner
Copy Link

@fltchr commented on GitHub (Aug 25, 2016):

@Lucho66, you may set LOGIN_REQUIRED to TRUE (FALSE by default) to require a login to Netbox before viewing any data. This is in ./netbox/netbox/configuration.py.

@fltchr commented on GitHub (Aug 25, 2016): @Lucho66, you may set LOGIN_REQUIRED to TRUE (FALSE by default) to require a login to Netbox before viewing any data. This is in ./netbox/netbox/configuration.py.
adam commented 2025-12-29 16:20:00 +01:00
Author
Owner
Copy Link

@Lucho66 commented on GitHub (Aug 25, 2016):

thanks fltchr, this fix my problem

@Lucho66 commented on GitHub (Aug 25, 2016): thanks fltchr, this fix my problem
adam commented 2025-12-29 16:20:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 5, 2018):

Django 2.1 introduced model-level view permissions, which permit access to a type of object (not individual objects) alongside the existing add/change/delete permissions. While enforcing these new view permissions should be fairly straightforward, I'm not sure how we'd handle their initial assignment.

If we begin enforcing but don't automatically assign the view permissions, regular users (non-superusers) won't be able to access any objects until an administrator manually assigns the permissions. However, we also don't want to blindly assign the new permissions to all users, as some organizations prefer to manage permissions at the group level.

A compromise might be to assign view permissions to any user or group with an existing add/change/delete permissions for each model, but that would still potentially block access for some users who should have it.

We could also just ignore the view permissions for the v2.5 release, giving admins time to assign permissions as they see fit before they're enforced. I'm open to suggestions.

@jeremystretch commented on GitHub (Nov 5, 2018): Django 2.1 introduced [model-level view permissions](https://docs.djangoproject.com/en/2.1/releases/2.1/#model-view-permission), which permit access to a type of object (not individual objects) alongside the existing add/change/delete permissions. While enforcing these new view permissions should be fairly straightforward, I'm not sure how we'd handle their initial assignment. If we begin enforcing but don't automatically assign the view permissions, regular users (non-superusers) won't be able to access any objects until an administrator manually assigns the permissions. However, we also don't want to blindly assign the new permissions to all users, as some organizations prefer to manage permissions at the group level. A compromise might be to assign view permissions to any user or group with an existing add/change/delete permissions for each model, but that would still potentially block access for some users who should have it. We could also just ignore the view permissions for the v2.5 release, giving admins time to assign permissions as they see fit before they're enforced. I'm open to suggestions.
adam commented 2025-12-29 16:20:01 +01:00
Author
Owner
Copy Link

@swerveshot commented on GitHub (Nov 11, 2018):

Just to be clear. I just read the link you posted on Django view permissions. This feature only controls read only access? So what about add/change/delete? Or is this not within the scope of this issue?

Either way adopting a permissions model from a framework you are already using this seems only logical to me. It's good that you describe the potential impact so admins of existing installs have some time to make the necessary changes for the 2.6 release. I'm glad you haven't forgotten about this issue since it is over two years old.

@swerveshot commented on GitHub (Nov 11, 2018): Just to be clear. I just read the link you posted on Django view permissions. This feature only controls read only access? So what about add/change/delete? Or is this not within the scope of this issue? Either way adopting a permissions model from a framework you are already using this seems only logical to me. It's good that you describe the potential impact so admins of existing installs have some time to make the necessary changes for the 2.6 release. I'm glad you haven't forgotten about this issue since it is over two years old.
adam commented 2025-12-29 16:20:01 +01:00
Author
Owner
Copy Link

@swerveshot commented on GitHub (Nov 11, 2018):

Could it be that what I'm looking for is actually issue #554?

@swerveshot commented on GitHub (Nov 11, 2018): Could it be that what I'm looking for is actually issue #554?
adam commented 2025-12-29 16:20:01 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 13, 2018):

Add/Change/Delete was already present, this just adds view permissions.

@DanSheps commented on GitHub (Nov 13, 2018): Add/Change/Delete was already present, this just adds view permissions.
adam commented 2025-12-29 16:20:02 +01:00
Author
Owner
Copy Link

@swerveshot commented on GitHub (Nov 14, 2018):

Okay so this feature just adds the ability to assign view permissions to a particular section of the inventory. Right?

@swerveshot commented on GitHub (Nov 14, 2018): Okay so this feature just adds the ability to assign view permissions to a particular section of the inventory. Right?
adam commented 2025-12-29 16:20:02 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 14, 2018):

Correct

Django 2.1 release notes

Model “view” permission

A “view” permission is added to the model Meta.default_permissions. The new permissions will be created automatically when running migrate.

This allows giving users read-only access to models in the admin. ModelAdmin.has_view_permission() is new. The implementation is backwards compatible in that there isn’t a need to assign the “view” permission to allow users who have the “change” permission to edit objects.

There are a couple of backwards incompatible considerations.

@DanSheps commented on GitHub (Nov 14, 2018): Correct [Django 2.1 release notes](https://docs.djangoproject.com/en/2.1/releases/2.1/) > ### Model “view” permission > > A “view” permission is added to the model Meta.default_permissions. The new permissions will be created automatically when running migrate. > >This allows giving users read-only access to models in the admin. ModelAdmin.has_view_permission() is new. The implementation is backwards compatible in that there isn’t a need to assign the “view” permission to allow users who have the “change” permission to edit objects. > > There are a couple of backwards incompatible considerations.
adam commented 2025-12-29 16:20:02 +01:00
Author
Owner
Copy Link

@mdaviesnz commented on GitHub (Dec 19, 2018):

@jeremystretch
In the release notes for 2.5.0 you said:

Users are encourage to begin assigning view permissions as desired in preparation for their eventual enforcement.

How is this actually done?

@mdaviesnz commented on GitHub (Dec 19, 2018): @jeremystretch In the release notes for 2.5.0 you said: > Users are encourage to begin assigning view permissions as desired in preparation for their eventual enforcement. How is this actually done?
adam commented 2025-12-29 16:20:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 20, 2018):

@mdaviesnz The same as with other permissions. Assign them to groups and/or users through the NetBox admin UI.

@jeremystretch commented on GitHub (Dec 20, 2018): @mdaviesnz The same as with other permissions. Assign them to groups and/or users through the NetBox admin UI.
adam commented 2025-12-29 16:20:03 +01:00
Author
Owner
Copy Link

@fnordpojk commented on GitHub (Jan 21, 2019):

Today, if the user does not have view permissions for Secrets, that module disappears off the front page.

I assume this will also be the case for the other modules, come 2.6.0?

We are only using the Tenant and IPAM modules and this would significantly lower user confusion for us.

@fnordpojk commented on GitHub (Jan 21, 2019): Today, if the user does not have view permissions for Secrets, that module disappears off the front page. I assume this will also be the case for the other modules, come 2.6.0? We are only using the Tenant and IPAM modules and this would significantly lower user confusion for us.
adam commented 2025-12-29 16:20:03 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 25, 2019):

Right now our existing "browsing" users are not member of any group. In fact we don't have any groups created: there are browsing users, and there are admins.

So as part of the migration, if it finds there are enabled users who are not members of any group, at minimum I think Netbox should create a default "View Everything" group, and assign those users to that group.

If no other groups have any "view" permissions, then either "view" can be added to those existing groups - or all users can be added to the "View Everything" group.

I think the logical and approach is simply to create a "View Everything" group and make all existing users be a member of it. This maintains functionality as-is, and can then be tightened up as required.

@candlerb commented on GitHub (Jan 25, 2019): Right now our existing "browsing" users are not member of any group. In fact we don't have any groups created: there are browsing users, and there are admins. So as part of the migration, if it finds there are enabled users who are not members of any group, at minimum I think Netbox should create a default "View Everything" group, and assign those users to that group. ~~If no other groups have any "view" permissions, then either "view" can be added to those existing groups - or all users can be added to the "View Everything" group.~~ I think the logical and approach is simply to create a "View Everything" group and make all existing users be a member of it. This maintains functionality as-is, and can then be tightened up as required.
adam commented 2025-12-29 16:20:03 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 22, 2019):

It occurs to me that view permissions should be evaluated only if LOGIN_REQUIRED is True. Otherwise, it would be impossible to grant any useful access to anonymous users.

@jeremystretch commented on GitHub (Feb 22, 2019): It occurs to me that view permissions should be evaluated only if `LOGIN_REQUIRED` is True. Otherwise, it would be impossible to grant any useful access to anonymous users.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#240
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?