[audit] GenericForeignKey / GenericInlineModelAdmin support — verify or document the gap

[MartinCastroAlvarez]

Adoption pain point

I couldn't find any wire handling for `GenericForeignKey` in the API package — no `ContentType`-aware field routing, no `object_id`+`content_type` pair handling.

A consumer with a `Comment` / `Attachment` / `ActivityLog` / `Tag` model that attaches to arbitrary parents via `GenericForeignKey` — the canonical Django pattern for cross-model attachments — probably hits an unsupported field shape.

Per the inline picture: `GenericInlineModelAdmin` is what surfaces "comments on this object" / "attachments on this object" in the legacy admin. If the SPA doesn't render generic inlines, consumers with attachment-pattern models lose every per-object surface that uses them.

What stock Django gets

`django.contrib.contenttypes.admin.GenericTabularInline` / `GenericStackedInline` ship with Django and render exactly like normal inlines. No special wiring required.

Suggested fix

Acceptance:

1. `AccountAdmin` registers a `GenericTabularInline` for `Comment` (where Comment has a GFK to Account).
2. The SPA detail page for an Account renders the Comment inline section.
3. Adding / editing / removing a Comment from the inline writes the correct `(content_type, object_id)` pair.

If GFK is intentionally out of scope, document it prominently and recommend consumers either (a) replace GFK with explicit FKs per parent type, or (b) keep affected models on the legacy admin.

Filed by

Audit triage 2026-05-30.

[MartinCastroAlvarez]

Closed as documented-gap.

Verification: zero GenericForeignKey / GenericRelation / GenericTabularInline / GenericStackedInline references in either django_admin_react or the installed django-admin-rest-api 1.0.6 source (grep). The _FORM_FIELD_TYPE map in api/views/detail.py resolves form field class names to wire types; GFK has no ModelForm field by default, so a ModelAdmin with fields = ("content_type", "object_id") renders the two underlying fields as a plain ForeignKey to ContentType + an IntegerField — NOT as a unified GFK widget.

Same for GenericInline* — they inherit InlineModelAdmin so the inline machinery runs, but no special wire shape merges the FK + object_id pair into a content-aware picker.

Documented in the README's "Stock-Django ModelAdmin hooks that do NOT carry through to the SPA" table (added in #640).

Re-open with a concrete use case if a consumer actually needs unified GFK widget support. Until then, recommended workarounds:

1. Replace the GFK with explicit FKs per parent type (turns a polymorphic relation into N typed relations — clearer + the SPA handles each natively).
2. Keep affected models on the legacy /admin/ surface via LEGACY_ADMIN_URL_PREFIX deeplink.

Splitting up is the more invasive option but yields better SPA UX.