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

Display list of devices when choosing to add a device to a rack #10733

New Issue
Closed
opened 2025-12-29 21:35:19 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:35:19 +01:00
Owner
Copy Link

Originally created by @chatasos on GitHub (Feb 4, 2025).

NetBox version

v4.1.10

Feature type

Change to existing functionality

Proposed functionality

Either change the "Add device" option in racks to allow choosing from a list of devices, or add another option to accomplish the same functionality using a totally separate action.

Personally i would prefer to display a list of existing devices by default (filtered by site/location if applicable), when clicking the add device (assuming the user has view permission to devices).
As an addon, an extra option could be provided to add a new device to a rack for users that have add permission to devices. Then the current behavior would be followed.

Currently the racks screen is confusing, because someone will full permissions on it, gets an access denied message when trying to add a device to a rack (he doesn't know that this action makes him add a new device to the system and then to a rack, while he just wants to add a device to a rack).

Similar discussions have happened in the past in the following links, but i didn't notice any reference of permissions there.
https://github.com/netbox-community/netbox/pull/8876
https://github.com/netbox-community/netbox/issues/8552
https://github.com/netbox-community/netbox/pull/4190
https://github.com/netbox-community/netbox/issues/1830

Extra config options could limit the devices list only to the ones with specific dcim.Device.status.

Use case

In my previous working environment (provider), but also in the current one (enterprise/utilities), we have distinct roles for field/infrastructure engineers and network engineers. Some of these might be external partners as well.

Network engineers (in general) are responsible for the configuration (operation/monitoring/etc) of a network device, while field engineers are responsible for the hardware preparation/(de)installation of the network device.

So, when a new network device is about to be activated, the field engineer will take it from the warehouse, install modules/power-supplies/etc and then install it to a rack he chooses, all based on the power/connectivity requirements given by the network engineer. Then he will make the cabling and so on.

While working in the provider we had a internal-built NSoT application, which was developed according to our needs and it did our job very well. Now in the enterprise environment I have chosen netbox to play this role, but this is one of the issues I have encountered with it.

The current "add device to rack" functionality cannot be accomplished by the field engineer, because:

  1. he doesn't have the permission to do it (he has full permission to racks, but view-only to devices)
  2. even if he had the permission to do it, he would actualy need to create a new device which is neither desirable nor possible (this is done programmatically by the network engineer).

The same issue applies for every change originated by the field engineers (i.e. device relocations). They need to inform the network engineers what to update in netbox, while network engineers do not deal with such things.

As a result, this limitation has added extra uneeded communication steps in our workflows, something we would like to avoid.

Database changes

No response

External dependencies

No response

Originally created by @chatasos on GitHub (Feb 4, 2025). ### NetBox version v4.1.10 ### Feature type Change to existing functionality ### Proposed functionality Either change the "Add device" option in racks to allow choosing from a list of devices, or add another option to accomplish the same functionality using a totally separate action. Personally i would prefer to **display a list of existing devices** by default (filtered by site/location if applicable), when clicking the add device (assuming the user has view permission to devices). As an addon, an extra option could be provided to add a new device to a rack for users that have add permission to devices. Then the current behavior would be followed. Currently the racks screen is confusing, **because someone will full permissions on it, gets an access denied message when trying to add a device to a rack** (he doesn't know that this action makes him add a new device to the system and then to a rack, while he just wants to add a device to a rack). Similar discussions have happened in the past in the following links, but i didn't notice any reference of permissions there. https://github.com/netbox-community/netbox/pull/8876 https://github.com/netbox-community/netbox/issues/8552 https://github.com/netbox-community/netbox/pull/4190 https://github.com/netbox-community/netbox/issues/1830 Extra config options could limit the devices list only to the ones with specific dcim.Device.status. ### Use case In my previous working environment (provider), but also in the current one (enterprise/utilities), we have distinct roles for field/infrastructure engineers and network engineers. Some of these might be external partners as well. Network engineers (in general) are responsible for the configuration (operation/monitoring/etc) of a network device, while field engineers are responsible for the hardware preparation/(de)installation of the network device. So, when a new network device is about to be activated, the field engineer will take it from the warehouse, install modules/power-supplies/etc and then install it to a rack he chooses, all based on the power/connectivity requirements given by the network engineer. Then he will make the cabling and so on. While working in the provider we had a internal-built NSoT application, which was developed according to our needs and it did our job very well. Now in the enterprise environment I have chosen netbox to play this role, but this is one of the issues I have encountered with it. The current "add device to rack" functionality cannot be accomplished by the field engineer, because: 1) he doesn't have the permission to do it (he has full permission to racks, but view-only to devices) 2) even if he had the permission to do it, he would actualy need to create a new device which is neither desirable nor possible (this is done programmatically by the network engineer). The same issue applies for every change originated by the field engineers (i.e. device relocations). They need to inform the network engineers what to update in netbox, while network engineers do not deal with such things. As a result, this limitation has added extra uneeded communication steps in our workflows, something we would like to avoid. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 21:35:19 +01:00
adam closed this issue 2025-12-29 21:35:20 +01:00
adam commented 2025-12-29 21:35:20 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 5, 2025):

