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

Ability to clone users/groups along with all applicable permissions #3915

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

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

Environment

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

Proposed Functionality

Ability to clone existing users/groups and all their associated permissions to allow easy replication of permissions sets for new users and groups.

Use Case

In #4919 I wrote about my perceived scalability challenges due to multiple permissions rules being required for each user/group due to the constraints. Providing a way to clone an existing user/group along with all their associated permissions would go some way to addressing the scalability issue.

Example, suppose I create two rules with different constraints to map group-a to devices and device components for tenant-a as follows:

Rule 1: group-a, read access to dcim > devices with constraint {'tenant__slug: 'tenant-a'}
Rule 2: group-a, read access to dcim > interface, dcim > console port, etc with constraint {'device__tenant__slug': 'tenant-a'}

It would be nice to be able to simply clone all of these rules when creating 'group-b' who should have read access only to devices, components etc applicable to 'tenant-b'.

Database Changes

None?

External Dependencies

Originally created by @cpmills1975 on GitHub (Jul 29, 2020). <!-- 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 clone existing users/groups and all their associated permissions to allow easy replication of permissions sets for new users and groups. <!-- 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 In #4919 I wrote about my perceived scalability challenges due to multiple permissions rules being required for each user/group due to the constraints. Providing a way to clone an existing user/group along with all their associated permissions would go some way to addressing the scalability issue. Example, suppose I create two rules with different constraints to map group-a to devices and device components for tenant-a as follows: Rule 1: group-a, read access to dcim > devices with constraint `{'tenant__slug: 'tenant-a'}` Rule 2: group-a, read access to dcim > interface, dcim > console port, etc with constraint `{'device__tenant__slug': 'tenant-a'}` It would be nice to be able to simply clone all of these rules when creating 'group-b' who should have read access only to devices, components etc applicable to 'tenant-b'. <!-- 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: needs ownerpending closure labels 2025-12-29 18:32:02 +01:00
adam closed this issue 2025-12-29 18:32:03 +01:00
adam commented 2025-12-29 18:32:03 +01:00
Author
Owner
Copy Link

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

How do you envision the end-to-end workflow? Cloning an existing permission is pretty straightforward, but there needs to be a clear step where the user has an opportunity to make changes. For instance, if you clone a permission with the constraint {'tenant__slug: 'tenant-a'} and assign it to group B, the constraint is still going to reference tenant-a. NetBox can't make any assumption about what, if anything, should change, so we need a human to take care of that.

It might be enough to have a "clone" button on a permission that redirects the user to a pre-populated form to create a new permission. That would be the simplest approach, though it doesn't provide the ability to clone multiple permissions at once.

@jeremystretch commented on GitHub (Jul 29, 2020): How do you envision the end-to-end workflow? Cloning an existing permission is pretty straightforward, but there needs to be a clear step where the user has an opportunity to make changes. For instance, if you clone a permission with the constraint `{'tenant__slug: 'tenant-a'}` and assign it to group B, the constraint is still going to reference `tenant-a`. NetBox can't make any assumption about what, if anything, should change, so we need a human to take care of that. It might be enough to have a "clone" button on a permission that redirects the user to a pre-populated form to create a new permission. That would be the simplest approach, though it doesn't provide the ability to clone multiple permissions at once.
adam commented 2025-12-29 18:32:03 +01:00
Author
Owner
Copy Link

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

I'm thinking here that the main reason for cloning a user/group in the first place would be to produce a set of permissions similar to those being cloned. Those permissions might be normal CRUD permissions over certain object types, or might include constraints so I guess the right thing to do would be just clone all of the permissions verbatim?

As you have said, NetBox can't make any assumptions about the user's intent in cloning the group/permissions so it would have to be up to the user to modify each rule in turn, add additional ones, perhaps delete some etc. I guess my main thought here is that, along with any possible changes made in #4919, it provides a step towards making sure all the permissions are replicated ready for amendment and #4919 will display them all within the group screen to make it obvious what permissions objects might need to be checked/amended.

I can foresee perhaps a situation where the network team of tenant A might require write permissions over network objects belonging to tenant A, and the server team might require write permissions over the servers belonging to tenant A. Neither group should have any visibility of the devices belonging to tenant B. Both groups/sets of permissions would likely have a {"tenant__slug": "tenant-a"} constraint along with perhaps a constraint over the device role.

@cpmills1975 commented on GitHub (Jul 29, 2020): I'm thinking here that the main reason for cloning a user/group in the first place would be to produce a set of permissions similar to those being cloned. Those permissions might be normal CRUD permissions over certain object types, or might include constraints so I guess the right thing to do would be just clone all of the permissions verbatim? As you have said, NetBox can't make any assumptions about the user's intent in cloning the group/permissions so it would have to be up to the user to modify each rule in turn, add additional ones, perhaps delete some etc. I guess my main thought here is that, along with any possible changes made in #4919, it provides a step towards making sure all the permissions are replicated ready for amendment and #4919 will display them all within the group screen to make it obvious what permissions objects might need to be checked/amended. I can foresee perhaps a situation where the network team of tenant A might require write permissions over network objects belonging to tenant A, and the server team might require write permissions over the servers belonging to tenant A. Neither group should have any visibility of the devices belonging to tenant B. Both groups/sets of permissions would likely have a {"tenant__slug": "tenant-a"} constraint along with perhaps a constraint over the device role.
adam commented 2025-12-29 18:32:03 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Oct 31, 2020):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Oct 31, 2020): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:32:03 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Nov 15, 2020):

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.

@stale[bot] commented on GitHub (Nov 15, 2020): 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 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#3915
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?