Merge pull request #13 from CESNET/12-feature-support-polymorphic-object-multiobject-fields-from-netbox-custom-objects-v050

Add polymorphic Object/MultiObject field support + release 2.4.0

Author: Kani999

CHANGELOG.md

@@ -5,6 +5,80 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [2.4.0] - 2026-05-12
+
+### Added
+
+- **Polymorphic Object / MultiObject field support**
+  ([#12](https://github.com/CESNET/netbox-custom-objects-tab/issues/12)) —
+  `netbox-custom-objects` v0.5.0 introduced `is_polymorphic=True` fields
+  whose targets live in the `related_object_types` M2M (and, for MultiObject,
+  in a per-field through table keyed by `(source_id, content_type_id, object_id)`).
+  The plugin's discovery logic previously filtered only on the single-FK
+  `related_object_type`, so polymorphic links were invisible: tabs disappeared
+  from referenced hosts (Device, Interface, Site, other CO Types) until the
+  field was switched back to non-polymorphic. Both tab styles now mirror
+  upstream's `CustomObjectLink.left_page` query shape — a non-polymorphic
+  queryset plus a polymorphic queryset, with per-field branching into four
+  reverse lookups (FK column, GFK `(content_type_id, object_id)` pair, M2M,
+  polymorphic through table).
+- **Polymorphic-field "Add *Type*" toolbar on typed tabs** — the toolbar
+  shortcut now works for polymorphic Object and MultiObject fields using
+  upstream's add-view sub-field prefill format: `?<name>__ct=<host_ct>&<name>__obj=<host_pk>`
+  for polymorphic Object, and `?<name>__<host_app>__<host_model>=<host_pk>`
+  for polymorphic MultiObject (the upstream form synthesizes one
+  `DynamicModelMultipleChoiceField` per allowed target type; we fill only
+  the one matching the host). The previous behaviour silently skipped the
+  Add link for polymorphic fields.
+
+### Changed
+
+- **Minimum `netbox-custom-objects` is now 0.5.0.** Enforced at startup:
+  `PluginConfig.ready()` probes for the `is_polymorphic` model field and
+  raises `ImproperlyConfigured` with a clear upgrade message if the
+  installed upstream is older. The check is behaviour-based (looks for the
+  field directly, not a version string) so it remains correct against forks
+  and pre-release tags. The pre-0.5 compat shims (`getattr` guards, module
+  feature probes) have been removed from both `combined.py` and `typed.py`.
+
+### Known Issues
+
+- **Upstream Delete bug on `netbox-custom-objects == 0.5.0` (fixed in 0.5.1).**
+  Deleting a Custom Object via the NetBox UI on 0.5.0 can raise
+  `ValueError: Cannot query "...": Must be "Table<N>Model" instance.` from
+  `CustomObjectDeleteView._get_dependent_objects`. The same crash also hits
+  `CustomObjectBulkDeleteView` (NetBox's generic `BulkDeleteView.post()`
+  iterates and calls `obj.delete()` per row — same code path), so
+  **Bulk Delete is NOT a workaround** (2.3.0 README claim corrected).
+  **Resolution:** upgrade upstream — PR
+  [#501](https://github.com/netboxlabs/netbox-custom-objects/pull/501)
+  (merged into `main` 2026-05-11) eliminates the entire bug class. As of
+  the 2.4.0 release date, no `0.5.1` release tag exists yet; install from
+  `main` (`pip install git+...@main`) or pin to `>=0.5.1` once tagged.
+  Adjacent fixes for related drift paths (#504, #505, #510) also ship in
+  `main` / `0.5.1`.
+- **Polymorphic-MultiObject rows amplify the failure rate on 0.5.0.** Each
+  polymorphic Object field adds a `GenericForeignKey` descriptor and each
+  polymorphic MultiObject field adds a per-field through model; Django's
+  collector traverses every related model during deletion, so polymorphic
+  rows give the drift more chances to land. Plugin 2.4.0's discovery code
+  walks these descriptors (the original goal of 2.4.0) and warms the
+  cache enough that the upstream drift becomes deterministic rather than
+  intermittent on 0.5.0.
+- **Workarounds for installs that cannot upgrade yet:** `manage.py shell`
+  direct delete (single-process model cache, no drift — see README) or
+  `systemctl restart netbox` (clears the cache). No UI-side workaround
+  exists for 0.5.0.
+- **Root cause is upstream** (`netbox-custom-objects` dynamic-model caching).
+  This plugin does not override delete or model caching and cannot fix it
+  from its own code; PR #501 fixes it inside upstream's delete view.
+- **Cosmetic post-fix issue on patched builds.** On builds containing
+  PR #501 (upstream `main` / forthcoming 0.5.1), the delete-success toast
+  for some dynamic models renders as `"Deleted <Type> <Type> None"` — the
+  patched view calls `str(obj)` *after* the row's deletion, so the
+  primary field returns `None`. Cosmetic only; the delete itself works.
+  Worth a small upstream follow-up issue but not a blocker.
+
 ## [2.3.0] - 2026-05-12
 
 ### Added

README.md

@@ -27,16 +27,26 @@ Two tab modes are available:
 ## Requirements
 
 - NetBox 4.5.0 – 4.6.99
-- `netbox_custom_objects` plugin **≥ 0.4.6** installed and configured (≥ 0.5.0 recommended on NetBox 4.6)
+- `netbox_custom_objects` plugin **≥ 0.5.0** installed and configured
+  (**≥ 0.5.1 strongly recommended** — 0.5.0 has an upstream Delete bug
+  that 0.5.1 fixes; see [Known Issues](#known-issues))
 
 ## Compatibility
 
-| Plugin version | NetBox version | `netbox_custom_objects` version       |
-|----------------|----------------|---------------------------------------|
-| 2.2.x          | 4.5.4+ / 4.6.x | ≥ 0.4.6 (≥ 0.5.0 on 4.6)              |
-| 2.1.x          | 4.5.4+         | ≥ 0.4.6                               |
-| 2.0.x          | 4.5.x          | ≥ 0.4.6                               |
-| 1.0.x          | 4.5.x          | ≥ 0.4.4                               |
+| Plugin version | NetBox version | `netbox_custom_objects` version                                        |
+|----------------|----------------|------------------------------------------------------------------------|
+| 2.4.x          | 4.5.4+ / 4.6.x | **≥ 0.5.0 required** (≥ 0.5.1 strongly recommended — fixes Delete bug) |
+| 2.3.x          | 4.5.4+ / 4.6.x | ≥ 0.4.6 (≥ 0.5.0 on 4.6)                                               |
+| 2.2.x          | 4.5.4+ / 4.6.x | ≥ 0.4.6 (≥ 0.5.0 on 4.6)                                               |
+| 2.1.x          | 4.5.4+         | ≥ 0.4.6                                                                |
+| 2.0.x          | 4.5.x          | ≥ 0.4.6                                                                |
+| 1.0.x          | 4.5.x          | ≥ 0.4.4                                                                |
+
+Plugin 2.4.x **enforces** the 0.5.0 minimum at startup: `PluginConfig.ready()`
+probes for the upstream `is_polymorphic` model field and raises
+`ImproperlyConfigured` with an upgrade message if the installed upstream is
+older. The check is behaviour-based (looks for the field, not a version
+string) so it stays correct across forks and pre-release tags.
 
 ## Installation
 
@@ -210,36 +220,110 @@ The tab displays:
 
 ## Known Issues
 
-### Per-row Delete fails on the first attempt right after Create (upstream bug)
+### Upstream Delete bug on `netbox-custom-objects == 0.5.0` (fixed in 0.5.1)
 
-After creating a custom object via the 2.3.0 "Add *Type*" button on a
-Typed tab, clicking the per-row **Delete** action in the list **on the
-very first attempt** raises a `ValueError` inside upstream
+**Affected versions:** `netbox-custom-objects == 0.5.0` only.
+**Fixed in:** `netbox-custom-objects` `main` (PR
+[#501](https://github.com/netboxlabs/netbox-custom-objects/pull/501),
+merged 2026-05-11) and the forthcoming `0.5.1` release.
+**Not affected:** `0.4.x` (no polymorphic through-models) and any build
+that contains PR #501.
+
+Deleting a Custom Object instance through the NetBox UI on a 0.5.0
+install can raise a `ValueError` inside
 `netbox_custom_objects.CustomObjectDeleteView`:
 
 ```
 ValueError: Cannot query "<row title>": Must be "Table<N>Model" instance.
 ```
 
-(at `netbox_custom_objects/views.py:977`, inside
-`_get_dependent_objects`). Workarounds:
-
-1. **Refresh the typed-tab list page** between clicking Create and
-   clicking the per-row Delete. The second `/delete/` GET succeeds.
-2. **Use Bulk Delete** instead — it goes through a different upstream
-   code path and is unaffected.
-
-Pre-existing rows (created in earlier sessions or via the upstream
-"Add" menu under Custom Objects → *Type*) are not affected. The bug
-originates in dynamic-model class identity drift across the
-Create → Delete request boundary in the upstream `netbox_custom_objects`
-plugin: each Custom Object Type backs a dynamically-generated Django
-model (`Table<N>Model`), the model class registry rebuilds during the
-Create POST, and the immediately-following Delete GET still holds a
-reference to the prior class object in some scope (queryset cache,
-prefetch, or import-level reference) until a request boundary refreshes
-it. Will be tracked and fixed upstream; this plugin's 2.3.0 release
-ships with the workaround documented here.
+(at `netbox_custom_objects/views.py:977`, inside `_get_dependent_objects`,
+called by Django's `Collector.collect()`). The same crash also occurs from
+the bulk-delete view (`CustomObjectBulkDeleteView`) because NetBox's
+generic `BulkDeleteView.post()` iterates the queryset and calls `obj.delete()`
+per row — the same code path. **Bulk Delete is NOT a workaround**
+(earlier versions of this README claimed it was; that was incorrect).
+
+#### Recommended fix — upgrade upstream
+
+The cleanest resolution is to upgrade `netbox-custom-objects` to a
+build that contains PR #501. As of writing (2026-05-13) no `0.5.1`
+release tag exists yet, so the options are:
+
+```bash
+# Option A: install from upstream main (contains PR #501)
+pip install --upgrade --force-reinstall \
+    git+https://github.com/netboxlabs/netbox-custom-objects.git@main
+
+# Option B: wait for the 0.5.1 release tag and pin to it
+pip install --upgrade 'netbox-custom-objects>=0.5.1'
+```
+
+Then restart NetBox. The entire delete-bug class disappears regardless
+of this plugin's state — no plugin-side change required.
+
+Several adjacent fixes also landed in upstream `main` post-0.5.0 and
+will ship with `0.5.1`: PR #504 (cross-COT FK fields after restart),
+PR #505 (stale through-model FK path_infos on COT regeneration), and
+PR #510 (self-referential FK isinstance check). Upgrading once closes
+the whole family.
+
+#### Workarounds if you cannot upgrade yet
+
+1. **`manage.py shell` direct delete** (recommended for one-off rows).
+   A freshly-spawned shell process initialises the model cache exactly
+   once, so the class identity is consistent throughout the session and
+   the collector's identity-check succeeds:
+   ```bash
+   /opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py shell <<'PY'
+   from netbox_custom_objects.models import CustomObjectType
+   cot = CustomObjectType.objects.get(slug="<your-slug>")
+   cot.get_model().objects.filter(pk=<row-pk>).delete()
+   PY
+   ```
+2. **Refresh the typed-tab list page** between Create and per-row Delete.
+   This worked reliably for non-polymorphic fields on earlier versions
+   and still often works on 0.5.0, but it is no longer guaranteed —
+   polymorphic-MultiObject rows can drift the model cache mid-flow.
+3. **Restart NetBox.** Clears `_model_cache` outright. Reliable but
+   heavyweight; use when shell access isn't available.
+
+#### Why polymorphic fields amplify the bug on 0.5.0
+
+`netbox-custom-objects` 0.5.0 introduced `is_polymorphic=True` Object /
+MultiObject fields. Each polymorphic Object field adds a
+`GenericForeignKey` descriptor and each polymorphic MultiObject field
+adds a per-field through model. Django's collector traverses every
+related model when collecting deletion dependencies, so each extra
+related-model is another opportunity to hit a stale class generation in
+`CustomObjectType._model_cache`. Plugin 2.4.0's discovery code walks
+those same descriptors to find inbound links (the original goal of
+2.4.0), which warms the cache enough that the upstream drift becomes
+deterministic rather than intermittent.
+
+#### Root cause (for the curious)
+
+Each Custom Object Type backs a dynamically-generated Django model
+(`Table<N>Model`), and the class registry can rebuild between requests
+(or during a request that touches `get_model(no_cache=True)`). Django's
+`Collector` then sees the queryset's model class on one side and a
+related-field descriptor's `.to` pointing at a *different copy of the
+same class name* on the other — its identity check raises `ValueError`.
+PR #501 fixes the symptom by overriding
+`CustomObjectDeleteView._get_dependent_objects` to filter through-table
+entries out of the collector's dependency walk before the identity check
+runs. This plugin does not override delete or model caching and cannot
+patch the bug from its own code.
+
+#### Cosmetic follow-up on patched builds
+
+On builds that already contain PR #501, the delete-success toast for
+some dynamic models renders as `"Deleted <Type> <Type> None"` — the
+patched view reads `str(obj)` *after* the row's deletion, so the
+dynamic model's primary field returns `None`. Models whose `__str__`
+captures the display value before delete are unaffected. This is a
+cosmetic, post-fix upstream issue; it does not affect the delete
+itself.
 
 ## Support
 

netbox_custom_objects_tab/__init__.py

@@ -33,6 +33,25 @@ class NetBoxCustomObjectsTabConfig(PluginConfig):
 
     def ready(self):
         super().ready()
+
+        # Hard gate: require netbox-custom-objects >= 0.5.0. We probe behaviour
+        # (the `is_polymorphic` model field added in 0.5.0) rather than parsing
+        # a version string, because forks and pre-release tags can carry any
+        # version label but either have or lack the field we actually use.
+        # Raising ImproperlyConfigured here aborts NetBox startup with a clean,
+        # named error in the logs — preferable to letting a half-loaded plugin
+        # ImportError mid-request.
+        from django.core.exceptions import FieldDoesNotExist, ImproperlyConfigured
+        from netbox_custom_objects.models import CustomObjectTypeField
+
+        try:
+            CustomObjectTypeField._meta.get_field("is_polymorphic")
+        except FieldDoesNotExist as exc:
+            raise ImproperlyConfigured(
+                "netbox-custom-objects-tab 2.4+ requires netbox-custom-objects>=0.5.0. "
+                "Upgrade with: pip install -U 'netbox-custom-objects>=0.5.0'"
+            ) from exc
+
         from . import template_override, views
 
         template_override.install()

netbox_custom_objects_tab/views/combined.py

@@ -3,6 +3,7 @@
 from urllib.parse import urlencode
 
 import django_tables2 as tables2
+from django.apps import apps
 from django.contrib.contenttypes.models import ContentType
 from django.core.paginator import InvalidPage
 from django.shortcuts import get_object_or_404, render
@@ -43,24 +44,71 @@ class Meta(BaseTable.Meta):
 
 
 def _iter_linked_fields(instance):
-    """Yield (field, model, filter_kwargs) for every CO field referencing instance."""
+    """
+    Yield (field, model, filter_kwargs) for every CO field referencing instance.
+
+    Handles both non-polymorphic fields (single related_object_type FK) and
+    polymorphic fields (related_object_types M2M + is_polymorphic, introduced
+    in netbox-custom-objects 0.5.0). Mirrors the query shape in upstream's
+    CustomObjectLink.left_page so behaviour stays consistent with the
+    upstream "Custom Objects linking to this object" card.
+    """
     content_type = ContentType.objects.get_for_model(instance._meta.model)
-    fields = CustomObjectTypeField.objects.filter(
+    type_choices = [CustomFieldTypeChoices.TYPE_OBJECT, CustomFieldTypeChoices.TYPE_MULTIOBJECT]
+
+    # is_polymorphic=False keeps the two querysets disjoint — a row with
+    # related_object_type set AND is_polymorphic=True (a legacy misconfig:
+    # is_polymorphic is immutable upstream but related_object_type isn't
+    # nulled when toggled) would otherwise be yielded twice.
+    non_poly = CustomObjectTypeField.objects.filter(
         related_object_type=content_type,
-        type__in=[CustomFieldTypeChoices.TYPE_OBJECT, CustomFieldTypeChoices.TYPE_MULTIOBJECT],
+        is_polymorphic=False,
+        type__in=type_choices,
     ).select_related("custom_object_type")
 
-    for field in fields:
+    poly = CustomObjectTypeField.objects.filter(
+        related_object_types=content_type,
+        is_polymorphic=True,
+        type__in=type_choices,
+    ).select_related("custom_object_type")
+
+    for field in list(non_poly) + list(poly):
         try:
             model = field.custom_object_type.get_model()
         except Exception:
             logger.exception("Could not get model for CustomObjectType %s", field.custom_object_type_id)
             continue
 
         if field.type == CustomFieldTypeChoices.TYPE_OBJECT:
-            yield field, model, {f"{field.name}_id": instance.pk}
+            if field.is_polymorphic:
+                yield (
+                    field,
+                    model,
+                    {
+                        f"{field.name}_content_type_id": content_type.id,
+                        f"{field.name}_object_id": instance.pk,
+                    },
+                )
+            else:
+                yield field, model, {f"{field.name}_id": instance.pk}
         elif field.type == CustomFieldTypeChoices.TYPE_MULTIOBJECT:
-            yield field, model, {field.name: instance.pk}
+            if field.is_polymorphic:
+                try:
+                    through = apps.get_model(_CUSTOM_OBJECTS_APP, field.through_model_name)
+                except LookupError:
+                    logger.exception(
+                        "Could not resolve through model %r for polymorphic field %s",
+                        field.through_model_name,
+                        field.pk,
+                    )
+                    continue
+                source_ids = through.objects.filter(
+                    content_type_id=content_type.id,
+                    object_id=instance.pk,
+                ).values("source_id")
+                yield field, model, {"pk__in": source_ids}
+            else:
+                yield field, model, {field.name: instance.pk}
 
 
 def _get_linked_custom_objects(instance):