Update of custom field does not reflect the change on a device

[laimaretto]

NetBox version

docker version 3.5.3

Python version

3.10

Steps to Reproduce

1. create a custom field (CF) of type multiple selection. The content type can be DCIM > Devices. Add some choices to it using in the field Choices. For example, the options could be: a,b,c,d,e
2. Go to a device and assign a couple of the choices of the previously created CF. You should see the CF with the selected choices in the device's gui. For example, assign choices a and d.
3. Go back to the definition of the CF and change the value of a to a1.
4. Go back to the device. The CF still shows the choices a and d. You need to manually edit the CF to reflect the change.

Expected Behavior

Once changing the value of the options at the definition of the CF, that should be reflected in each and every content type that is using the CF.

This is particularly important if you have hundreds/thousands of devices using a particular CF, and a CF with hundreds of options (which is actually my real case scenario). One should be able to modify only a specific option of the CF at its definition: then that change should be back-reflected to the device. Otherwise one needs to go to each and every device to update the content of the CF.

Observed Behavior

When changing a specific value of the CF at the CF definition, that is not being reflected at the device.

[kkthxbye-code]

The custom field system was never designed to do this, so I'm having a hard time seeing it being a bug.

Go back to the definition of the CF and change the value of a to a1.

This doesn't really make sense as there are only keys basically. You can't change a to a1, you can remove a and add a new choice called a1, these are different choices.

I think the closest we could get to improve on the situation is to iterate the objects when a custom field has its choices changed and removing choices that are not valid anymore. Doesn't sound like what you want though.

[laimaretto]

Hi! Thanks for the reply. I understand now that this is not a bug but an expected behavior as per design. My bad ...

I think the closest we could get to improve on the situation is to iterate the objects when a custom field has its choices changed and removing choices that are not valid anymore. Doesn't sound like what you want though.

Well, that could be part of the solution. I mean, there are situations where you really need to update the values of the CF along the life of a network. And when you have tons of devices using a CF's choice, then if for some reason that choice changed, you need to (manually?) update the amount of devices that were using the specific choice.

Like in the example, say you have 1000 routers with a CF representing the list of NTP Servers. The choices are [IP1,IP2] . For some reason, IP1 changed to IP3. So now, at the definition level, the CF has chocies [IP3,IP2] . You should (1) identify all the 1000 devices using that CF's value IP1 and (2) update the CF's value to IP3. The choice IP2 should remain the same. That's just an example, there could be other scenarios ...

Probably one could use a dictionary instead of a list to store the different choices. So, CF's choices instead of being [IP1,IP2] could be {key1:IP1, key2:IP2}. Then the devices are linked to those keys and they show the proper values. But I'm talking with out knowing the technicalities of the design inside netbox, so not really sure if this is possible or not.

[a084ed22]

IIRC custom fields are stored as a string in the database so it should be relatively straightforward to migrate your data to a new name

[kkthxbye-code]

you need to (manually?) update the amount of devices that were using the specific choice.

If bulk editing is not an option, the recommendation would be using a custom script, the API or nbshell to do the change.

like in the example, say you have 1000 routers with a CF representing the list of NTP Servers.

NTP servers specifically are a good usecase for config contexts, which do reflect the changes globally.

I understand what you are trying to achieve, it's just not an easy thing to solve with the way it's currently implemented.

[ITJamie]

I believe #12988 is meant to cover this?

[laimaretto]

I believe #12988 is meant to cover this?

It does look like so ... :-) ...

[jeremystretch]

I'm going to close this out as it does not appear to be a valid bug report.