Change of custom field name results in empty data

[Mothuizyk]

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.

[jakubkrysl]

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.

[jeremystretch]

@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.

[jakubkrysl]

@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 #5655

[jeremystretch]

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.