Introduce choice sets for custom fields

[jeremystretch]

NetBox version

v3.5.4

Feature type

Data model extension

Proposed functionality

Currently, custom field choices are stored as an array of values on each applicable CustomField instance:

class CustomField(CloningMixin, ExportTemplatesMixin, ChangeLoggedModel):
    choices = ArrayField(
        base_field=models.CharField(max_length=100),
        blank=True,
        null=True,
        help_text=_('Comma-separated list of available choices (for selection fields)')
    )

This issue proposes essentially moving the choices field to a separate model, CustomFieldChoiceSet:

class CustomField(CloningMixin, ExportTemplatesMixin, ChangeLoggedModel):
    choices = models.ForeignKey(
        to='CustomFieldChoiceSet',
        blank=True,
        null=True
    )


class CustomFieldChoiceSet(ChangeLoggedModel):
    name = models.CharField()
    description = models.CharField(blank=True)
    choices = ArrayField(
        base_field=models.CharField(max_length=100),
        help_text=_('Comma-separated list of available choices (for selection fields)')
    )

Individual choice values will continue to be managed as flat lists, but now are defined on separate CustomFieldChoiceSet instances, which can be referenced by multiple custom fields.

As part of this work, I'd also like to improve the manner in which custom field choices are managed by the end user. We can extend the current view to allow creating, modifying, and deleting choice values as if they were individual objects (as opposed to a list of values in a single JSON form field).

This will result in a breaking API change for custom fields themselves, however custom field data on NetBox objects should not be affected by the change.

Use case

This change was prompted by #12194, which seeks to introduce reusable choice sets containing well-known values (e.g. UN-LOCODE identifiers). Moving the choice sets into a separate model allows for their efficient reuse across multiple custom fields without introducing significant overhead. (The choice sets can be easily pre-fetched along with the custom fields themselves.)

Database changes

• Introduce the new CustomFieldChoiceSet model (above)
• Add a ForeignKey from CustomField to CustomFieldChoiceSet
• Migrate all existing choices values to new CustomFieldChoiceSet instances
• Drop the old choices field from the CustomField model

External dependencies

N/A