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

Way to document brushpanel/cablemanager #7098

New Issue
Closed
opened 2025-12-29 20:19:14 +01:00 by adam · 9 comments
adam commented 2025-12-29 20:19:14 +01:00
Owner
Copy Link

Originally created by @PieterL75 on GitHub (Oct 11, 2022).

NetBox version

v3.3.5

Feature type

New functionality

Proposed functionality

It would be great that we could mark units in a rack as 'occupied with brushpanel/cableguide', without the need of creating them as devices.

Use case

In our the rack elevation, there are many empty slots.
This is mainly because there no easy way to document brushpanels and cableguides.
The only way is to create a device per panel and populate that in the rack, and that is a lot of work and not really relevant to the device objects lifecycle

This will make the presentation of the rack elevations better, and will give us a better overview of the unit usage of the racks.

Database changes

  • extra csv field of 'occupied' units in a rack.
  • optional a 'type' field of the used rackunit (brushpanel, cableguide, ...)

External dependencies

No response

Originally created by @PieterL75 on GitHub (Oct 11, 2022). ### NetBox version v3.3.5 ### Feature type New functionality ### Proposed functionality It would be great that we could mark units in a rack as 'occupied with brushpanel/cableguide', without the need of creating them as devices. ### Use case In our the rack elevation, there are many empty slots. This is mainly because there no easy way to document brushpanels and cableguides. The only way is to create a device per panel and populate that in the rack, and that is a lot of work and not really relevant to the device objects lifecycle This will make the presentation of the rack elevations better, and will give us a better overview of the unit usage of the racks. ### Database changes - extra csv field of 'occupied' units in a rack. - optional a 'type' field of the used rackunit (brushpanel, cableguide, ...) ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:19:14 +01:00
adam closed this issue 2025-12-29 20:19:14 +01:00
adam commented 2025-12-29 20:19:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 11, 2022):

Thank you for submitting this issue, however it appears that this topic has already been raised. Please see issue #9129 for further discussion.

@jeremystretch commented on GitHub (Oct 11, 2022): Thank you for submitting this issue, however it appears that this topic has already been raised. Please see issue #9129 for further discussion.
adam commented 2025-12-29 20:19:15 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Oct 11, 2022):

I overlooked that topic, as it was closed already.
It handles mainly about blank panels. but those are not the goal of my request.
I don't see any value in keeping track of blank panels, the solution to that, is to make the background of a rack black :-)

My aim , is to document Units that are occupied by items that are not devices (no ports, no power, no serial, no asset tag)
It is import for planning to know what units are in use by those items.

Creating a device for each brushpanel is too much overhead. How to call those ? and what status do you give them ?

It would be easier to just be able to mark units as in use per rack, with an optional idea to use a dropdown to select what the unit is used by.

@PieterL75 commented on GitHub (Oct 11, 2022): I overlooked that topic, as it was closed already. It handles mainly about blank panels. but those are not the goal of my request. I don't see any value in keeping track of blank panels, the solution to that, is to make the background of a rack black :-) My aim , is to document Units that are occupied by items that are not devices (no ports, no power, no serial, no asset tag) It is import for planning to know what units are in use by those items. Creating a device for each brushpanel is too much overhead. How to call those ? and what status do you give them ? It would be easier to just be able to mark units as in use per rack, with an optional idea to use a dropdown to select what the unit is used by.
adam commented 2025-12-29 20:19:15 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Oct 11, 2022):

also seeing https://github.com/netbox-community/netbox/issues/417 all with a lot of thumsup...

We did document those things as devices in the past, but that was not workable.. we had 1/4 of our devices being brushpanels..
In our old cmdb we did create the 'occupied slot' feature and that really made things feel more 'real'

@PieterL75 commented on GitHub (Oct 11, 2022): also seeing https://github.com/netbox-community/netbox/issues/417 all with a lot of thumsup... We did document those things as devices in the past, but that was not workable.. we had 1/4 of our devices being brushpanels.. In our old cmdb we did create the 'occupied slot' feature and that really made things feel more 'real'
adam commented 2025-12-29 20:19:16 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Oct 11, 2022):

How to call those ?

You don't have to call them anything, devices can be unnamed.

and what status do you give them ?

Active?

@kkthxbye-code commented on GitHub (Oct 11, 2022): > How to call those ? You don't have to call them anything, devices can be unnamed. > and what status do you give them ? Active?
adam commented 2025-12-29 20:19:16 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Oct 11, 2022):

Not active, just dead? Never tried unnamed devices, strange idea..

Devices are really not the way to put this in.
It is not a device, just a panel that lies en mass in the datacenter and don't need lifecycle, monitoring, ticketing, ...

Maybe we should get back to another FR, and that is too hide devices from the default view (like 'out of production'). Then those panels can still be a device, but will not show up in a simple search, only when a specific status is selected...

