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

Make customfields multiselect choices related #7766

New Issue
Closed
opened 2025-12-29 20:27:57 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:27:57 +01:00
Owner
Copy Link

Originally created by @zacho112 on GitHub (Mar 16, 2023).

NetBox version

v3.4.6

Feature type

Change to existing functionality

Proposed functionality

Currently when using the multi-select options in custom-fields, choice options aren't related when first set. Then means you have to build tools outside Netbox to keep values up-to-date.

This is the case for the implementation in eg Nautobot , you can check their demo site out.

Use case

Making multi-select usable and manageable.

Database changes

No response

External dependencies

No response

Originally created by @zacho112 on GitHub (Mar 16, 2023). ### NetBox version v3.4.6 ### Feature type Change to existing functionality ### Proposed functionality Currently when using the multi-select options in custom-fields, choice options aren't related when first set. Then means you have to build tools outside Netbox to keep values up-to-date. This is the case for the implementation in eg Nautobot , you can check their demo site out. ### Use case Making multi-select usable and manageable. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:27:57 +01:00
adam closed this issue 2025-12-29 20:27:57 +01:00
adam commented 2025-12-29 20:27:58 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 16, 2023):

Multi-select custom fields are intended to store static values for efficiency. To track related objects, please use the custom object field type.

@jeremystretch commented on GitHub (Mar 16, 2023): Multi-select custom fields are intended to store static values for efficiency. To track related objects, please use the [custom object field](https://docs.netbox.dev/en/stable/customization/custom-fields/#custom-object-fields) type.
adam commented 2025-12-29 20:27:58 +01:00
Author
Owner
Copy Link

@zacho112 commented on GitHub (Mar 16, 2023):

Thanks for the quick reply. But I have a followup question, we have use cases for using custom objects in custom fields. This could eg. be to define interface roles, used in our automation. Currently the best solution is to add tags to the interface named with a key:value.

Fx: Tag: "inteface_role:whatever".

I really hate this idea, because it's ugly, and there's no way for our users to figure out the purpose of these tags. But it get the job done.

We could also add multi-select with objects, and use the tags here, but again, it's not nice either, but it provide more logic for the humans working within Netbox what the purpose of the tag is.

We need this kind of functionality in various places to add extra options used in automation on our objects.

@zacho112 commented on GitHub (Mar 16, 2023): Thanks for the quick reply. But I have a followup question, we have use cases for using custom objects in custom fields. This could eg. be to define interface roles, used in our automation. Currently the best solution is to add tags to the interface named with a key:value. Fx: Tag: "inteface_role:whatever". I really hate this idea, because it's ugly, and there's no way for our users to figure out the purpose of these tags. But it get the job done. We could also add multi-select with objects, and use the tags here, but again, it's not nice either, but it provide more logic for the humans working within Netbox what the purpose of the tag is. We need this kind of functionality in various places to add extra options used in automation on our objects.
adam commented 2025-12-29 20:27:58 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 16, 2023):

The limitation you're hitting is the need to extend the data model beyond the relationships that already exist. This is usually a sign that it's necessary to either extend the core data model, or introduce a new model via a plugin. (Introducing a model solely to hold choices would be a poor design choice, as it would impose significant performance overhead while delivering very limited value: A choice's attribute would be limited to a single value.)

For your specific use case, I'd argue that it would justify a feature request to introduce an interface role model in NetBox core, as this seems to be a fairly common need. Alternatively, you could write a plugin to introduce your own custom model with whatever additional attributes you may need.

@jeremystretch commented on GitHub (Mar 16, 2023): The limitation you're hitting is the need to extend the data model beyond the relationships that already exist. This is usually a sign that it's necessary to either extend the core data model, or introduce a new model via a plugin. (Introducing a model solely to hold choices would be a poor design choice, as it would impose significant performance overhead while delivering very limited value: A choice's attribute would be limited to a single value.) For your specific use case, I'd argue that it would justify a feature request to introduce an interface role model in NetBox core, as this seems to be a fairly common need. Alternatively, you could write a plugin to introduce your own custom model with whatever additional attributes you may need.
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#7766
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?