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

Omit non-permitted item groups in views #9303

New Issue
Closed
opened 2025-12-29 20:48:06 +01:00 by adam · 5 comments
adam commented 2025-12-29 20:48:06 +01:00
Owner
Copy Link

Originally created by @markkuleinio on GitHub (Feb 28, 2024).

NetBox version

v3.7.3

Feature type

Change to existing functionality

Proposed functionality

Currently the menu items for which the user doesn't have permission are not shown in the main menu.

I'm proposing also omitting the related item groups in the views.

Example: user does not have permission to view IPAM>Services. When the user views a device, there is an empty Services box:

image

I'm proposing that the empty box is omitted.

At the same time (when viewing the device) a Django warning is logged (provided that django logger is configured):

2024-02-28 09:35:40,339 django.request WARNING: Forbidden (Permission denied): /ipam/services/
Traceback (most recent call last):
...
  File "/opt/netbox/netbox/netbox/views/generic/base.py", line 77, in dispatch
    return super().dispatch(request, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/netbox/utilities/views.py", line 104, in dispatch
    return self.handle_no_permission()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/netbox/venv/lib/python3.11/site-packages/django/contrib/auth/mixins.py", line 48, in handle_no_permission
    raise PermissionDenied(self.get_permission_denied_message())
django.core.exceptions.PermissionDenied

I'd expect there would be no PermissionDenied errors in the logs when the users themselves are accessing the views they are permitted to (it's the app that generates the non-permitted attempts in the background, not the user). But this is a side note.

Use case

One major use case for removing the View permissions for models is to improve the user experience for non-admin users: don't show the models (menu items) that are not accessible anyway, or used at all in the specific NetBox implementation. This proposal extends the same idea to the model views (= don't show the boxes that won't be populated anyway, preventing questions like "what does Services mean in our devices, there aren't any").

I believe quite many model views are concerned, examples (potentially non-permitted boxes mentioned):

  • Site view (Images, Locations, Non-Racked Devices)
  • Location view (Images, Non-Racked Devices)
  • Rack view (Images)
  • Device view (Services, Images, Virtual Device Contexts)
  • VLAN view (Prefixes)
  • and so on

Database changes

None I think

External dependencies

None

Originally created by @markkuleinio on GitHub (Feb 28, 2024). ### NetBox version v3.7.3 ### Feature type Change to existing functionality ### Proposed functionality Currently the menu items for which the user doesn't have permission are not shown in the main menu. **I'm proposing also omitting the related item groups in the views.** Example: user does not have permission to view IPAM>Services. When the user views a device, there is an empty Services box: ![image](https://github.com/netbox-community/netbox/assets/25136274/e95a3d86-8b82-46af-bec3-435b2569279b) I'm proposing that the empty box is omitted. At the same time (when viewing the device) a Django warning is logged (provided that `django` logger is configured): ``` 2024-02-28 09:35:40,339 django.request WARNING: Forbidden (Permission denied): /ipam/services/ Traceback (most recent call last): ... File "/opt/netbox/netbox/netbox/views/generic/base.py", line 77, in dispatch return super().dispatch(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/netbox/utilities/views.py", line 104, in dispatch return self.handle_no_permission() ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/netbox/venv/lib/python3.11/site-packages/django/contrib/auth/mixins.py", line 48, in handle_no_permission raise PermissionDenied(self.get_permission_denied_message()) django.core.exceptions.PermissionDenied ``` I'd expect there would be no PermissionDenied errors in the logs when the users themselves are accessing the views they are permitted to (it's the app that generates the non-permitted attempts in the background, not the user). But this is a side note. ### Use case One major use case for removing the View permissions for models is to improve the user experience for non-admin users: don't show the models (menu items) that are not accessible anyway, or used at all in the specific NetBox implementation. This proposal extends the same idea to the model views (= don't show the boxes that won't be populated anyway, preventing questions like "what does Services mean in our devices, there aren't any"). I believe quite many model views are concerned, examples (potentially non-permitted boxes mentioned): - Site view (Images, Locations, Non-Racked Devices) - Location view (Images, Non-Racked Devices) - Rack view (Images) - Device view (Services, Images, Virtual Device Contexts) - VLAN view (Prefixes) - and so on ### Database changes None I think ### External dependencies None
adam added the type: featurestatus: needs ownerpending closurecomplexity: medium labels 2025-12-29 20:48:07 +01:00
adam closed this issue 2025-12-29 20:48:07 +01:00
adam commented 2025-12-29 20:48:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 3, 2024):

Seems like a pretty steep effort-to-value ratio IMO but I've opened this for volunteers.

@jeremystretch commented on GitHub (Apr 3, 2024): Seems like a pretty steep effort-to-value ratio IMO but I've opened this for volunteers.
adam commented 2025-12-29 20:48:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 21, 2024):

@abhi1693 are you still planning to work on this?

@jeremystretch commented on GitHub (May 21, 2024): @abhi1693 are you still planning to work on this?
adam commented 2025-12-29 20:48:08 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (May 28, 2024):

I think we can add this functionality with the changes of #15876 by simply filtering the generated list of relations by "can view" permissions.

@alehaa commented on GitHub (May 28, 2024): I think we can add this functionality with the changes of #15876 by simply filtering the generated list of relations by "can view" permissions.
adam commented 2025-12-29 20:48:08 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 12, 2024):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Sep 12, 2024): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:48:08 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 13, 2024):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Oct 13, 2024): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 complexity: medium pending closure status: needs owner type: feature
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#9303
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?