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

Rack (inner) depth #6713

New Issue
Closed
opened 2025-12-29 19:44:23 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:44:23 +01:00
Owner
Copy Link

Originally created by @sieuwe on GitHub (Jul 25, 2022).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.2.7

Feature type

Data model extension

Proposed functionality

Currently we have a width and height option for inner sizing of a rack.
And the outer width and outer depth is also available.
What we are missing is the possibility to add the inner depth.

Use case

There are different inner depths possible.
Some hardware only fits from a certain depth.

Database changes

Depth field needs to be added

External dependencies

No response

Originally created by @sieuwe on GitHub (Jul 25, 2022). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.2.7 ### Feature type Data model extension ### Proposed functionality Currently we have a width and height option for inner sizing of a rack. And the outer width and outer depth is also available. What we are missing is the possibility to add the inner depth. ### Use case There are different inner depths possible. Some hardware only fits from a certain depth. ### Database changes Depth field needs to be added ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:44:23 +01:00
adam closed this issue 2025-12-29 19:44:23 +01:00
adam commented 2025-12-29 19:44:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 25, 2022):

This is a good idea, but your FR needs much more detail.

  • What field(s) are you proposing be added to the rack model?
  • Do we want to allow specifying the measurement unit as we do for the outer depth?
  • Should the use of this field be limited by rack type?
@jeremystretch commented on GitHub (Jul 25, 2022): This is a good idea, but your FR needs much more detail. * What field(s) are you proposing be added to the rack model? * Do we want to allow specifying the measurement unit as we do for the outer depth? * Should the use of this field be limited by rack type?
adam commented 2025-12-29 19:44:24 +01:00
Author
Owner
Copy Link

@sieuwe commented on GitHub (Jul 25, 2022):

  • What field(s) are you proposing be added to the rack model?
    I'd suggest using 'inner depth' since that would clarify the use and make it not confusing when using depth and outer depth.
  • Do we want to allow specifying the measurement unit as we do for the outer depth?
    The same measurement unit could apply as for the outer depth.
  • Should the use of this field be limited by rack type?
    This applies to al rack types.
@sieuwe commented on GitHub (Jul 25, 2022): - What field(s) are you proposing be added to the rack model? I'd suggest using 'inner depth' since that would clarify the use and make it not confusing when using depth and outer depth. - Do we want to allow specifying the measurement unit as we do for the outer depth? The same measurement unit could apply as for the outer depth. - Should the use of this field be limited by rack type? This applies to al rack types.
adam commented 2025-12-29 19:44:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 26, 2022):

This applies to al rack types.

What about a freestanding two-post frame?

@jeremystretch commented on GitHub (Jul 26, 2022): > This applies to al rack types. What about a freestanding two-post frame?
adam commented 2025-12-29 19:44:25 +01:00
Author
Owner
Copy Link

@sieuwe commented on GitHub (Jul 27, 2022):

What about a freestanding two-post frame?

Overlooked that one. That shouldn't have an inner dimension, all the other types should have one.

@sieuwe commented on GitHub (Jul 27, 2022): > What about a freestanding two-post frame? Overlooked that one. That shouldn't have an inner dimension, all the other types should have one.
adam commented 2025-12-29 19:44:25 +01:00
Author
Owner
Copy Link

@gellis713 commented on GitHub (Aug 11, 2022):

This applies to al rack types.

What about a freestanding two-post frame?

I've worked in many broom closets that have limited space behind the two-post frame (a wall). Inner depth could be relevant still and may simplify the model. (I don't suppose it's truly any different than an outer depth in this case but some people may want to standardize checking against equipment depth on one field.)

I've made the necessary additions needed to submit a pull request assuming it is OK to have a dedicated "inner_unit" field. Otherwise we'll need to potentially complicate UI design and checks on whether fields are defined (which is fine will just need more careful planning)

@gellis713 commented on GitHub (Aug 11, 2022): > > This applies to al rack types. > > What about a freestanding two-post frame? I've worked in many broom closets that have limited space behind the two-post frame (a wall). Inner depth could be relevant still and may simplify the model. (I don't suppose it's truly any different than an outer depth in this case but some people may want to standardize checking against equipment depth on one field.) I've made the necessary additions needed to submit a pull request assuming it is OK to have a dedicated "inner_unit" field. Otherwise we'll need to potentially complicate UI design and checks on whether fields are defined (which is fine will just need more careful planning)
adam commented 2025-12-29 19:44:25 +01:00
Author
Owner
Copy Link

@AnythingOverIP commented on GitHub (Aug 23, 2022):

Inner depth as in rail-to-rail distance or door-to-door? I would personally like to have rail-to-rail tracked, and maybe even have a min/max rail depth added to the device types. We currently document that through custom properties, but did not script any validation yet...

Some manufacturers have that information documented ( https://i.dell.com/sites/csdocuments/Business_solutions_engineering-Docs_Documents/en/rail-rack-matrix.pdf ) and we rely on that as we have hundreds of sites across the country with no unique rack model...

Having all that information added would be a plus, and that would also help to revisit https://github.com/netbox-community/netbox/issues/1627 ?

@AnythingOverIP commented on GitHub (Aug 23, 2022): Inner depth as in rail-to-rail distance or door-to-door? I would personally like to have rail-to-rail tracked, and maybe even have a min/max rail depth added to the device types. We currently document that through custom properties, but did not script any validation yet... Some manufacturers have that information documented ( https://i.dell.com/sites/csdocuments/Business_solutions_engineering-Docs_Documents/en/rail-rack-matrix.pdf ) and we rely on that as we have hundreds of sites across the country with no unique rack model... Having all that information added would be a plus, and that would also help to revisit https://github.com/netbox-community/netbox/issues/1627 ?
adam commented 2025-12-29 19:44:26 +01:00
Author
Owner
Copy Link

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

Inner depth as in rail-to-rail distance or door-to-door?

Rail-to-rail

Having all that information added would be a plus, and that would also help to revisit #1627?

Possibly, but it would be best to submit a new FR after this one has been implemented.

@jeremystretch commented on GitHub (Oct 19, 2022): > Inner depth as in rail-to-rail distance or door-to-door? Rail-to-rail > Having all that information added would be a plus, and that would also help to revisit #1627? Possibly, but it would be best to submit a new FR after this one has been implemented.
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 status: accepted 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#6713
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?