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

Shared picklists for custom fields #1334

New Issue
Closed
opened 2025-12-29 16:31:33 +01:00 by adam · 2 comments
adam commented 2025-12-29 16:31:33 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Oct 19, 2017).

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.2
  • NetBox version: 2.2.2

Description

Each custom field of type "Selection" has its own unique picklist of values. It would be very helpful if a picklist could be a separate entity, and multiple custom fields could refer to the same picklist.

Use case: we want both Device and VM to have the following custom fields:

  • Primary person responsible
  • Secondary person responsible

Currently this means having to enter and maintain four copies of the same picklist. (In fact we want more custom fields with assigned users, but that's enough for example purposes)

By re-using the same picklist, it would also use the same values, which could make some SQL queries simpler. At the moment the custom field serialized values are different depending on which field it came from.

netbox=# select * from extras_customfieldchoice where value='Brian';
 id | value | weight | field_id
----+-------+--------+----------
  2 | Brian |    100 |        1
  4 | Brian |    100 |        3
... etc

Proposed implementation:

  • extras_customfield gains a new value selection_id, only used when type is CF_TYPE_SELECT
  • extras_selection is a new table/object
    • data migration is simple: insert into extras_selection(id) (select id from extras_customfield where type=600). That is: each existing custom field of type CF_TYPE_SELECT becomes an instance of extras_selection with the same id.
    • TODO: bump the sequence nextval
  • rename extras_customfieldchoice to extras_selectionchoice
  • extras_selectionchoice links to selection_id instead of field_id
  • admin and main UI updates
Originally created by @candlerb on GitHub (Oct 19, 2017). ### Issue type [X] Feature request <!-- Requesting the implementation of a new feature --> [ ] Bug report <!-- Reporting unexpected or erroneous behavior --> [ ] Documentation <!-- Proposing a modification to the documentation --> ### Environment * Python version: 3.5.2 * NetBox version: 2.2.2 ### Description Each custom field of type "Selection" has its own unique picklist of values. It would be very helpful if a picklist could be a separate entity, and multiple custom fields could refer to the same picklist. Use case: we want both Device and VM to have the following custom fields: * Primary person responsible * Secondary person responsible Currently this means having to enter and maintain *four* copies of the same picklist. (In fact we want more custom fields with assigned users, but that's enough for example purposes) By re-using the same picklist, it would also use the same values, which could make some SQL queries simpler. At the moment the custom field serialized values are different depending on which field it came from. ~~~ netbox=# select * from extras_customfieldchoice where value='Brian'; id | value | weight | field_id ----+-------+--------+---------- 2 | Brian | 100 | 1 4 | Brian | 100 | 3 ... etc ~~~ Proposed implementation: * `extras_customfield` gains a new value `selection_id`, only used when `type` is `CF_TYPE_SELECT` * `extras_selection` is a new table/object * data migration is simple: `insert into extras_selection(id) (select id from extras_customfield where type=600)`. That is: each existing custom field of type `CF_TYPE_SELECT` becomes an instance of `extras_selection` with the same id. * TODO: bump the sequence nextval * rename `extras_customfieldchoice` to `extras_selectionchoice` * `extras_selectionchoice` links to `selection_id` instead of `field_id` * admin and main UI updates
adam closed this issue 2025-12-29 16:31:33 +01:00
adam commented 2025-12-29 16:31:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 19, 2017):

This would be extending custom fields beyond their intended use. The selection field is only meant to convey a set of static predefined values relevant to a single field (similar to device status). If you find yourself needing to reference the same set of values from multiple fields, it's a sign that you've outgrown custom fields and need to pursue a more robust solution.

For this particular use case, it seems like you'd be best off waiting for #988 or #132.

@jeremystretch commented on GitHub (Oct 19, 2017): This would be extending custom fields beyond their intended use. The selection field is only meant to convey a set of static predefined values relevant to a single field (similar to device status). If you find yourself needing to reference the same set of values from multiple fields, it's a sign that you've outgrown custom fields and need to pursue a more robust solution. For this particular use case, it seems like you'd be best off waiting for #988 or #132.
adam commented 2025-12-29 16:31:34 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Oct 19, 2017):

#988

A single "Owner" wouldn't cut it for me, because I need multiple "Owners". However it does suggest another idea which may be simpler to implement: a new CUSTOMFIELD_TYPE_CHOICES value of CF_TYPE_USER, where the field contains a user id.

#132

Multiple tags to a device/VM would probably do the job. I see this as an extension to 'Role', but allowing a device/VM to be associated with multiple Roles.

@candlerb commented on GitHub (Oct 19, 2017): > #988 A single "Owner" wouldn't cut it for me, because I need multiple "Owners". However it does suggest another idea which may be simpler to implement: a new `CUSTOMFIELD_TYPE_CHOICES` value of `CF_TYPE_USER`, where the field contains a user id. > #132 Multiple tags to a device/VM would probably do the job. I see this as an extension to 'Role', but allowing a device/VM to be associated with multiple Roles.
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#1334
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?