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

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

New Issue
Closed
opened 2025-12-29 20:33:58 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:33:58 +01:00
Owner
Copy Link

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

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.

Originally created by @laimaretto on GitHub (Jun 21, 2023). ### 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.
adam closed this issue 2025-12-29 20:33:58 +01:00
adam commented 2025-12-29 20:33:59 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jun 21, 2023):

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.

@kkthxbye-code commented on GitHub (Jun 21, 2023): 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.
adam commented 2025-12-29 20:33:59 +01:00
Author
Owner
Copy Link

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

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.

@laimaretto commented on GitHub (Jun 21, 2023): 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.
adam commented 2025-12-29 20:33:59 +01:00
Author
Owner
Copy Link

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

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

@a084ed22 commented on GitHub (Jun 21, 2023): 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
adam commented 2025-12-29 20:34:00 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jun 21, 2023):

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.

@kkthxbye-code commented on GitHub (Jun 21, 2023): > 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.
adam commented 2025-12-29 20:34:00 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Jun 23, 2023):

I believe #12988 is meant to cover this?

@ITJamie commented on GitHub (Jun 23, 2023): I believe #12988 is meant to cover this?
adam commented 2025-12-29 20:34:00 +01:00
Author
Owner
Copy Link

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

I believe #12988 is meant to cover this?

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

@laimaretto commented on GitHub (Jun 23, 2023): > I believe #12988 is meant to cover this? It does look like so ... :-) ...
adam commented 2025-12-29 20:34:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 27, 2023):

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

@jeremystretch commented on GitHub (Jun 27, 2023): I'm going to close this out as it does not appear to be a valid bug report.
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#8222
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?