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

Add Face field for Device components #6424

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

Originally created by @sleepinggenius2 on GitHub (Apr 29, 2022).

NetBox version

v3.2.2

Feature type

Data model extension

Proposed functionality

Add a Face field like the Rack face field on Racks for Device components and templates. I was originally going to limit this to the Device Bay and Module Bay models and associated templates, but I think it would be really useful for all the device components. Unfortunately, this can't be properly done with a custom field unless #9243 is implemented. The same options that are used for Rack face, Front and Rear, would be sufficient for my immediate use case, but there might be some devices where Top, Bottom, Left, or Right would also be required. Additionally, it could be helpful to change the uniqueness constraint to be [face, name] for at least device and module bays. Having to still name things like Slot 1 (Front) and Slot 1 (Rear) seems like it would be redundant and potentially error prone. I have seen some devices with a midplane that use the same slot numbering on the front and rear.

Use case

When modeling device components, it would be really helpful to be able to specify the face on the device where that component is located. We have a number of devices where modules, interfaces, and ports are located on the front and rear of a device and we are currently doing something like Slot 1 (Rear) to indicate physically where a given module bay is located, for example. Having a standard way to apply this to not just bays, but also interfaces and ports would be very helpful when interfacing with field technicians. I know there are currently front and rear images that can be set on a device type, but it's not always practical to add those images for all device types or produce them at a high enough resolution where text can be read clearly.

This may seem a little redundant for the Front and Rear port models, but would actually be especially useful there, as I often find scenarios where those models need to be used in a particular way because of how the rear and front port models work (one to many breakout) and not because a given port is actually on the front or rear of a device.

Database changes

Add a Face field to the Device component models and templates. Possibly change the uniqueness constraint on at least device and module bays to be [face, name].

External dependencies

None

Originally created by @sleepinggenius2 on GitHub (Apr 29, 2022). ### NetBox version v3.2.2 ### Feature type Data model extension ### Proposed functionality Add a *Face* field like the *Rack face* field on *Racks* for *Device* components and templates. I was originally going to limit this to the *Device Bay* and *Module Bay* models and associated templates, but I think it would be really useful for all the device components. Unfortunately, this can't be properly done with a custom field unless #9243 is implemented. The same options that are used for *Rack face*, Front and Rear, would be sufficient for my immediate use case, but there might be some devices where Top, Bottom, Left, or Right would also be required. Additionally, it could be helpful to change the uniqueness constraint to be [face, name] for at least device and module bays. Having to still name things like *Slot 1 (Front)* and *Slot 1 (Rear)* seems like it would be redundant and potentially error prone. I have seen some devices with a midplane that use the same slot numbering on the front and rear. ### Use case When modeling device components, it would be really helpful to be able to specify the face on the device where that component is located. We have a number of devices where modules, interfaces, and ports are located on the front and rear of a device and we are currently doing something like *Slot 1 (Rear)* to indicate physically where a given module bay is located, for example. Having a standard way to apply this to not just bays, but also interfaces and ports would be very helpful when interfacing with field technicians. I know there are currently front and rear images that can be set on a device type, but it's not always practical to add those images for all device types or produce them at a high enough resolution where text can be read clearly. This may seem a little redundant for the Front and Rear port models, but would actually be especially useful there, as I often find scenarios where those models need to be used in a particular way because of how the rear and front port models work (one to many breakout) and not because a given port is actually on the front or rear of a device. ### Database changes Add a *Face* field to the *Device* component models and templates. Possibly change the uniqueness constraint on at least device and module bays to be [face, name]. ### External dependencies None
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:40:34 +01:00
adam closed this issue 2025-12-29 19:40:34 +01:00
adam commented 2025-12-29 19:40:34 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 11, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jul 11, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:40:35 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 11, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Aug 11, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: under review 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#6424
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?