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

Change of custom field name results in empty data #4478

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

Originally created by @Mothuizyk on GitHub (Jan 20, 2021).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.6.8
  • NetBox version: 2.10.3

Steps to Reproduce

  1. Create custom field.
  2. Create appropriate object (device/ip address...) and fill the custom field with data.
  3. Change name of custom field and see that appropriate field in object is empty.
  4. (Optionally) Change back the name and see that the data is back.

Expected Behavior

After changing the name of custom field data is also migrated.

Observed Behavior

Data is still linked with old name.

Looking at the database the data is still there with associated old name. Seems like name change doesn't make sure that the appropriate data is migrated to the field under new name. For sure affects devices and ip addresses, probably all objects with custom fields.

Originally created by @Mothuizyk on GitHub (Jan 20, 2021). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.6.8 * NetBox version: 2.10.3 ### Steps to Reproduce 1. Create custom field. 2. Create appropriate object (device/ip address...) and fill the custom field with data. 3. Change name of custom field and see that appropriate field in object is empty. 4. (Optionally) Change back the name and see that the data is back. ### Expected Behavior After changing the name of custom field data is also migrated. ### Observed Behavior Data is still linked with old name. Looking at the database the data is still there with associated old name. Seems like name change doesn't make sure that the appropriate data is migrated to the field under new name. For sure affects devices and ip addresses, probably all objects with custom fields.
adam added the type: bugstatus: accepted labels 2025-12-29 18:36:26 +01:00
adam closed this issue 2025-12-29 18:36:26 +01:00
adam commented 2025-12-29 18:36:27 +01:00
Author
Owner
Copy Link

@jakubkrysl commented on GitHub (Jan 20, 2021):

Hi,

We're seeing this too. The issue we found is ID from custom field value is gone in v2.10. This is a major one for us.

One of our use cases is having owner as custom field in IP object. The owner contains e-mail address. If we change the e-mail (or name of the owner), we still want object owned by this owner to be owner after the change, just with the change. This is not possible anymore. The result is data inconsistency on owner change:

  1. object had owner, object keeps old owner
  2. object had owner, some other change is done to object (like described above), object has no owner now (as the owner is not found in possible values of the custom field)
  3. new objects are assigned new owner as the old is "gone"

On change of the custom field in v2.9, the owner got changed everywhere so all 3 previous scenarios resulted in having new owner.

Note: Our scripts are working with ID of the owner to set some default one for some objects. This too is not possible. We can use string now and access the value easily, but we would have to change all our scripts when we change the default string.

We are depending a lot on custom fields, v2.10 completely broke this. I cannot see a way to deploy v2.10 until this is fixed.

@jakubkrysl commented on GitHub (Jan 20, 2021): Hi, We're seeing this too. The issue we found is ID from custom field value is gone in v2.10. This is a major one for us. One of our use cases is having owner as custom field in IP object. The owner contains e-mail address. If we change the e-mail (or name of the owner), we still want object owned by this owner to be owner after the change, just with the change. This is not possible anymore. The result is data inconsistency on owner change: 1. object had owner, object keeps old owner 2. object had owner, some other change is done to object (like described above), object has no owner now (as the owner is not found in possible values of the custom field) 3. new objects are assigned new owner as the old is "gone" On change of the custom field in v2.9, the owner got changed everywhere so all 3 previous scenarios resulted in having new owner. Note: Our scripts are working with ID of the owner to set some default one for some objects. This too is not possible. We can use string now and access the value easily, but we would have to change all our scripts when we change the default string. We are depending a lot on custom fields, v2.10 completely broke this. I cannot see a way to deploy v2.10 until this is fixed.
adam commented 2025-12-29 18:36:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 20, 2021):

@Thetacz this doesn't sound like the issue described above, which involves renaming a particular custom field. FYI, the legacy custom field implementation also did not support object assignment, so I'm not sure exactly what issue you're running into. Please consider starting a separate discussion if you'd like assistance with this.

