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

Unify status options #2787

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

Originally created by @Bitsky on GitHub (Aug 6, 2019).

Environment

  • Python version: 2.7.5
  • NetBox version: 2.6.1

Proposed Functionality

It looks like the Status dropdown has a wide range of varying options. Wouldn't it make sense to have them unified so every dropdown list has the same options?

Here are a few:

  • Powerfeed: Active, Offline, Planned, Failed
  • Device: Active, Offline, Planned, Staged, Failed, Inventory, Decommissioning
  • Rack: Active, Planned, Reserved, Available, Deprecated
  • Circuit: Planned, Provisioning, Active, Offline, Deprovisioning, Decommissioned
  • Virtual Machine: Active, Offline, Staged
  • Cluster: (no status)
  • Cable: Planned, Connected

I noticed because I wanted to set a powerfeed to Reserved. It would make sense to merge all them into a single list only which is sorted by "on/off".

Use Case

Having a streamlined status list would let users expect what they can set without checking different status dropdowns first. Racks can be reserved, Powerfeeds can't. Devices can be failed, Cabled can't. Clusters can't be anything.

Database Changes

A compiled and sorted list of current different Stati would be something like this:

Active
Inactive
Online
Offline
Connected
Disconnected
Available
Unavailable
Provisioning
Deprovisioning
Decommissioned
Deprecated
Planned
Staged
Reserved
Failed

External Dependencies

Originally created by @Bitsky on GitHub (Aug 6, 2019). ### Environment * Python version: 2.7.5 * NetBox version: 2.6.1 ### Proposed Functionality It looks like the Status dropdown has a wide range of varying options. Wouldn't it make sense to have them unified so every dropdown list has the same options? Here are a few: - Powerfeed: Active, Offline, Planned, Failed - Device: Active, Offline, Planned, Staged, Failed, Inventory, Decommissioning - Rack: Active, Planned, Reserved, Available, Deprecated - Circuit: Planned, Provisioning, Active, Offline, Deprovisioning, Decommissioned - Virtual Machine: Active, Offline, Staged - Cluster: (no status) - Cable: Planned, Connected I noticed because I wanted to set a powerfeed to Reserved. It would make sense to merge all them into a single list only which is sorted by "on/off". ### Use Case Having a streamlined status list would let users expect what they can set without checking different status dropdowns first. Racks can be reserved, Powerfeeds can't. Devices can be failed, Cabled can't. Clusters can't be anything. ### Database Changes A compiled and sorted list of current different Stati would be something like this: Active Inactive Online Offline Connected Disconnected Available Unavailable Provisioning Deprovisioning Decommissioned Deprecated Planned Staged Reserved Failed ### External Dependencies
adam closed this issue 2025-12-29 18:22:09 +01:00
adam commented 2025-12-29 18:22:10 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 6, 2019):

Wouldn't it make sense to have them unified so every dropdown list has the same options?

This approach was intentionally avoided, as many of the statuses do not make sense for every model (for example, an "offline" rack).

@jeremystretch commented on GitHub (Aug 6, 2019): > Wouldn't it make sense to have them unified so every dropdown list has the same options? This approach was intentionally avoided, as many of the statuses do not make sense for every model (for example, an "offline" rack).
adam commented 2025-12-29 18:22:10 +01:00
Author
Owner
Copy Link

@Bitsky commented on GitHub (Aug 7, 2019):

I beg to differ on that one, as it would give more flexibility to the users if it is their decision to make sense of a status. It's not really a huge change, but would widen the options a lot to cover more use-cases.

Like, you can have a bad CAT cable in a bonded network; it's not a huge drama because the bond will generally be set up to provide fault tolerance, but you would want to mark the cable as failed so next time you go to the location for maintenance you don't forget to replace it. Granted the NICs could be bad, but then you'd still want to replace the cable to check.

Or like in my case where I wanted to set a powerfeed to reserved.

@Bitsky commented on GitHub (Aug 7, 2019): I beg to differ on that one, as it would give more flexibility to the users if it is their decision to make sense of a status. It's not really a huge change, but would widen the options a lot to cover more use-cases. Like, you can have a bad CAT cable in a bonded network; it's not a huge drama because the bond will generally be set up to provide fault tolerance, but you would want to mark the cable as failed so next time you go to the location for maintenance you don't forget to replace it. Granted the NICs could be bad, but then you'd still want to replace the cable to check. Or like in my case where I wanted to set a powerfeed to reserved.
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
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#2787
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?