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

Extend rack coordinate labelling system to include non-numeric rack coordinates #9864

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

Originally created by @pv2b on GitHub (Jun 18, 2024).

NetBox version

v4.0.5

Feature type

New functionality

Proposed functionality

I propose extending the current system for showing rack coordinates to support non-standard rack labels in general, for rack unit labeling systems that aren't as simple as 1-48.

Specifically, I propose adding a new "Rack Unit Numbering System" data type that contains a mapping between unit numbers and label strings. For example, this mapping numbering system could be specified by a user:

Position Label
1 01A
1.5 01A½
2 01B
2.5 01B½
3 01C
3.5 01C½
4 01D
4.5 01D½
5 11A
5.5 11A½
6 11B
6.5 11B½
7 11C
7.5 11C½
8 11D
8.5 11D½
9 21A
9.5 21A½
10 21B
10.5 21B½
11 21C
11.5 21C½
12 21D
12.5 21D½
13 31A
13.5 31A½
14 31B
14.5 31B½
15 31C
15.5 31C½
16 31D
16.5 31D½

(Etc.)

It might also be useful to allow the use the same code as when generating multiple interface names here to support common cases, for example, the ones above could have been expressed as "[0-3]1[A-D][,½]", but it probably wise not to restrict the user to those types of ranges.

A field would be added to the "Rack" class, allowing a custom numbering system to be used. This would affect displaying of rack coordinates in the following places:

  • Rack diagrams
  • Position selection and indication on the device views

Optionally, the API could be extended with a new calculated field for "position label" or similar, leaving the existing numeric positions untouched, in order to not break any existing API usage.

Use case

One very common system for labelling rack positions here in Sweden is to label rack positions as, from top to bottom like:

01A
01B
01C
01D
11A
11B
11C
11D
21A
21B
21C
21D

Etc.

You'll literally find this numbering system everywhere here in Sweden, every distribution frame I've ever been to has been labeled this way.

I'll spare you the history lesson for why exactly this came about, because it's not that interesting in the context of Netbox, but suffice to say this system started out back in the bad old days of POTS telephony and has stuck around for use in distribution frames.

It would be useful to be able to use this numbering system in Netbox, somehow! Personally I'd be happy if it's just visible in the GUI, adding it to the API would not be worth it to me.

This probably couldn't be a plugin, because you'd need to be able to reach in and change the current places where rack positions are displayed, both in any drop-downs and display fields on a device, as well as on the rack diagram labels.

Database changes

A new "rack numbering type" model would need to be added.

The rack model would need to be extended to add a field for "numbering system", referring to an instance of said model. The field is nullable, and a null field implies to just use the numbers directly, as per the existing implementaiton.

External dependencies

None.

