Fixes #567: Make "Custom object type" field read-only in Add Field flow

[bctiemann]

Fixes: #567

Summary

The Custom object type dropdown on the Add Field form showed undefined as the selected value when clicked.

Root Cause

TomSelect (NetBox's select widget) uses LABEL_FIELD = 'display' to resolve option labels from API results. CustomObjectTypeSerializer.Meta.fields never included "display", so the Custom Object Type API endpoint returned objects without a display value. When TomSelect preloaded options on focus, it overwrote the DOM-parsed label with undefined, causing the displayed selection to change to the literal string "undefined".

However, there is no need for this field to be editable in the first place, and it is disabled/read-only in the Edit flow for an existing Custom Object Type Field. The real root cause is that the field should be read-only and inferred from the COT context in the Add flow too.

Fix

Make custom_object_type read-only and inferred from the view context when creating a new Custom Object Type Field.

🤖 Generated with Claude Code

[bctiemann]

@claude /review

[github-actions]

Claude finished @bctiemann's task in 4m 19s —— View job

---

Code Review — PR #568

• Gather context and read changed files
• Analyze the diff
• Post review feedback

---

Overview

This PR addresses issue #567 via two complementary strategies: (1) adding "display" to CustomObjectTypeSerializer so TomSelect can resolve option labels from the API, and (2) making custom_object_type unconditionally read-only in the Add Field form so the buggy TomSelect interaction can never corrupt the selection even if the API response is missing a field.

The overall approach is correct and well-structured across 4 commits. A few observations below.

---

api/serializers.py — display added to CustomObjectTypeSerializer

Good. This directly fixes the reported symptom. NetBoxModelSerializer exposes a display SerializerMethodField via the base class; adding it to fields makes it appear in API responses so TomSelect's LABEL_FIELD='display' works.

Minor gap — display is not in brief_fields (serializers.py:345):

brief_fields = ("id", "url", "name", "slug", "description")

When CustomObjectTypeSerializer is used in nested/brief mode (e.g., embedded within another serializer response), display won't be present. This won't affect the specific bug being fixed here (TomSelect calls the full list endpoint), but it's inconsistent — every other generated custom-object serializer in the file includes "display" in its brief_fields (line 482). Fix this →

---

forms.py — custom_object_type always disabled

Correct. Moving self.fields["custom_object_type"].disabled = True unconditionally (line 284) is the right invariant — this field is always determined by context and should never be editable by the user, not even during creation.

The comment added is clear and accurately describes why.

---

views.py — alter_object override

Correct in principle; one detail worth noting.

The implementation correctly handles the GET-param case: when a form at /custom-objects/fields/add/?custom_object_type=X is submitted, the ?custom_object_type=X query string remains in the URL, so request.GET.get('custom_object_type') returns the value even on a POST.

The second part — or request.POST.get('custom_object_type') — exists specifically to support PrimaryObjectViewTestCase, which posts custom_object_type in the request body (as confirmed by test_views.py:134). This is acknowledged in the inline comment, which is helpful context.

One concern worth being aware of: reading custom_object_type from the POST body means that any POST request can set the COT for a new field, regardless of the URL query param. In a multi-tenant or fine-grained permission setup this could allow a user to create fields in a COT whose ?custom_object_type= they don't control. The risk is mitigated by NetBox's object-level permission system (which should restrict create on CustomObjectTypeField based on COT), but this is worth a note for reviewers familiar with the deployment's permission configuration.

If the POST-body read is only needed for the test harness, an alternative would be to fix the test to pass the COT via a query param in the URL (matching the real Add Field flow) — though that is a more invasive change and the current approach is pragmatic. Discuss this →

---

tests/test_forms.py

The test helper correctly switches from putting custom_object_type in data={} to initial={}, since disabled fields are ignored from POST data in Django. The approach is sound — Django's ModelChoiceField accepts an integer PK in initial and resolves it at validation time.

---

Summary

Item	Verdict
display fix for TomSelect	✅ Correct
Always-disabled custom_object_type in form	✅ Correct
alter_object GET-param reading	✅ Correct
alter_object POST-body reading	✅ Pragmatic, minor authorization note above
Test update for disabled field	✅ Correct
display missing from brief_fields	⚠️ Minor gap

The changes are solid. The one clear improvement would be adding "display" to brief_fields for consistency.

[bctiemann]

The agent review looks like it is keying on the initial commit which added display to the serializer, which is no longer the case. Everything else noted in the review looks good.