Choice Set: API "extra_choices" required - is this correct?

[p-rintz]

Should the extra_choices be required via the API?

Currently it is, but via the UI I can create choice sets that do not have extra_choices, but rather just base_choices.

Should be this line? (compare it to line 178 directly above)

netbox/netbox/extras/api/serializers.py

Line 180 in b7668fb

extra_choices = serializers.ListField(

[candlerb]

Netbox version?

Can you provide an example of an API call that fails, but that you think should succeed?

[p-rintz]

Current version 3.7.5.

curl -X 'POST' \
  'http://localhost:8000/api/extras/custom-field-choice-sets/' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'X-CSRFTOKEN: asdasdasdasdasdasdasdasdasd' \
  -d '{
  "name": "string",
  "description": "string",
  "base_choices": "IATA",
  "order_alphabetically": true
}'

This fails, since the extra_choices are required while missing in the request.

I am just trying to understand if the extra_choices should really be required or not. (since it isnt when creating a choice set via the UI)

[candlerb]

"base_choices" identifies another choice set; "extra_choices" are the choices unique to this choice set.

I think the confusion comes because "extra_choices" are always provided in the UI, but are permitted to be empty. The following works fine for me:

# curl -X 'POST' \
  "$NETBOX/api/extras/custom-field-choice-sets/" \
  -H "Content-Type: application/json" \
  -H "Authorization: Token $TOKEN" \
  -d '{
  "name": "string",
  "description": "string",
  "base_choices": "IATA",
  "extra_choices": [],
  "order_alphabetically": true
}'
### response ###
{"id":4,"url":...}

[p-rintz]

In that case, extra_choices shouldn't be required though, right?

Why permit an empty list, but require the option?

[candlerb]

In that case, extra_choices shouldn't be required though, right?

That's not obvious to me.

I think that you are suggesting that extra_choices could be made optional, and the default value could be an empty list. But maybe it's a good idea to require API users to be explicit that they want an empty choice set. After all, although choice sets with no extra choices aren't forbidden, neither are they particularly useful.

I guess it can be argued from a consistency point of view, if there are other places in the API where lists are optional and default to empty. Tags, maybe?

[p-rintz]

More that its rather confusing to me that I need to also explicitly send an empty extra_choice list in addition to the base_choice set, if all I want is to configure a base_choice set.

So much so, that I didnt think about sending an empty list, tbqh 😆
I thought I always needed to send some extra_choices with every base_choice set I was creating.