@PieterL75 commented on GitHub (Oct 11, 2022): Not active, just dead? Never tried unnamed devices, strange idea.. Devices are really not the way to put this in. It is not a device, just a panel that lies en mass in the datacenter and don't need lifecycle, monitoring, ticketing, ... Maybe we should get back to another FR, and that is too hide devices from the default view (like 'out of production'). Then those panels can still be a device, but will not show up in a simple search, only when a specific status is selected...
adam commented 2025-12-29 20:19:16 +01:00
Author
Owner
Copy Link

@baldgeek commented on GitHub (Oct 11, 2022):

Our current dcim product considers these kinds of things to be passive
items and directly part of the rack parent. It always felt a bit clunky,
bit it does keep them out of searches unless you are looking for them
directly.

On 10/11/22 2:48 PM, PieterL75 wrote:

Not active, just dead? Never tried unnamed devices, strange idea..

Devices are really not the way to put this in.
It is not a device, just a panel that lies en mass in the datacenter
and don't need lifecycle, monitoring, ticketing, ...

Maybe we should get back to another FR, and that is too hide devices
from the default view (like 'out of production'). Then those panels
can still be a device, but will not show up in a simple search, only
when a specific status is selected...

Message ID: @.***>

@baldgeek commented on GitHub (Oct 11, 2022): Our current dcim product considers these kinds of things to be passive items and directly part of the rack parent. It always felt a bit clunky, bit it does keep them out of searches unless you are looking for them directly. On 10/11/22 2:48 PM, PieterL75 wrote: > > Not active, just dead? Never tried unnamed devices, strange idea.. > > Devices are really not the way to put this in. > It is not a device, just a panel that lies en mass in the datacenter > and don't need lifecycle, monitoring, ticketing, ... > > Maybe we should get back to another FR, and that is too hide devices > from the default view (like 'out of production'). Then those panels > can still be a device, but will not show up in a simple search, only > when a specific status is selected... > > Message ID: ***@***.***> >
adam commented 2025-12-29 20:19:16 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 12, 2022):

We did document those things as devices in the past, but that was not workable.. we had 1/4 of our devices being brushpanels..

In our old cmdb we did create the 'occupied slot' feature and that really made things feel more 'real'

I have 11261 "Devices". I would say over 3/4 of them are not traditional "devices". I have some devices which are simply a front and a rear-port to represent a wall/ceiling termination.

You can model any items using Devices. As mentioned, you don't need to give these devices names and the bare minimum of information is all that is required.

It is not a device, just a panel that lies en mass in the datacenter and don't need lifecycle, monitoring, ticketing, ...

A panel is still a device (Definition: "a piece of equipment or a mechanism designed to serve a special purpose or perform a special function"), just not a device that has any interfaces.

Maybe we should get back to another FR, and that is too hide devices from the default view (like 'out of production'). Then those panels can still be a device, but will not show up in a simple search, only when a specific status is selected...

There are a number of filters you can already employ to remove these from view

@DanSheps commented on GitHub (Oct 12, 2022): > We did document those things as devices in the past, but that was not workable.. we had 1/4 of our devices being brushpanels.. > > In our old cmdb we did create the 'occupied slot' feature and that really made things feel more 'real' I have 11261 "Devices". I would say over 3/4 of them are not traditional "devices". I have some devices which are simply a front and a rear-port to represent a wall/ceiling termination. You can model any items using Devices. As mentioned, you don't need to give these devices names and the bare minimum of information is all that is required. > It is not a device, just a panel that lies en mass in the datacenter and don't need lifecycle, monitoring, ticketing, ... A panel is still a [device ](https://www.merriam-webster.com/dictionary/device) (Definition: "a piece of equipment or a mechanism designed to serve a special purpose or perform a special function"), just not a device that has any interfaces. > Maybe we should get back to another FR, and that is too hide devices from the default view (like 'out of production'). Then those panels can still be a device, but will not show up in a simple search, only when a specific status is selected... There are a number of filters you can already employ to remove these from view
adam commented 2025-12-29 20:19:16 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Oct 12, 2022):

Having no need for a name of a device is indeed a + for not investing time in my proposal..
So I'll pass the word and get going with unnamed brushpannels..

What filters do you mean? Can i set default filters for device views for all users?

@PieterL75 commented on GitHub (Oct 12, 2022): Having no need for a name of a device is indeed a + for not investing time in my proposal.. So I'll pass the word and get going with unnamed brushpannels.. What filters do you mean? Can i set default filters for device views for all users?
adam commented 2025-12-29 20:19:17 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 13, 2022):

@PieterL75 You can probably write a script to handle some of the trivial stuff. Might make things easier (like, have a script where you just type in the type and the rack "U's". Have it populate everything else needed.)

@DanSheps commented on GitHub (Oct 13, 2022): @PieterL75 You can probably write a script to handle some of the trivial stuff. Might make things easier (like, have a script where you just type in the type and the rack "U's". Have it populate everything else needed.)
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#7098
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?