Originally created by @pv2b on GitHub (Jun 18, 2024). ### NetBox version v4.0.5 ### Feature type New functionality ### Proposed functionality I propose extending the current system for showing rack coordinates to support non-standard rack labels in general, for rack unit labeling systems that aren't as simple as 1-48. Specifically, I propose adding a new "Rack Unit Numbering System" data type that contains a mapping between unit numbers and label strings. For example, this mapping numbering system could be specified by a user: | Position | Label | | --- | --- | | 1 | 01A | | 1.5 | 01A½ | | 2 | 01B | | 2.5 | 01B½ | | 3 | 01C | | 3.5 | 01C½ | | 4 | 01D | | 4.5 | 01D½ | | 5 | 11A | | 5.5 | 11A½ | | 6 | 11B | | 6.5 | 11B½ | | 7 | 11C | | 7.5 | 11C½ | | 8 | 11D | | 8.5 | 11D½ | | 9 | 21A | | 9.5 | 21A½ | | 10 | 21B | | 10.5 | 21B½ | | 11 | 21C | | 11.5 | 21C½ | | 12 | 21D | | 12.5 | 21D½ | | 13 | 31A | | 13.5 | 31A½ | | 14 | 31B | | 14.5 | 31B½ | | 15 | 31C | | 15.5 | 31C½ | | 16 | 31D | | 16.5 | 31D½ | (Etc.) It might also be useful to allow the use the same code as when generating multiple interface names here to support common cases, for example, the ones above could have been expressed as "[0-3]1[A-D][,½]", but it probably wise not to restrict the user to those types of ranges. A field would be added to the "Rack" class, allowing a custom numbering system to be used. This would affect displaying of rack coordinates in the following places: - Rack diagrams - Position selection and indication on the device views Optionally, the API could be extended with a new calculated field for "position label" or similar, leaving the existing numeric positions untouched, in order to not break any existing API usage. ### Use case One very common system for labelling rack positions here in Sweden is to label rack positions as, from top to bottom like: 01A 01B 01C 01D 11A 11B 11C 11D 21A 21B 21C 21D Etc. You'll literally find this numbering system everywhere here in Sweden, every distribution frame I've ever been to has been labeled this way. I'll spare you the history lesson for why exactly this came about, because it's not that interesting in the context of Netbox, but suffice to say this system started out back in the bad old days of POTS telephony and has stuck around for use in distribution frames. It would be useful to be able to use this numbering system in Netbox, somehow! Personally I'd be happy if it's just visible in the GUI, adding it to the API would not be worth it to me. This probably couldn't be a plugin, because you'd need to be able to reach in and change the current places where rack positions are displayed, both in any drop-downs and display fields on a device, as well as on the rack diagram labels. ### Database changes A new "rack numbering type" model would need to be added. The rack model would need to be extended to add a field for "numbering system", referring to an instance of said model. The field is nullable, and a null field implies to just use the numbers directly, as per the existing implementaiton. ### External dependencies None.
adam added the type: feature label 2025-12-29 21:23:42 +01:00
adam closed this issue 2025-12-29 21:23:42 +01:00
adam commented 2025-12-29 21:23:43 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jun 20, 2024):

Thanks for the good quality feature description and use case. Moving along to the feature backlog, which is not a promise of implementation. If this numbering scheme is indeed as Swedish as räkost in a tube, I assume we'll hear from other users in the form of 👍 reacts on the issue body.

@jeffgdotorg commented on GitHub (Jun 20, 2024): Thanks for the good quality feature description and use case. Moving along to the feature backlog, which is not a promise of implementation. If this numbering scheme is indeed as Swedish as räkost in a tube, I assume we'll hear from other users in the form of 👍 reacts on the issue body.
adam commented 2025-12-29 21:23:44 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 3, 2024):

I like this idea. I'd like to offer another use case as well.
Currently, devices can either be racked, or non-racked but associated with the rack. (PDU's, etc.)

But it would be great to be able to define a position for these unracked devices. For instance, if I had (2) PDU's in the rear of the rack, it would be nice to be able to mark PDU(a) on the "left" side of the rack, and PDU(b) on the "right" side of the rack. Often times these vertical PDU's are referred to as "Zero-U". So the ability to capture where exactly in the rack these devices are would be handy.

You might also have both PDU(a) and PDU(b) on the right side, but you might have an extra deep rack. In which case, the PDU's might be Right(1) and Right(2), or something like that.

@ghost commented on GitHub (Aug 3, 2024): I like this idea. I'd like to offer another use case as well. Currently, devices can either be racked, or non-racked but associated with the rack. (PDU's, etc.) But it would be great to be able to define a position for these unracked devices. For instance, if I had (2) PDU's in the rear of the rack, it would be nice to be able to mark PDU(a) on the "left" side of the rack, and PDU(b) on the "right" side of the rack. Often times these vertical PDU's are referred to as "Zero-U". So the ability to capture where exactly in the rack these devices are would be handy. You might also have both PDU(a) and PDU(b) on the right side, but you might have an extra deep rack. In which case, the PDU's might be Right(1) and Right(2), or something like that.
adam commented 2025-12-29 21:23:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 5, 2024):

Sorry, but this is not something we can accommodate in NetBox: rack units must be numeric. If you need to track alphanumeric labels for rack units, you'll need to fork NetBox and implement a custom mechanism for doing so.

@jeremystretch commented on GitHub (Aug 5, 2024): Sorry, but this is not something we can accommodate in NetBox: rack units must be numeric. If you need to track alphanumeric labels for rack units, you'll need to fork NetBox and implement a custom mechanism for doing so.
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#9864
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?