Values for Selection Custom Fields via API

[cimnine]

Issue type

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

Environment

• Python version: 3.6
• NetBox version: 2.2.8

Description

As I already told on the mailing list, I would like to fill in the values of selection custom fields via the API.

I expected to provide the actual value of the field, i.e. the text I see in the dropdown of the GUI. But the API expects to get the ID of the option, rather than the value, and there seems to be no way of looking up the available (value,id)-pairs for a given selection custom fields. Also I would like to avoid hardcoding any (value,id)-pairs in my application, as it's not consistent across our different Netbox instances (local, staging, production) and it would be very fragile.

I see two solutions:

• When I set the value of such a selection custom field, Netbox accepts the String value and converts it to the respective ID internally.
• There is a new endpoint to fetch the option pairs of selection custom fields, similar to the other _options endpoints.

IMO both options could even live in parallel to each other: Whenever an integer is presented as value for a selection custom field, we can assume it's the ID of the value. Whenever it's a string, we can assume it's the text value and first has to be converted to the corresponding integer id.

Allowing to submit text values via the API instead of the actual IDs might imply that we don't allow the same text value on one given selection custom field twice.

[cimnine]

I just learned that the behaviour I described was already discussed in #1297, yet no solution was proposed / implemented to get the primary keys of values via the API.

Which would be important when the selection options change over time or when the PKs differ between independant instances of Netbox (e.g. staging/production).

[arionl]

I ran into this same issue when trying to update a selection-based custom field I'm using through APIs (and pynetbox). I'm really trying to avoid custom fields whenever I can but I still need a few. In general I'd rather have a custom field with fixed selection options rather than a string to try to limit data diversity.. but without a programmatic way of changing selection values, it's getting a bit challenging..

[jeremystretch]

We need to decide how to expose the custom field choices in the API. Currently, each app has a _choices endpoint which returns the choices for all models in the form "model:field": [choices]:

{
    "device:face": [
        {
            "label": "Front",
            "value": 0
        },
        {
            "label": "Rear",
            "value": 1
        }
    ],
    "device:status": [
        {
            "label": "Active",
            "value": 1
        },
        ...
    ]
}

We can't do model:custom_field_name because it's possible that custom_field_name will collide with the name of a built-in field. We need a way to distinguish custom fields.

One option would be to prepend cf_ to the field name, such that custom field foo on the Device model would become device:cf_foo, but that may not be the cleanest approach. Open to suggestions.

[a31amit]

I am also very much interested in this feature.

[lampwins]

I feel this should be its own API endpoint. Perhaps /extras/custom-fields/_choices/. This way it can act just like the built-in app choices endpoints, but there can be no name collision or name manipulation. It is also very apparent that these choices apply only to custom fields.

[jasweet]

@jeremystretch I'd be fine with any way to lookup the '_choices' label using the value. Doesn't have to be pretty, just has to work.

[Grokzen]

@jeremystretch If issue would be accepted, i got the following branch ready to be merged Grokzen/netbox@develop...Grokzen:feature/custom_field_choice_api_endpoint

It would add a new API endpoint /api/extras/_custom_field_choices/ and it would output in the following format

{
  "archiving.retention": {
    "Archiving 13 Months": 493,
    "Archiving 7 Years": 494,
    "Archiving 10 Years": 495,
    "Other": 496
  },
  "backup.database.dbfrequency": {
    "1 per day": 515,
    "1 per hour": 516
  },
}

External services can query all fields and cache them locally for a period of time, or they can look for a specific value each time and pass it into the next api call to POST an item.

[jeremystretch]

@Grokzen I think that looks good if you want to submit a PR. I like @lampwins' idea of putting the endpoint at /extras/custom-fields/_choices/, but that wouldn't show up in the browsable API, so your way is probably preferable to make it more obvious.

[Grokzen]

Awesome, i will put it up during the upcomming workweek

[jeremystretch]

Closed in #2941. Thanks @Grokzen!

[jasweet]

@Grokzen & @jeremystretch
Great work! This is fan-friggin-tastic, and a much needed endpoint function.