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

Allow editing of permissions within the group/user edit screens #3914

New Issue
Closed
opened 2025-12-29 18:32:02 +01:00 by adam · 5 comments
adam commented 2025-12-29 18:32:02 +01:00
Owner
Copy Link

Originally created by @cpmills1975 on GitHub (Jul 29, 2020).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.7.8
  • NetBox version: 2.9-beta1

Proposed Functionality

Ability to set permissions within the group add/user add pages.

Use Case

With more granular permissions becoming available in 2.9-beta1 (thank you!), there is potential for scalability issues when adding additional users/groups that need their own sets of permissions leading to potential missing permissions and resulting support overhead.

Currently, permissions need to be set in the permissions screen and for a small number of permissions or where these are limited purely by user/group and perhaps multiple object types this is fine, but with the addition of constraints, and the requirement for a constraint to match a permitted filter for the object type, inevitably many more permissions rules will be required for a given user/group.

Example, in 2.8 a group of admins (perhaps defined by a Django group mapped to an AD group) can be granted full CRUD permissions over all object types with a single rule and a group of RO users can be granted just Read permissions over all object types with one additional rule.

In 2.9, if I want to create a constraint where 'group-a' only has access to devices whose tenant is 'tenant-a', I need to create one rule to map group-a to dcim > device with constraint {'tenant__slug': 'tenant-a'} and a second rule for dcim > interface, dcim > console_port, etc with the constraint {'device__tenant__slug': 'tenant-a'}. In addition to my admin rule, I now have three rules. If I wish to create a second user group for tenant-b, I need to duplicate two rules for tenant-a and modify them both for tenant-b. This will inevitably lead to many many rules being displayed in the permissions screen and the likelihood of missing some when creating subtly different permissions sets for different groups.

This FR seeks to group all applicable permissions for a given user/group and display them within the user/group create/edit screen thus reducing the number of rules displayed and making it easier to duplicate them for new users/groups.

Database Changes

None?

External Dependencies

Originally created by @cpmills1975 on GitHub (Jul 29, 2020). Originally assigned to: @jeremystretch on GitHub. <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.7.8 * NetBox version: 2.9-beta1 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Ability to set permissions within the group add/user add pages. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case With more granular permissions becoming available in 2.9-beta1 (thank you!), there is potential for scalability issues when adding additional users/groups that need their own sets of permissions leading to potential missing permissions and resulting support overhead. Currently, permissions need to be set in the permissions screen and for a small number of permissions or where these are limited purely by user/group and perhaps multiple object types this is fine, but with the addition of constraints, and the requirement for a constraint to match a permitted filter for the object type, inevitably many more permissions rules will be required for a given user/group. Example, in 2.8 a group of admins (perhaps defined by a Django group mapped to an AD group) can be granted full CRUD permissions over all object types with a single rule and a group of RO users can be granted just Read permissions over all object types with one additional rule. In 2.9, if I want to create a constraint where 'group-a' only has access to devices whose tenant is 'tenant-a', I need to create one rule to map group-a to dcim > device with constraint `{'tenant__slug': 'tenant-a'}` and a second rule for dcim > interface, dcim > console_port, etc with the constraint `{'device__tenant__slug': 'tenant-a'}`. In addition to my admin rule, I now have three rules. If I wish to create a second user group for tenant-b, I need to duplicate two rules for tenant-a and modify them both for tenant-b. This will inevitably lead to many many rules being displayed in the permissions screen and the likelihood of missing some when creating subtly different permissions sets for different groups. This FR seeks to group all applicable permissions for a given user/group and display them within the user/group create/edit screen thus reducing the number of rules displayed and making it easier to duplicate them for new users/groups. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes None? <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies
adam added the type: featurestatus: under reviewbeta labels 2025-12-29 18:32:02 +01:00
adam closed this issue 2025-12-29 18:32:02 +01:00
adam commented 2025-12-29 18:32:03 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Jul 29, 2020):

In fact I notice the permissions are already displayed for a user in the user edit screen so I guess replicating this for groups and add the ability to create new rules along with deleting the existing ones would be what I seek.

@cpmills1975 commented on GitHub (Jul 29, 2020): In fact I notice the permissions are already displayed for a user in the user edit screen so I guess replicating this for groups and add the ability to create new rules along with deleting the existing ones would be what I seek.
adam commented 2025-12-29 18:32:03 +01:00
Author
Owner
Copy Link

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

The biggest challenge with this is just getting the admin UI to cooperate. It's probably doable, just need to play around with the forms a bit. Also, I should point out that that you can filter the global permissions list by user and group currently, though I understand this isn't as convenient as embedding permissions directly within the user/group edit view.

Regardless, we should replicate whatever solution we end up with for user permissions to the group view as well.

@jeremystretch commented on GitHub (Jul 29, 2020): The biggest challenge with this is just getting the admin UI to cooperate. It's probably doable, just need to play around with the forms a bit. Also, I should point out that that you can filter the global permissions list by user and group currently, though I understand this isn't as convenient as embedding permissions directly within the user/group edit view. Regardless, we should replicate whatever solution we end up with for user permissions to the group view as well.
adam commented 2025-12-29 18:32:03 +01:00
Author
Owner
Copy Link

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

Ok, I think I've come up with a reasonable solution in 55ee3db5bc. There's still an open question or two around permission naming, but now it's possible to add and edit assigned permissions from within the group and user admin views. Let me know what you think!

@jeremystretch commented on GitHub (Jul 29, 2020): Ok, I think I've come up with a reasonable solution in 55ee3db5bc3a26c2f2e8c3647eae4501a0a5b73c. There's still an open question or two around permission naming, but now it's possible to add and edit assigned permissions from within the group and user admin views. Let me know what you think!
adam commented 2025-12-29 18:32:03 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Aug 3, 2020):

Looks good. My only comment as you have already spotted, is around permission naming. As it is the permission 'name' that is displayed in the drop down boxes on the users and groups pages, I think it would make sense to display this as the 'name' on the permissions page as well so it is easy to identify (and potentially change) the permission itself.

@cpmills1975 commented on GitHub (Aug 3, 2020): Looks good. My only comment as you have already spotted, is around permission naming. As it is the permission 'name' that is displayed in the drop down boxes on the users and groups pages, I think it would make sense to display this as the 'name' on the permissions page as well so it is easy to identify (and potentially change) the permission itself.
adam commented 2025-12-29 18:32:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 3, 2020):

Yep, I've opened and implemented #4943 to make name a required field now. Upon migration, we'll automatically copy over the built-in-style names to the new ObjectPermission instances (users of course have the option of renaming/modifying these as they see fit).

Going to close this out as I believe the implementation is complete, however anyone should feel encouraged to open a new issue for any additional feedback concerning this feature.

@jeremystretch commented on GitHub (Aug 3, 2020): Yep, I've opened and implemented #4943 to make `name` a required field now. Upon migration, we'll automatically copy over the built-in-style names to the new ObjectPermission instances (users of course have the option of renaming/modifying these as they see fit). Going to close this out as I believe the implementation is complete, however anyone should feel encouraged to open a new issue for any additional feedback concerning this feature.
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 beta status: under review 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#3914
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?