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

[laimaretto]

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

[laimaretto]

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.