starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 22:03:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Configurable status choices for sites, prefixes, etc. #5766

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

Originally created by @jeremystretch on GitHub (Dec 13, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.1.1

Feature type

New functionality

Proposed functionality

Allow NetBox administrators to configure the list of available status choices for sites, devices, prefixes, etc. by defining a list of (value, label) tuples in the configuration. We could optionally include a third item to designate color, though more discussion is likely needed here to establish supported values. For example:

DEVICE_STATUS_CHOICES = (
    ('active', 'Active'),
    ('staged', 'Staged', 'cyan'),
    ('broken', 'Broken', 'red'),
)

This list of choices would replace the defaults provided by NetBox. Administrators would be able to add or remove values from this list at any time; it might also be possible to accommodate as part of NetBox's dynamic configuration. Where a status value is required, the first listed option will be used as the default.

However, we would need to address the scenario wherein a status value has been removed but it still applied to one or more objects in the database. In such case, I believe it is sufficient to return only the raw value (as no human-friendly label would be available), and prevent any modifications to an object with an invalid value until it has been corrected.

Use case

This would allow users to define their own custom status values for objects.

Database changes

No database changes should be necessary to implement this.

External dependencies

No response

Originally created by @jeremystretch on GitHub (Dec 13, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.1.1 ### Feature type New functionality ### Proposed functionality Allow NetBox administrators to configure the list of available status choices for sites, devices, prefixes, etc. by defining a list of (value, label) tuples in the configuration. We could optionally include a third item to designate color, though more discussion is likely needed here to establish supported values. For example: ```python DEVICE_STATUS_CHOICES = ( ('active', 'Active'), ('staged', 'Staged', 'cyan'), ('broken', 'Broken', 'red'), ) ``` This list of choices would replace the defaults provided by NetBox. Administrators would be able to add or remove values from this list at any time; it might also be possible to accommodate as part of NetBox's [dynamic configuration](https://netbox.readthedocs.io/en/stable/configuration/dynamic-settings/). Where a status value is required, the first listed option will be used as the default. However, we would need to address the scenario wherein a status value has been removed but it still applied to one or more objects in the database. In such case, I believe it is sufficient to return only the raw value (as no human-friendly label would be available), and prevent any modifications to an object with an invalid value until it has been corrected. ### Use case This would allow users to define their own custom status values for objects. ### Database changes No database changes should be necessary to implement this. ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:32:24 +01:00
adam closed this issue 2025-12-29 19:32:24 +01:00
adam commented 2025-12-29 19:32:24 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 13, 2021):

Overriding status options in Prefix might have implications where container is concerned.

Would it make more sense to instead of overriding allow appending to the status options instead and preserving the existing options we have baked into it?

Specifically for prefix, as an alternative, instead of having a container status have instead a "container" boolean checkbox. It adds another field but then doesn't pose a problem if the override route is chosen over appending. (I only bring this up as it would need to be done at the same time or as a blocker to this)

@DanSheps commented on GitHub (Dec 13, 2021): Overriding status options in Prefix might have implications where container is concerned. Would it make more sense to instead of overriding allow appending to the status options instead and preserving the existing options we have baked into it? Specifically for prefix, as an alternative, instead of having a container status have instead a "container" boolean checkbox. It adds another field but then doesn't pose a problem if the override route is chosen over appending. (I only bring this up as it would need to be done at the same time or as a blocker to this)
adam commented 2025-12-29 19:32:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 15, 2021):

Seems reasonable to allow users to extend the fields with their own choices while keeping the stock values intact. Prefix status is just one example where we rely on the presence of a stock value; cable status is another, and it's not difficult to imagine additional scenarios popping up in the future.

@jeremystretch commented on GitHub (Dec 15, 2021): Seems reasonable to allow users to extend the fields with their own choices while keeping the stock values intact. Prefix status is just one example where we rely on the presence of a stock value; cable status is another, and it's not difficult to imagine additional scenarios popping up in the future.
adam commented 2025-12-29 19:32:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 16, 2021):

