Custom field values no longer saved with ID

[jakubkrysl]

Hi,
Continuing from #5652. Copying the relevant comment:

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.

Our goal is to be able to set owner (and other fields) for several endpoints (IP, prefix, device...) and being able to change part of the value and have this change propagate everywhere.
This worked with v2.9, but is broken in v2.10 since there are no more IDs associated to custom field values. Are the IDs coming back in the future? Is there other way to do this?

[candlerb]

Although you don't actually say it, I am guessing that you are talking about custom fields where the data type is "Selection", i.e. a drop-down list of choices? That's the only place I can see "ID" being relevant.

In principle, I think you should put a permanent value here (e.g. customer number), and then look up changing data (like the customer's current E-mail address) in a separate table.

However, I do note that in HTML, choices can have labels which are distinct from the values:

<select>
  <option value="foo">[email protected]</option>
  <option value="bar">[email protected]</option>
</select>

Therefore you could request a feature to allow the displayed values for choices to be different to the stored values. e.g.

Choices:  [email protected],[email protected]

Effectively then, "foo" becomes the persistent ID, and the displayed value can be more user-friendly and/or changed without altering data in the database. Is that the sort of thing you're thinking of?

[jakubkrysl]

Yes, that would solve the regression we are facing. Basically I don't care if the persistent value is ID (int), string or anything else as long as we have a way to persistently keep the displayed value of choice custom field linked to assigned objects even if part of that value (or whole) is changed.
Is this something that can be reasonably done?

[candlerb]

I think it should be possible. It's a question of taking the CustomField.choices value and formatting it in the appropriate way for the Django selection widget; probably also changing any validation code that confirms that the provided value is one of the choices. It would need someone who groks Django widgets to do it.