Closes: #392 - Validate semantic version fields

[bctiemann]

Closes: #392

Summary

• Adds a _validate_semver validator (backed by packaging.version.Version) to three version-string fields:
  • CustomObjectType.version — the schema version of the COT itself
  • CustomObjectTypeField.deprecated_since — version in which the field was marked deprecated
  • CustomObjectTypeField.scheduled_removal — version in which the field is planned to be removed
• All three fields remain blank=True; the validator is a no-op for empty strings
• Validation uses PEP 440 (packaging.version), which is already a project dependency and accepts standard semver strings (1.0.0, 2.3.4, etc.) as well as Python-style pre/post-release suffixes (1.0.0a1, 1.0.0.post1)
• Includes a Django migration (0007) recording the field alterations

Changed files

File	Change
models.py	Import packaging.version.{Version,InvalidVersion}; add _validate_semver; wire onto three CharField definitions
migrations/0007_alter_customobjecttype_version_and_more.py	Generated migration for the three AlterField operations
tests/test_models.py	SemverValidationTestCase — 9 tests covering blank (valid), valid PEP 440 strings, and invalid strings for all three fields

Part of the portable schema format cluster

PR	Issue	Description
#449	#385	Schema document format
#450	#386	Exporter
#452	#387	Comparator / diff engine
#453	#389	Upgrade executor
#454	#390	Schema preview & apply API endpoints
#455	#392	Version field semver validation

[arthanson]

Blocked by #449

[bctiemann]

No longer blocked.

[arthanson]

need to fix the merge conflicts

[bctiemann]

Additional fixes bundled into this PR

While integrating this branch with feature, a cluster of startup and request-time crashes surfaced. They are fixed in the 11 commits added on top of the original semver-validation work. This note records what broke, why it only showed up now, and what each fix does.

---

How the bugs entered feature

Two PRs merged on April 20 introduced the conditions that caused the crashes:

PR #474 — Skip absent fields when registering search index for stub models
Added model._meta.get_field(field.name) inside register_custom_object_search_index() to safely skip fields absent from a stub model. The intent was correct, but _meta.get_field() for a name that is not yet in _forward_fields_map falls through to fields_map, which triggers Django's lazy _relation_tree computation. _relation_tree calls apps.get_models(), which re-enters our custom get_models() override, which calls get_model() for every COT — producing unbounded recursion.

PR #467 — Add thread-safe clear_cache suppressor
Restructured _after_model_generation by wrapping it inside _suppress_clear_cache(). The suppressor only prevents apps.clear_cache() from firing; it does not protect against apps.get_models() re-entry. _after_model_generation already called model._meta.get_field() for tombstoned fields before this PR, so the same recursion path existed there as well.

Each PR passed its own tests and worked correctly in isolation. The combination exposed the recursion because both register_custom_object_search_index (new call from #474) and _after_model_generation (restructured by #467) could now trigger _relation_tree during the same model registration window. Merging both into feature, and then merging feature into this branch, was when the crashes first appeared.

---

Root cause

Any call to model._meta.get_field() or model._meta.get_fields() during model registration can trigger Django's lazy _relation_tree cached property. That computation calls apps.get_models(), which re-enters our override, which calls get_model() for every COT. If get_model() is already executing (we are mid-registration), this is infinite recursion.

The safe alternatives are model._meta.local_fields and model._meta.local_many_to_many — plain lists populated at class-creation time that never trigger _relation_tree.

---

Fixes (in order of application)

Commit	What it fixes
0c9ada6	Replace _meta.get_field() in register_custom_object_search_index() with local_fields / local_many_to_many set membership check
9617203	Same replacement in _after_model_generation() for tombstoned fields in _trashed_field_objects
409efe6	Add _app_ready flag to get_models(): skip all dynamic model generation until ready() has fully completed. Prevents dcim.ready() → Device._meta.get_fields() → _relation_tree → our get_models() from attempting COT model generation before the plugin is initialised
052a0b1	Centralise null/missing related_object_type_id handling into FieldType._get_related_content_type(), which converts ContentType.DoesNotExist and null-FK into NotImplementedError. Add model_field_names guard in get_serializer_class() so Meta.fields and serializer attrs stay consistent (DRF raises on mismatch)
f7f39f5	Replace all remaining raw ContentType.objects.get(pk=field.related_object_type_id) calls in field_types.py with self._get_related_content_type(field) so every caller gets a consistent NotImplementedError
fd4c006	Add _get_related_content_type() guard at the top of both get_serializer_field() methods so a null/missing FK raises before field.related_object_type.model_class() is called
ed1418a	Widen the except clause in _fetch_and_generate_field_attrs() from ContentType.DoesNotExist to NotImplementedError to match what _get_related_content_type() now raises
9cb440e	Downgrade the "skipping field" log messages from WARNING to DEBUG; they were appearing twice at startup because get_model() was being called twice per COT on the stub path
a2b3191	Remove now-dead ContentType.DoesNotExist from the except tuple (unreachable after centralisation); fix two raw ContentType.objects.get() calls in MultiObjectFieldType that used the instance parameter and were missed by the earlier search-and-replace
bcf7f10	Regression tests: get_model() with null FK, get_serializer_class() with skipped field, register_custom_object_search_index() with stub model, ObjectFieldType/MultiObjectFieldType.get_model_field() raises NotImplementedError for null FK
d48ca78	Move the search-index regression test from SearchReindexTestCase to CustomObjectTypeTestCase where it belongs

[arthanson]

jsonschema is listed in pyproject.toml dependencies (hard requirement), but api/views.py wraps its import in a try/except and silently no-ops schema validation if it fails (_HAS_JSONSCHEMA = False).

If it's required, the ImportError path is dead code and the silent-pass fallback should be replaced with a startup error. If it's optional, it shouldn't be in dependencies. Either way, the OSError/json.JSONDecodeError case (missing/corrupt schema file) is a separate concern and should be handled explicitly regardless.