I ended up just introducing a single configuration parameter to hold the choice mappings for all supported fields:

FIELD_CHOICES = {
    'dcim.Site.status': (
        ('exploded', 'Exploded', 'danger'),
        ('Custom', (
            ('foo', 'Foo', 'primary'),
            ('bar', 'Bar', 'info'),
            ('baz', 'Baz'),
        ))
    ),
}

These are populated on service start and appended to the stock choices.
Screenshot from 2021-12-16 10-42-27
Screenshot_2021-12-16 Sites NetBox

I've also opened #8089 to allow passing proper color names rather than BS5 CSS theme classes.

@jeremystretch commented on GitHub (Dec 16, 2021): I ended up just introducing a single configuration parameter to hold the choice mappings for all supported fields: ```python FIELD_CHOICES = { 'dcim.Site.status': ( ('exploded', 'Exploded', 'danger'), ('Custom', ( ('foo', 'Foo', 'primary'), ('bar', 'Bar', 'info'), ('baz', 'Baz'), )) ), } ``` These are populated on service start and appended to the stock choices. ![Screenshot from 2021-12-16 10-42-27](https://user-images.githubusercontent.com/13487278/146403098-1df5f2fb-1c73-4887-8124-9111b88a1710.png) ![Screenshot_2021-12-16 Sites NetBox](https://user-images.githubusercontent.com/13487278/146403112-bfccf896-4caf-4afb-aa26-24823c6fc1a6.png) I've also opened #8089 to allow passing proper color names rather than BS5 CSS theme classes.
adam commented 2025-12-29 19:32:25 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Dec 20, 2021):

@jeremystretch
Can you also add an option to 'hide' the default ones ?
The device statusses for example dont match with our namings. Just hiding them from the dropdown would suffice in my case.

FIELD_CHOICES = {
    'dcim.Site.status': (
        ('__hide__', (
            ('Inventory', 'Offline', 'Failed'),
        ),
        ('exploded', 'Exploded', 'danger'),
        ('Custom', (
            ('foo', 'Foo', 'primary'),
            ('bar', 'Bar', 'info'),
            ('baz', 'Baz'),
        ))
    ),
}
@PieterL75 commented on GitHub (Dec 20, 2021): @jeremystretch Can you also add an option to 'hide' the default ones ? The device statusses for example dont match with our namings. Just hiding them from the dropdown would suffice in my case. ``` FIELD_CHOICES = { 'dcim.Site.status': ( ('__hide__', ( ('Inventory', 'Offline', 'Failed'), ), ('exploded', 'Exploded', 'danger'), ('Custom', ( ('foo', 'Foo', 'primary'), ('bar', 'Bar', 'info'), ('baz', 'Baz'), )) ), } ```
adam commented 2025-12-29 19:32:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 20, 2021):

@PieterL75 please see my comment above.

@jeremystretch commented on GitHub (Dec 20, 2021): @PieterL75 please see my [comment](https://github.com/netbox-community/netbox/issues/8054#issuecomment-995165071) above.
adam commented 2025-12-29 19:32:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 3, 2022):

I did end up devising a solution to let users either replace or extend the stock choices. The following will replace the stock choices (leaving only three total choices):

FIELD_CHOICES = {
    'dcim.Site.status': (
        ('foo', 'Foo', 'red'),
        ('bar', 'Bar', 'green'),
        ('baz', 'Baz', 'blue'),
    )
}

Whereas adding a + to the end of the field identifier will instead extend the available choices:

