Shared picklists for custom fields

[candlerb]

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

• Python version: 3.5.2
• NetBox version: 2.2.2

Description

Each custom field of type "Selection" has its own unique picklist of values. It would be very helpful if a picklist could be a separate entity, and multiple custom fields could refer to the same picklist.

Use case: we want both Device and VM to have the following custom fields:

• Primary person responsible
• Secondary person responsible

Currently this means having to enter and maintain four copies of the same picklist. (In fact we want more custom fields with assigned users, but that's enough for example purposes)

By re-using the same picklist, it would also use the same values, which could make some SQL queries simpler. At the moment the custom field serialized values are different depending on which field it came from.

netbox=# select * from extras_customfieldchoice where value='Brian';
 id | value | weight | field_id
----+-------+--------+----------
  2 | Brian |    100 |        1
  4 | Brian |    100 |        3
... etc

Proposed implementation:

• extras_customfield gains a new value selection_id, only used when type is CF_TYPE_SELECT
• extras_selection is a new table/object
  • data migration is simple: insert into extras_selection(id) (select id from extras_customfield where type=600). That is: each existing custom field of type CF_TYPE_SELECT becomes an instance of extras_selection with the same id.
  • TODO: bump the sequence nextval
• rename extras_customfieldchoice to extras_selectionchoice
• extras_selectionchoice links to selection_id instead of field_id
• admin and main UI updates

[jeremystretch]

This would be extending custom fields beyond their intended use. The selection field is only meant to convey a set of static predefined values relevant to a single field (similar to device status). If you find yourself needing to reference the same set of values from multiple fields, it's a sign that you've outgrown custom fields and need to pursue a more robust solution.

For this particular use case, it seems like you'd be best off waiting for #988 or #132.

[candlerb]

#988

A single "Owner" wouldn't cut it for me, because I need multiple "Owners". However it does suggest another idea which may be simpler to implement: a new CUSTOMFIELD_TYPE_CHOICES value of CF_TYPE_USER, where the field contains a user id.

#132

Multiple tags to a device/VM would probably do the job. I see this as an extension to 'Role', but allowing a device/VM to be associated with multiple Roles.