Fixes: #708 - Represent select/multiselect fields as {value, label} in REST and GraphQL

[bctiemann]

Closes: #708

Summary

SelectFieldType/MultiSelectFieldType never wrapped their stored value in a labeled representation, unlike every core NetBox ChoiceField (e.g. dcim.Site.status) — both APIs returned the raw stored string(s) directly. One underlying gap, surfacing in both REST and GraphQL, as the issue itself notes.

Note: this PR targets the 715-integer-decimal-min-max-validation branch (itself stacked on 700-required-fields-not-enforced/#714), not main — it builds on the get_serializer_field() methods those introduce. Retarget to main once the earlier PRs in the stack merge.

• REST: SelectFieldType.get_serializer_field() now returns netbox.api.fields.ChoiceField — core's own field that represents {value, label} on read and still accepts a bare value on write — instead of DRF's plain ChoiceField. MultiSelectFieldType's ListField uses the same core ChoiceField as its child, so each item in the list reads the same way.
• GraphQL: added a small CustomObjectChoiceType (value, label) and a resolver for SELECT/MULTISELECT fields, mirroring core's CustomField.resolve_selection_value() almost exactly, and reusing this plugin's own CustomObjectTypeField.get_choice_label() — the same helper already backing the UI table column (SelectFieldType.get_table_column_field()) and get_display_value().
• Updated test_scalar_fields_query, whose existing assertion on the raw "status" value is now intentionally outdated by this fix.

Test plan

• SelectMultiSelectValueLabelAPITest (new, test_api.py) — REST GET returns {value, label} for select and a list of such dicts for multiselect; POST still accepts bare values on write.
• test_multiselect_field_query_returns_value_label_pairs (new, test_graphql.py) — GraphQL query returns {value, label} per item for a multiselect field.
• test_scalar_fields_query (updated) — GraphQL select field now queried/asserted as {value, label}.
• Empirically verified both layers end-to-end: REST GET/POST round-trip, and the actual built Strawberry type's resolver called directly against a real instance.
• Full test_graphql suite (32 tests, including the schema-assembly smoke test) passes.
• Broader regression pass (test_api, test_graphql, test_field_types, test_views — 455 tests) — 4 pre-existing errors observed, matching the already-established netbox_branching app_label baseline, confirmed unrelated.
• ruff check passes on all changed files.

[bctiemann]

@claude /review and limit response to actionable issues.

[github-actions]

Claude finished @bctiemann's task in 1m 51s —— View job

---

Review

• Read changed files
• Analyze implementation
• Post review

---

The implementation is clean and closely mirrors core NetBox's own pattern. Two actionable issues:

---

1. Stale graphql_annotation on SelectFieldType and MultiSelectFieldType

field_types.py:737 and field_types.py:832:

class SelectFieldType(FieldType):
    graphql_annotation = str          # now bypassed by CHOICE_TYPES guard

class MultiSelectFieldType(FieldType):
    graphql_annotation = List[str]    # same

After this PR, _build_object_type hits the CHOICE_TYPES guard before it ever calls _scalar_annotation_for() → get_graphql_annotation(), so these attributes are dead code. But they still say str / List[str], which is wrong — anyone calling SelectFieldType().get_graphql_annotation() directly (e.g., future tooling, docs generation, schema introspection helpers) gets a lie. They should either be removed (set to None) or updated to reflect the actual GQL return type.

Fix this →

---

2. Null select value not tested in REST

test_api.py — test_select_field_reads_as_value_label creates status="choice2" (always non-null). There's no test covering a non-required select field with no value set, which exercises a different branch in NetBoxChoiceField.to_representation(). Given the allow_null=True path on the serializer field, it's worth asserting that a null DB value comes back as None (not {"value": None, "label": ""} or similar).

Fix this →

---

Nothing else blocks this; the core logic, the _make_choice_resolver close-over, and the write-accepts-bare-value tests are all correct.

[bctiemann]

Addressed both in 63405a8:

1. Stale graphql_annotation — removed = str/= List[str] from SelectFieldType/MultiSelectFieldType entirely (matching ObjectFieldType/MultiObjectFieldType, which never set it either, for the same reason: GraphQL resolution goes through a dedicated resolver, not get_graphql_annotation()). Dropped the now-unused List import.
2. Null-value coverage — added test_select_field_reads_as_none_when_unset and test_multiselect_field_reads_as_none_when_unset. Worth noting: an unset multiselect also reads back as None, not [] — DRF's Serializer.to_representation() short-circuits to None before ever calling the field's own to_representation() when the underlying attribute is None, so this is inherent to how the model field's own default works, unaffected by this fix either way.

259/260 in the affected test classes (1 pre-existing skip, expected).

[bctiemann]

Pushed c6bd376 addressing Jason's finding on the choice-field coercion bug (inline reply here).

Summary: core's netbox.api.fields.ChoiceField coerces numeric-/boolean-looking string input to int/bool before checking choice membership, which breaks any choice set with a value like "1" or "true" — the API rejects its own GET output on write. Added SafeChoiceField, a ChoiceField subclass that keeps the {value, label} read shape but drops that write-side coercion, and swapped it in for SelectFieldType/MultiSelectFieldType. Verified empirically and added regression tests for both select and multiselect (numeric string, boolean-like string, and confirming out-of-set values are still rejected).