FIELD_CHOICES = {
    'dcim.Site.status+': (
        ('foo', 'Foo', 'red'),
        ('bar', 'Bar', 'green'),
        ('baz', 'Baz', 'blue'),
    )
}
@jeremystretch commented on GitHub (Feb 3, 2022): I did end up devising a solution to let users either replace or extend the stock choices. The following will *replace* the stock choices (leaving only three total choices): ```python FIELD_CHOICES = { 'dcim.Site.status': ( ('foo', 'Foo', 'red'), ('bar', 'Bar', 'green'), ('baz', 'Baz', 'blue'), ) } ``` Whereas adding a `+` to the end of the field identifier will instead _extend_ the available choices: ```python FIELD_CHOICES = { 'dcim.Site.status+': ( ('foo', 'Foo', 'red'), ('bar', 'Bar', 'green'), ('baz', 'Baz', 'blue'), ) } ```
adam commented 2025-12-29 19:32:26 +01:00
Author
Owner
Copy Link

@opericgithub commented on GitHub (Apr 11, 2022):

what is the syntax for altering multiple fields?
if I use this syntax:

FIELD_CHOICES = {
    'dcim.Device.status+': (
        ('ok', 'OK', 'red'),
        ('magacin', 'Magacin', 'green'),
        ('neispravno', 'Neispravno', 'blue'),
    )
    'dcim.Site.status+': (
        ('prim', 'Primarni', 'green'),
        ('dr', 'DR', 'blue'),
    ) 
}

I end up with nginx message "502 Bad Gateway". When I use either of them it works fine.

@opericgithub commented on GitHub (Apr 11, 2022): what is the syntax for altering **multiple** fields? if I use this syntax: ``` FIELD_CHOICES = { 'dcim.Device.status+': ( ('ok', 'OK', 'red'), ('magacin', 'Magacin', 'green'), ('neispravno', 'Neispravno', 'blue'), ) 'dcim.Site.status+': ( ('prim', 'Primarni', 'green'), ('dr', 'DR', 'blue'), ) } ``` I end up with nginx message "502 Bad Gateway". When I use either of them it works fine.
adam commented 2025-12-29 19:32:26 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Apr 11, 2022):

You are missing a comma after the middle ).

@kkthxbye-code commented on GitHub (Apr 11, 2022): You are missing a comma after the middle ).
adam commented 2025-12-29 19:32:26 +01:00
Author
Owner
Copy Link

@hagbarddenstore commented on GitHub (Apr 11, 2022):

You need a “,” after the )

FIELD_CHOICES = {
‘dcim.Device.status+’: (
…
),
‘dcim.Site.status+’: (
…
),
}

Sent from my iPhone

On 11 Apr 2022, at 09:05, opericgithub @.***> wrote:


what is the syntax for altering multiple fields?
if I use this syntax:

FIELD_CHOICES = {
'dcim.Device.status+': (
('ok', 'OK', 'red'),
('magacin', 'Magacin', 'green'),
('neispravno', 'Neispravno', 'blue'),
)
'dcim.Site.status+': (
('prim', 'Primarni', 'green'),
('dr', 'DR', 'blue'),
)
}
I end up with nginx message "502 Bad Gateway". When I use either of them it works fine.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

@hagbarddenstore commented on GitHub (Apr 11, 2022): You need a “,” after the ) FIELD_CHOICES = { ‘dcim.Device.status+’: ( … ), ‘dcim.Site.status+’: ( … ), } Sent from my iPhone > On 11 Apr 2022, at 09:05, opericgithub ***@***.***> wrote: > >  > what is the syntax for altering multiple fields? > if I use this syntax: > > FIELD_CHOICES = { > 'dcim.Device.status+': ( > ('ok', 'OK', 'red'), > ('magacin', 'Magacin', 'green'), > ('neispravno', 'Neispravno', 'blue'), > ) > 'dcim.Site.status+': ( > ('prim', 'Primarni', 'green'), > ('dr', 'DR', 'blue'), > ) > } > I end up with nginx message "502 Bad Gateway". When I use either of them it works fine. > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you are subscribed to this thread.
adam commented 2025-12-29 19:32:27 +01:00
Author
Owner
Copy Link

@opericgithub commented on GitHub (Apr 11, 2022):

thanx!

@opericgithub commented on GitHub (Apr 11, 2022): thanx!
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#5766
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?