I am going to take some time to respond to a few of your issues here

Currently the racks screen is confusing, because someone will full permissions on it, gets an access denied message when trying to add a device to a rack (he doesn't know that this action makes him add a new device to the system and then to a rack, while he just wants to add a device to a rack).

You are effectively editing the device, so you need device permissions. You could give your field engineers full control over editing the actual device (but not components) and then use a custom validator to check that nothing has changed beyond the rack information.

#8552
#1830

These two are the only issues. Please don't include PR's to inflate the "issue count", it isn't needed

Extra config options could limit the devices list only to the ones with specific dcim.Device.status.

Filtering options would be available in the object picker itself.

Use case

In my previous working environment (provider), but also in the current one (enterprise/utilities), we have distinct roles for field/infrastructure engineers and network engineers. Some of these might be external partners as well.

Network engineers (in general) are responsible for the configuration (operation/monitoring/etc) of a network device, while field engineers are responsible for the hardware preparation/(de)installation of the network device.

So, when a new network device is about to be activated, the field engineer will take it from the warehouse, install modules/power-supplies/etc and then install it to a rack he chooses, all based on the power/connectivity requirements given by the network engineer. Then he will make the cabling and so on.

While working in the provider we had a internal-built NSoT application, which was developed according to our needs and it did our job very well. Now in the enterprise environment I have chosen NetBox to play this role, but this is one of the issues I have encountered with it.

All of this above is unneeded, it is not really the use case. It is extra background that we don't need.

  1. he doesn't have the permission to do it (he has full permission to racks, but view-only to devices)

Unfortunately this will not change by simply making "assign to rack" a special form, it would require a fundamental change to the permissions and that unfortunately is too much work for us to undertake

  1. even if he had the permission to do it, he would actually need to create a new device which is neither desirable nor possible

I don't see why he would need to create a new device. You would simply edit the device.

The same issue applies for every change originated by the field engineers (i.e. device relocations). They need to inform the network engineers what to update in NetBox, while network engineers do not deal with such things.

Unfortunately, all of what you actually want is do-able within NetBox (may require some customization). For your use case, you have two real options:

  1. Write a custom script or plugin, which can bypasses the permissions and present the simplified "Assign Device"
  2. Give your techs permissions to edit devices, add a custom validator to enforce the only changes be to location specific fields (Site, Location, Rack, etc)

There is merit in having a more simplified "Assign Device" workflow, however this FR is insufficient to move forward on as all the issues identified in this FR's use case are not specific to an "Assign Device" workflow and are instead indicative of a business workflow that needs refinement within NetBox itself.

@DanSheps commented on GitHub (Feb 5, 2025): I am going to take some time to respond to a few of your issues here > Currently the racks screen is confusing, **because someone will full permissions on it, gets an access denied message when trying to add a device to a rack** (he doesn't know that this action makes him add a new device to the system and then to a rack, while he just wants to add a device to a rack). You are effectively editing the device, so you need device permissions. You could give your field engineers full control over editing the actual device (but not components) and then use a custom validator to check that nothing has changed beyond the rack information. > [#8552](https://github.com/netbox-community/netbox/issues/8552) > [#1830](https://github.com/netbox-community/netbox/issues/1830) These two are the only issues. Please don't include PR's to inflate the "issue count", it isn't needed > Extra config options could limit the devices list only to the ones with specific dcim.Device.status. Filtering options would be available in the object picker itself. > ### Use case > In my previous working environment (provider), but also in the current one (enterprise/utilities), we have distinct roles for field/infrastructure engineers and network engineers. Some of these might be external partners as well. > > Network engineers (in general) are responsible for the configuration (operation/monitoring/etc) of a network device, while field engineers are responsible for the hardware preparation/(de)installation of the network device. > > So, when a new network device is about to be activated, the field engineer will take it from the warehouse, install modules/power-supplies/etc and then install it to a rack he chooses, all based on the power/connectivity requirements given by the network engineer. Then he will make the cabling and so on. > > While working in the provider we had a internal-built NSoT application, which was developed according to our needs and it did our job very well. Now in the enterprise environment I have chosen NetBox to play this role, but this is one of the issues I have encountered with it. All of this above is unneeded, it is not really the use case. It is extra background that we don't need. > 1. he doesn't have the permission to do it (he has full permission to racks, but view-only to devices) Unfortunately this will not change by simply making "assign to rack" a special form, it would require a fundamental change to the permissions and that unfortunately is too much work for us to undertake > 2. even if he had the permission to do it, he would actually need to create a new device which is neither desirable nor possible I don't see why he would need to create a new device. You would simply edit the device. > The same issue applies for every change originated by the field engineers (i.e. device relocations). They need to inform the network engineers what to update in NetBox, while network engineers do not deal with such things. Unfortunately, all of what you actually want is do-able within NetBox (may require some customization). For your use case, you have two real options: 1. Write a custom script or plugin, which can bypasses the permissions and present the simplified "Assign Device" 2. Give your techs permissions to edit devices, add a custom validator to enforce the only changes be to location specific fields (Site, Location, Rack, etc) There is merit in having a more simplified "Assign Device" workflow, however this FR is insufficient to move forward on as all the issues identified in this FR's use case are not specific to an "Assign Device" workflow and are instead indicative of a business workflow that needs refinement within NetBox itself.
adam commented 2025-12-29 21:35:21 +01:00
Author
Owner
Copy Link

@chatasos commented on GitHub (Feb 5, 2025):

Daniel, thank you for taking the time to respond to my feature request. I appreciate the detailed feedback, but I'd like to address a few points and provide additional context to better clarify my request:

Past discussions: I included the past discussions to highlight that this topic has been brought up multiple times, showing ongoing interest and need for improvement in this area. I did not intend to inflate the issue count, but to provide context. Your comment has been noted.

Use case: The background information provided was to illustrate the practical challenges we face in our workflow. The separation of roles between field engineers and network engineers is common in many organizations, and having a clear distinction in permissions and capabilities is crucial for efficient operations. I would be very surprised to find out that only a few organizations face similar challenges.

Editing device permissions: I understand that editing the device requires device permissions. However, in our environment (power utility company), giving field engineers full control over editing devices (even with custom validators) is not ideal due to compliance and security concerns. We need to ensure that field engineers can perform specific tasks without having broader access than necessary. Let's keep the custom validator as a workaround, maybe suitable for other types of enterprises.

Assign to rack vs Creating a new device: I understand that making "assign to rack" a special form would require significant changes to the permissions model. However, I believe that this change would greatly benefit users with similar workflows, reducing unnecessary communication and potential errors. The point I was trying to make is that the current "add device to rack" functionality can be confusing (*). Another example is that users (field engineers) might unintentionally create a new device when they simply want to assign an existing one to a rack. Clarifying this process would improve the user experience.

(*) i always assume the field engineer is using the racks menu for his actions, not the devices one. Right now the racks menu can be used for :

  • adding a new device to a specific rack (Add permission on devices)
  • viewing everything on a existing device already added to a rack (View permission on devices)

It cannot be used for adding an existing device to a specific rack (Change permission on devices). This can only be accomplished via the devices menu.

Custom script/plugin: Writing a custom script or plugin seems a valid option, but i need to make further research due to limited exposure to netbox internals. In any case, a native solution within NetBox would be more accessible and beneficial to a broader user base.

I'm glad to hear that there is merit in having a more simplified "Assign Device" workflow. I believe that addressing the specific issues identified in this feature request would lead to significant improvements in the usability and flexibility of NetBox for users with similar workflows.

Thank you again for your time and consideration. I hope this clarifies the need for the proposed changes, and I am open to further discussion to find the best solution.

@chatasos commented on GitHub (Feb 5, 2025): Daniel, thank you for taking the time to respond to my feature request. I appreciate the detailed feedback, but I'd like to address a few points and provide additional context to better clarify my request: Past discussions: I included the past discussions to highlight that this topic has been brought up multiple times, showing ongoing interest and need for improvement in this area. I did not intend to inflate the issue count, but to provide context. Your comment has been noted. Use case: The background information provided was to illustrate the practical challenges we face in our workflow. The separation of roles between field engineers and network engineers is common in many organizations, and having a clear distinction in permissions and capabilities is crucial for efficient operations. I would be very surprised to find out that only a few organizations face similar challenges. Editing device permissions: I understand that editing the device requires device permissions. However, in our environment (power utility company), giving field engineers full control over editing devices (even with custom validators) is not ideal due to compliance and security concerns. We need to ensure that field engineers can perform specific tasks without having broader access than necessary. Let's keep the custom validator as a workaround, maybe suitable for other types of enterprises. Assign to rack vs Creating a new device: I understand that making "assign to rack" a special form would require significant changes to the permissions model. However, I believe that this change would greatly benefit users with similar workflows, reducing unnecessary communication and potential errors. The point I was trying to make is that the current "add device to rack" functionality can be confusing (*). Another example is that users (field engineers) might unintentionally create a new device when they simply want to assign an existing one to a rack. Clarifying this process would improve the user experience. (*) i always assume the field engineer is using the racks menu for his actions, not the devices one. Right now the racks menu can be used for : - adding a new device to a specific rack (Add permission on devices) - viewing everything on a existing device already added to a rack (View permission on devices) It cannot be used for adding an existing device to a specific rack (Change permission on devices). This can only be accomplished via the devices menu. Custom script/plugin: Writing a custom script or plugin seems a valid option, but i need to make further research due to limited exposure to netbox internals. In any case, a native solution within NetBox would be more accessible and beneficial to a broader user base. I'm glad to hear that there is merit in having a more simplified "Assign Device" workflow. I believe that addressing the specific issues identified in this feature request would lead to significant improvements in the usability and flexibility of NetBox for users with similar workflows. Thank you again for your time and consideration. I hope this clarifies the need for the proposed changes, and I am open to further discussion to find the best solution.
adam commented 2025-12-29 21:35:21 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 6, 2025):

Thanks for the additional information.

@DanSheps commented on GitHub (Feb 6, 2025): Thanks for the additional information.
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 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#10733
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?