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

Value identification for custom field Selection #4521

New Issue
Closed
opened 2025-12-29 18:36:55 +01:00 by adam · 4 comments
adam commented 2025-12-29 18:36:55 +01:00
Owner
Copy Link

Originally created by @jakubkrysl on GitHub (Feb 1, 2021).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.10.3

Proposed Functionality

Please re-implement a way of differentiating values of custom field Selection. Discussed here: #5655
This is something that worked with 2.9 (v2.9.9 now) but got broken in v2.10 (tested with v2.10.3) (see the discussion or Use Case for more details)
The proposed solution is to have permanent value and customizable label for each choice in Selection.

Note: The current behaviour is considered a regression bug from our side.

Use Case

We have custom field named owner which we use to set business owner of most models. Let's assume only single one, IPAddresses as an example. This field is mandatory and for every IP there must be an owner set. The owner is mostly a team, string consisting of <team_name> <contact_mail> <manager>. If any of these change, we change it in admin view and this change gets propagated to every instance of IP with this owner. This is no longer the case, the old value does not get changed.

Also any scripting now works with ID, which would need to be changed to the value and the value too will have to be changed on every change in admin view.

Database Changes

If the new label/value gets stored in DB, than there will be a change to CustomField Selection.

External Dependencies

No external dependencies.

Originally created by @jakubkrysl on GitHub (Feb 1, 2021). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please start a discussion instead: https://github.com/netbox-community/netbox/discussions NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.8 * NetBox version: 2.10.3 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Please re-implement a way of differentiating values of custom field Selection. Discussed here: #5655 This is something that worked with 2.9 (v2.9.9 now) but got broken in v2.10 (tested with v2.10.3) (see the discussion or Use Case for more details) The proposed solution is to have permanent `value` and customizable `label` for each choice in Selection. Note: The current behaviour is considered a regression bug from our side. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case We have custom field named `owner` which we use to set business owner of most models. Let's assume only single one, IPAddresses as an example. This field is mandatory and for every IP there must be an owner set. The owner is mostly a team, string consisting of `<team_name> <contact_mail> <manager>`. If any of these change, we change it in admin view and this change gets propagated to every instance of IP with this owner. This is no longer the case, the old value does not get changed. Also any scripting now works with ID, which would need to be changed to the value and the value too will have to be changed on every change in admin view. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes If the new label/value gets stored in DB, than there will be a change to CustomField Selection. <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies No external dependencies.
adam closed this issue 2025-12-29 18:36:55 +01:00
adam commented 2025-12-29 18:36:56 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 1, 2021):

It sounds like this would be better suited for a plugin with a custom data model associated with it.

@DanSheps commented on GitHub (Feb 1, 2021): It sounds like this would be better suited for a plugin with a custom data model associated with it.
adam commented 2025-12-29 18:36:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 4, 2021):

The owner is mostly a team, string consisting of <team_name> <contact_mail> .

It looks like what you need, as @DanSheps hinted, is a separate model to store teams, which can then be referenced using a custom field. Trying to fit all this data into a single field is terribly redundant and should be considered an anti-pattern.

@jeremystretch commented on GitHub (Feb 4, 2021): > The owner is mostly a team, string consisting of <team_name> <contact_mail> <manager>. It looks like what you need, as @DanSheps hinted, is a separate model to store teams, which can then be referenced using a custom field. Trying to fit all this data into a single field is terribly redundant and should be considered an anti-pattern.
adam commented 2025-12-29 18:36:56 +01:00
Author
Owner
Copy Link

@jakubkrysl commented on GitHub (Feb 8, 2021):

The owner is mostly a team, string consisting of <team_name> <contact_mail> .

It looks like what you need, as @DanSheps hinted, is a separate model to store teams, which can then be referenced using a custom field. Trying to fit all this data into a single field is terribly redundant and should be considered an anti-pattern.

Yes, having new table of stake holders or owners table would actually work for this particular field. Though I don't think it is possible to create a new model to extend the core models by myself. I can create new table with plugin, but AFAIK somehow referencing this in the core model is not the best course of actions (understatement).

Also from my point of view this would solve only 1/6 of our custom fields issues since we are using 6 Selections, each of them is vulnerable to change and causing issues in data consistency as a result. Much better course of action would be to solve this for general use.

I can write a plugin to create new tables for each instance of this custom field type, but that would mean basically creating layer above netbox and have everything requiring those fields referencing that layer. Not only API, but UI too since our users are changing those choice fields themselves.

So to fix this in netbox, having custom field Selection (choice) behave as other choices seems like a smart and DRY thing to do.

Using utilities.choices.ChoiceSet for this seems like a good idea in line with the rest of the code base, where user input of [choice_1, choice_2] would get transfered to

custom_field_choice (
    (auto_ID_1, choice_1),
    (auto_ID_2, choice_2)
)

or let the user specify both and than there is no need to have extra serializer, just use the one there is for choice fields if base models.

Note: I agree it is not the best practise to have both name and email in single field, but is is safer than having 2 fields since users can change the owners themselves and sooner or later someone will change only 1 of those instead of both at once.

@jakubkrysl commented on GitHub (Feb 8, 2021): > > The owner is mostly a team, string consisting of <team_name> <contact_mail> . > > It looks like what you need, as @DanSheps hinted, is a separate model to store teams, which can then be referenced using a custom field. Trying to fit all this data into a single field is terribly redundant and should be considered an anti-pattern. Yes, having new table of `stake holders` or `owners` table would actually work for this particular field. Though I don't think it is possible to create a new model to extend the core models by myself. I can create new table with plugin, but AFAIK somehow referencing this in the core model is not the best course of actions (understatement). Also from my point of view this would solve only 1/6 of our custom fields issues since we are using 6 Selections, each of them is vulnerable to change and causing issues in data consistency as a result. Much better course of action would be to solve this for general use. I can write a plugin to create new tables for each instance of this custom field type, but that would mean basically creating layer above netbox and have everything requiring those fields referencing that layer. Not only API, but UI too since our users are changing those choice fields themselves. So to fix this in netbox, having custom field Selection (choice) behave as other choices seems like a smart and DRY thing to do. Using `utilities.choices.ChoiceSet` for this seems like a good idea in line with the rest of the code base, where user input of `[choice_1, choice_2]` would get transfered to ``` custom_field_choice ( (auto_ID_1, choice_1), (auto_ID_2, choice_2) ) ``` or let the user specify both and than there is no need to have extra serializer, just use the one there is for choice fields if base models. Note: I agree it is not the best practise to have both name and email in single field, but is is safer than having 2 fields since users can change the owners themselves and sooner or later someone will change only 1 of those instead of both at once.
adam commented 2025-12-29 18:36:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 8, 2021):

Using utilities.choices.ChoiceSet for this seems like a good idea

This doesn't make any sense. The ChoiceSet class is used for storing data in the executed code; what you need is a mechanism for storing custom, variable data in the database (i.e. a custom model). The only way to accomplish this is with a plugin.

I'm sorry, but the use case you've described exceeds the intended function of custom fields.

@jeremystretch commented on GitHub (Feb 8, 2021): > Using utilities.choices.ChoiceSet for this seems like a good idea This doesn't make any sense. The ChoiceSet class is used for storing data in the executed code; what you need is a mechanism for storing custom, variable data in the database (i.e. a custom model). The only way to accomplish this is with a plugin. I'm sorry, but the use case you've described exceeds the intended function of custom fields.
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#4521
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?