Back-reflection on devices when custom fields' values are changed #8220

New Issue

adam · 2025-12-29T20:33:57+01:00

adam commented

2025-12-29 20:33:57 +01:00

Originally created by @laimaretto on GitHub (Jun 21, 2023).

NetBox version

docker version 3.5.3

Feature type

Change to existing functionality

Proposed functionality

The custom fields (CF) allow to add new attributes say to devices or interfaces, just to mention some. So when you create a device, you have that CF available to document whatever you need to.

However if for some reason you need to change or update the values of your CF at a definition level, you can do so, but that is not back-reflected at the device (or interface) that was using that CF in particular.

It gets worse if, for example, the CF is of the kind "multiple selection" or "selection". Changing the list of options (or updating just one of the options) means the you need to go back to the device to update the CF's value.

For example, you want to document a BGP community. If at some point in time that community changes, you not only need to update the CF at a system level in your netbox setup, but you also need to go to each and every router to update the value.

Use case

Well, if you have hundreds/thousands of devices with a CF, and a CF with hundreds of options (which is actually a real case), you should be able to modify only the proper value of the CF at its definition: then that change should be back-reflected to the device using not only the proper proper CF, but also the specific option of it. The rest of the options of the CF and the devices using it, should not be changed or modified at all.

Database changes

I don't really know what should be changed at a database level. But, for example, if the options are stored as a list that could be changed to a dictionary. And then the CF's values are the items of that dictionary.

As such, when one needs to modify an option of the CF, the modification is performed on the value of the dictionary, but the key remains the same. Hence the device using that CF will have the same key, and the value will be updated accordingly.

For example, I'm showing you an example of how this could be implemented.

-	Name	Content types	Label	Type	Required	Choices
Before	BGP_LU	dcim.device	BGP-LU	Selection	True	['option1', 'option2']
After	BGP_LU	dcim.device	BGP-LU	Selection	True	{key1:'option1', key2:'option2'}

I mean, you already support the Type JSON. Probably allowing to input a dictionary that at the momento of the definition of the CF would be enough. The problem will be then linking the ContentType to the proper key of the dictionary and show the proper dict[key] as the value at the device's view.

External dependencies

No response

Originally created by @laimaretto on GitHub (Jun 21, 2023). ### NetBox version docker version 3.5.3 ### Feature type Change to existing functionality ### Proposed functionality The custom fields (CF) allow to add new attributes say to devices or interfaces, just to mention some. So when you create a device, you have that CF available to document whatever you need to. However if for some reason you need to change or update the values of your CF at a definition level, you can do so, but that is not back-reflected at the device (or interface) that was using that CF in particular. It gets worse if, for example, the CF is of the kind "multiple selection" or "selection". Changing the list of options (or updating just one of the options) means the you need to go back to the device to update the CF's value. For example, you want to document a BGP community. If at some point in time that community changes, you not only need to update the CF at a system level in your netbox setup, but you also need to go to each and every router to update the value. ### Use case Well, if you have hundreds/thousands of devices with a CF, and a CF with hundreds of options (which is actually a real case), you should be able to modify only the proper value of the CF at its definition: then that change should be back-reflected to the device using not only the proper proper CF, but also the specific option of it. The rest of the options of the CF and the devices using it, should not be changed or modified at all. ### Database changes I don't really know what should be changed at a database level. But, for example, if the options are stored as a `list` that could be changed to a dictionary. And then the CF's values are the items of that dictionary. As such, when one needs to modify an option of the CF, the modification is performed on the value of the dictionary, but the key remains the same. Hence the device using that CF will have the same key, and the value will be updated accordingly. For example, I'm showing you an example of how this could be implemented. -|Name|Content types|Label|Type|Required|Choices --|--------|--------------------|-------|---------|-------------|---------- Before|BGP_LU|dcim.device|BGP-LU|Selection|True|['option1', 'option2'] After|BGP_LU|dcim.device|BGP-LU|Selection|True|{key1:'option1', key2:'option2'} I mean, you already support the Type JSON. Probably allowing to input a dictionary that at the momento of the definition of the CF would be enough. The problem will be then linking the ContentType to the proper key of the dictionary and show the proper dict[key] as the value at the device's view. ### External dependencies _No response_

adam added the type: feature label 2025-12-29 20:33:57 +01:00

adam closed this issue

2025-12-29 20:33:57 +01:00

adam commented

2025-12-29 20:33:58 +01:00

@laimaretto commented on GitHub (Jun 21, 2023):

I'm closing this because I reopened it as a bug. I really think this should be treated as a bug and not as a feature improvement. The new issue is here.

@laimaretto commented on GitHub (Jun 21, 2023): I'm closing this because I reopened it as a bug. I really think this should be treated as a bug and not as a feature improvement. The new issue is [here](https://github.com/netbox-community/netbox/issues/12954).

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#8220