@jeremystretch commented on GitHub (Jan 20, 2021): @Thetacz this doesn't sound like the issue described above, which involves renaming a particular custom field. FYI, the legacy custom field implementation also did not support object assignment, so I'm not sure exactly what issue you're running into. Please consider starting a separate [discussion](https://github.com/netbox-community/netbox/discussions) if you'd like assistance with this.
adam commented 2025-12-29 18:36:28 +01:00
Author
Owner
Copy Link

@jakubkrysl commented on GitHub (Jan 20, 2021):

@Thetacz this doesn't sound like the issue described above, which involves renaming a particular custom field. FYI, the legacy custom field implementation also did not support object assignment, so I'm not sure exactly what issue you're running into. Please consider starting a separate discussion if you'd like assistance with this.

Oh I see, I misunderstood the issue, got pointed here by Paddy from N2C. Based on our discussion I thought it complains about the values of the custom field, but it seems to talk only about the name of the field itself, not the name of the values in the field. I'll create a discussion so we can continue there.

EDIT: discussion started here https://github.com/netbox-community/netbox/discussions/5655

@jakubkrysl commented on GitHub (Jan 20, 2021): > @Thetacz this doesn't sound like the issue described above, which involves renaming a particular custom field. FYI, the legacy custom field implementation also did not support object assignment, so I'm not sure exactly what issue you're running into. Please consider starting a separate [discussion](https://github.com/netbox-community/netbox/discussions) if you'd like assistance with this. Oh I see, I misunderstood the issue, got pointed here by Paddy from N2C. Based on our discussion I thought it complains about the values of the custom field, but it seems to talk only about the name of the field itself, not the name of the values in the field. I'll create a discussion so we can continue there. EDIT: discussion started here https://github.com/netbox-community/netbox/discussions/5655
adam commented 2025-12-29 18:36:28 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 20, 2021):

Allowing custom field name changes introduces a host of challenges. Foremost, Django doesn't currently support modification of JSONField keys using .update() (although there is a feature request for it). This means that any such changes would need a separate database query per object, which would be very inefficient at scale.

Additionally, custom field values are recorded in the change log, so any changes to a custom field's name will be appear as a change to the assigned object upon its next modification.

Given these considerations, it might be more prudent to simply disallow the renaming of custom fields, at least until bulk update becomes feasible.

@jeremystretch commented on GitHub (Jan 20, 2021): Allowing custom field name changes introduces a host of challenges. Foremost, Django doesn't currently support modification of JSONField keys using `.update()` (although there is a [feature request](https://code.djangoproject.com/ticket/29112) for it). This means that any such changes would need a separate database query per object, which would be very inefficient at scale. Additionally, custom field values are recorded in the change log, so any changes to a custom field's name will be appear as a change to the assigned object upon its next modification. Given these considerations, it might be more prudent to simply disallow the renaming of custom fields, at least until bulk update becomes feasible.
adam commented 2025-12-29 18:36:28 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 15, 2021):

This means that any such changes would need a separate database query per object, which would be very inefficient at scale.

I've worked around this by employing bulk_update() on the queryset. It's not quite ideal as we still need to load all instances into memory, but it's far more efficient than updating them each individually.

Additionally, custom field values are recorded in the change log, so any changes to a custom field's name will be appear as a change to the assigned object upon its next modification.

Note that this fix will cause changelog discrepancies on NetBox releases prior to v2.11. Releases v2.11.0 and later are unaffected due to the improved change logging.

@jeremystretch commented on GitHub (Apr 15, 2021): > This means that any such changes would need a separate database query per object, which would be very inefficient at scale. I've worked around this by employing `bulk_update()` on the queryset. It's not quite ideal as we still need to load all instances into memory, but it's far more efficient than updating them each individually. > Additionally, custom field values are recorded in the change log, so any changes to a custom field's name will be appear as a change to the assigned object upon its next modification. Note that this fix _will_ cause changelog discrepancies on NetBox releases prior to v2.11. Releases v2.11.0 and later are unaffected due to the improved change logging.
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 status: accepted type: bug
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#4478
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?