Custom admin views (ModelAdmin.get_urls / AdminSite.get_urls) are unreachable in the SPA

[martin-castro-laminr-ai]

Problem (swap blocker)

The package exposes a fixed JSON API surface (api/urls.py:84-176) + an SPA catch-all (urls.py:55). Nothing introspects ModelAdmin.get_urls() / AdminSite.get_urls(), and the registry payload (registry.py:133-221) emits only model metadata + the four permission booleans. A consumer who adds bespoke admin pages — custom change-form buttons, report / import-export views, dashboards — via get_urls() (a very common admin extension) has no way to reach or render them from the SPA. For shops that rely on custom admin views, this blocks a full swap.

Direction

Surface the consumer's extra admin URLs (those in get_urls() beyond the standard CRUD routes) so the SPA can link out to them — open the legacy-rendered page (Django's own admin templates) in a new tab/iframe, or expose a per-model / index "custom views" menu. A link-out is enough to unblock; full SPA rendering of arbitrary custom views is out of scope.

Where

api/urls.py, api/registry.py (expose custom-view links), urls.py catch-all.

Acceptance

• A consumer's custom admin view is reachable from the SPA (linked), not orphaned.

[martin-castro-laminr-ai]

Elevation — this is the actual object-actions blocker for custom-view admins

Validated against a live action-heavy consumer: its operational object actions (reprocess / regenerate / cache-clear / etc.) are implemented via custom get_urls() views + custom change-form object-tools templates — not django-object-actions (which isn't even a dependency; 0/86 models use change_actions). So for that consumer, #439 — not #236 — is the operational object-actions blocker.

Design implication: surfacing object actions can't rely solely on change_actions (see #236/#427 for that path). It must also cover custom change-page tools / custom get_urls() routes — e.g. expose the consumer's extra admin URLs + any per-object tool links so the SPA can link out to (or render) them. This is a top operational swap blocker for admins built on custom view/template patterns (a very common shape).

[martin-castro-laminr-ai]

Design options for surfacing custom admin views / object tools (for a human to pick)

This blocker has a real architectural fork. Three approaches, with tradeoffs:

A. Link-out (transition bridge) — lowest effort.
Backend introspects each ModelAdmin.get_urls() / AdminSite.get_urls() and exposes the extra routes (beyond standard add/change/changelist/delete/history) in the registry + detail payload as {name, label, url}. SPA renders them in a "Custom views / More" menu that opens the Django-rendered page (new tab).

• Pros: small; unblocks daily ops immediately.
• Cons: requires the legacy /admin/ (templates) to stay mounted, so it's a migration bridge, not a full legacy removal. Per-object change-page buttons that live only in custom change-form templates still aren't auto-discoverable (only their URL is).

B. Iframe embed — medium effort.
Same backend introspection; SPA embeds the Django-rendered custom view in an iframe inside the shell.

• Pros: feels in-app; still no SPA re-implementation.
• Cons: styling/theme mismatch, CSRF/nav/height quirks, still needs legacy templates.

C. Package-native object-actions/views API — highest effort, true full swap.
A small opt-in convention the consumer declares (e.g. a dar_object_actions / dar_change_views attribute, or wrap django-object-actions #236 under the same umbrella) listing object actions + custom views the SPA renders natively (button → async run / route).

• Pros: real full swap, clean SPA UX, no legacy templates.
• Cons: requires consumers to migrate custom-template object-tools to the convention.

Recommendation: land #236 (django-object-actions, drafted in #427) + a package-native registration (C) as the long-term path; ship A (link-out) now as the transition bridge for arbitrary get_urls views that can't be auto-rendered. Important caveat for a full legacy-admin removal: object actions defined purely in custom change-form templates are not programmatically discoverable — those consumers must adopt #236 or (C) to expose them.

I can draft A (backend introspection + link-out) as a human-review PR (it's a Tier-5/6 contract addition) on request — it's design-safe and reusable under B/C too.

[martin-castro-laminr-ai]

Option A (link-out) implemented as a human-review draft: PR #465. Backend introspection of get_urls() custom routes + {name,label,url,level} payload + DetailPage link-out UI; 11 tests, full suite 505 pass; no new permission surface; graceful degradation. It's the design-safe foundation (the same payload powers a future iframe/native approach). Needs a human to (a) decide Option A vs iframe/native, (b) land the Tier-5 docs/api-contract.md additions, (c) merge.

[MartinCastroAlvarez]

Closed by #539 (merged): ModelAdmin custom views surfaced on the detail response as a typed list, rendered as link-outs on the detail page (Option A).