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 set None for Height (U) field in device type creation/update #4943

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

Originally created by @msuksong on GitHub (May 25, 2021).

NetBox version

v2.11.3

Feature type

Change to existing functionality

Proposed functionality

Allow to set None(empty) in the height field in device type creation/update.

Use case

There are device types that are not rack mountable or not designed for rack mount. This type of device is not necessary to have height(U) value. ex) Desktop PC, Monitor, CRAC, ...

Database changes

Allow height field to be null.

External dependencies

None

Originally created by @msuksong on GitHub (May 25, 2021). ### NetBox version v2.11.3 ### Feature type Change to existing functionality ### Proposed functionality Allow to set None(empty) in the height field in device type creation/update. ### Use case There are device types that are not rack mountable or not designed for rack mount. This type of device is not necessary to have height(U) value. ex) Desktop PC, Monitor, CRAC, ... ### Database changes Allow height field to be null. ### External dependencies None
adam added the type: feature label 2025-12-29 19:22:29 +01:00
adam closed this issue 2025-12-29 19:22:29 +01:00
adam commented 2025-12-29 19:22:29 +01:00
Author
Owner
Copy Link

@TheNetworkGuy commented on GitHub (May 25, 2021):

You can add non-racked devices already in Netbox. Sounds like this is what you are looking for?

@TheNetworkGuy commented on GitHub (May 25, 2021): You can add non-racked devices already in Netbox. Sounds like this is what you are looking for?
adam commented 2025-12-29 19:22:29 +01:00
Author
Owner
Copy Link

@msuksong commented on GitHub (May 25, 2021):

Setting height to zero or other value (default is 1 when a device type is created) can mislead the device type is rack mountable. So having none value(as default) can help the device type is not rack mountable explicitly.

I'm testing a report for device types with height value - if a device type has non-zero height value, its instances must be placed in a rack.

@msuksong commented on GitHub (May 25, 2021): Setting height to zero or other value (default is 1 when a device type is created) can mislead the device type is rack mountable. So having none value(as default) can help the device type is not rack mountable explicitly. I'm testing a report for device types with height value - if a device type has non-zero height value, its instances must be placed in a rack.
adam commented 2025-12-29 19:22:30 +01:00
Author
Owner
Copy Link

@drmsoffall commented on GitHub (May 26, 2021):

This functionality (including preventing a device from being racked) already exists when height is set to 0. It sounds like this is just a request for change in convention, not functionality? What would be the functional difference between height=0 and height=None?

@drmsoffall commented on GitHub (May 26, 2021): This functionality (including preventing a device from being racked) already exists when height is set to 0. It sounds like this is just a request for change in convention, not functionality? What would be the functional difference between height=0 and height=None?
adam commented 2025-12-29 19:22:30 +01:00
Author
Owner
Copy Link

@msuksong commented on GitHub (May 26, 2021):

Because there is no RU height=0 devices in real world (allowing the value 0 for height is not a good modeling I think.)
I think it is an implementation tweak for non-rack mountable devices.

Netbox already enforces height should have an integer value greater than 0 in device type bulk update UI,
Screen Shot 2021-05-25 at 13 26 33
I believe the developer for this code also thought height=0 doesn't make sense.

@msuksong commented on GitHub (May 26, 2021): Because there is no RU height=0 devices in real world (allowing the value 0 for height is not a good modeling I think.) I think it is an implementation tweak for non-rack mountable devices. Netbox already enforces height should have an integer value greater than 0 in device type bulk update UI, <img width="559" alt="Screen Shot 2021-05-25 at 13 26 33" src="https://user-images.githubusercontent.com/9711776/119597514-2855b780-be1c-11eb-9dbf-c649569f1131.png"> I believe the developer for this code also thought height=0 doesn't make sense.
adam commented 2025-12-29 19:22:30 +01:00
Author
Owner
Copy Link

@drmsoffall commented on GitHub (May 27, 2021):

At the very least, that sounds like a bug (inconsistency) in the Device Type Bulk Edit form, whether or not the convention changes! Nice catch!

@drmsoffall commented on GitHub (May 27, 2021): At the very least, that sounds like a bug (inconsistency) in the Device Type Bulk Edit form, whether or not the convention changes! Nice catch!
adam commented 2025-12-29 19:22:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 28, 2021):

Netbox already enforces height should have an integer value greater than 0 in device type bulk update UI,

This looks like a bug in the bulk edit feature. A U height of zero is perfectly valid and supported to indicate that the device does not consume quantified rack space. A null value in this field would imply that the value is unknown, which wouldn't make sense.

I'm going to close this issue, but I encourage you to open a separate bug report for the bulk edit bug.

@jeremystretch commented on GitHub (May 28, 2021): > Netbox already enforces height should have an integer value greater than 0 in device type bulk update UI, This looks like a bug in the bulk edit feature. A U height of zero is perfectly valid and supported to indicate that the device does not consume quantified rack space. A null value in this field would imply that the value is unknown, which wouldn't make sense. I'm going to close this issue, but I encourage you to open a separate bug report for the bulk edit bug.
adam commented 2025-12-29 19:22:30 +01:00
Author
Owner
Copy Link

@msuksong commented on GitHub (May 29, 2021):

I don't think null always implies unknown. Sometimes it is used for fields not related to an object.
For example, LAG field in the interface can be null(None). And I think it means the interface is not a LAG member(not related to any LAG interface). Does it mean the LAG member state is unknown?

Also a null value is totally valid if the value is unknown yet. I don't always know the RU height when I create a new device type. I would like to update it later after I get that info instead of putting the wrong value 1(current default value) or 0 in the first place.

@msuksong commented on GitHub (May 29, 2021): I don't think null always implies unknown. Sometimes it is used for fields not related to an object. For example, LAG field in the interface can be null(None). And I think it means the interface is not a LAG member(not related to any LAG interface). Does it mean the LAG member state is unknown? Also a null value is totally valid if the value is unknown yet. I don't always know the RU height when I create a new device type. I would like to update it later after I get that info instead of putting the wrong value 1(current default value) or 0 in the first place.
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#4943
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?