Detail page: action affordances missing (object History link, save-flow buttons, custom object actions)

[MartinCastroAlvarez]

Report

On the SPA detail page (laminr packages.loanpackage), the action buttons are missing relative to Django admin's change view. The SPA currently shows only Edit + Delete (top-right). Django admin's change page additionally offers:

1. Object History link (top-right) — the per-object change log. The backend history endpoint already exists (tests/test_history.py); the SPA detail page does not link to it.
2. Save-flow buttons in edit mode — Save, Save and continue editing, Save and add another, Save as new. The detail response already carries the save_options block (tests/test_detail.py::test_detail_includes_save_options_block), but the SPA EditForm renders only Save / Cancel. This half is tracked by Save flow buttons — Save / continue / add another / save as new (Django admin parity) #154 — this issue cross-links it for the detail-page surface.
3. Custom object-level actions — ModelAdmin change-form tools / object actions (where present) are not surfaced.

Scope

Frontend (@dar/details / apps/web DetailPage), metadata-driven only — drive every affordance off data the API already returns (save_options, permissions, history availability). No hardcoded model knowledge.

Acceptance

• Detail read view shows a History link when the model has history, gated by permission.
• Edit mode renders the full save-flow button set from save_options (dedup with Save flow buttons — Save / continue / add another / save as new (Django admin parity) #154; this issue tracks the detail-page wiring).
• Buttons honor the permissions block (no Save without change perm, no Delete without delete perm, etc.).

Source

Maintainer report (2026-05-27) with screenshot: detail page for Test Loan Package — Settings Stable.

[martin-castro-laminr-ai]

Customer parity note (live review): the detail page currently shows only Edit / Delete / History. Custom object-level action buttons defined on the ModelAdmin — the per-object actions that appear on the standard change page (e.g. via django-object-actions change_actions, or buttons injected by a custom change template) — are not rendered at all.

Requirements for the custom-object-action half of this issue:

• Render the model's object-level actions as buttons on the detail page (next to Edit/Delete).
• Run them asynchronously via the API (POST to a single-pk action endpoint) and do NOT full-page redirect. Stay on the detail page; on success re-fetch the object payload and show a success/error toast.
• Gate each action by its permission (coordinate with Security (LOW): custom actions gate on has_change_permission only — honour action.allowed_permissions? #302 re: allowed_permissions).

[MartinCastroAlvarez]

Done — acceptance criteria met on main:

• History link: DetailPage shows a History button in the read view that opens the @dar/history modal (consumes the /history/ endpoint, which enforces its own permission server-side).
• Save-flow buttons: edit mode renders the full set (Save / Save and continue / Save and add another / Save as new) driven by the save_options block (Save flow buttons — Save / continue / add another / save as new (Django admin parity) #154).
• Permission-honoring: Edit/Delete/Save are gated by the permissions block.

The third report item — custom object-level actions — is not in the acceptance list and isn't part of standard django.contrib.admin (it's a third-party pattern, e.g. django-object-actions). If we want it as an SPA enhancement, it deserves its own scoped issue. Closing this one as satisfied.

[martin-castro-laminr-ai]

Confirmed: this is the critical-path blocker for deprecating the legacy admin

Validated against a live, action-heavy consumer admin: the detail payload exposes no object-actions key at all —
['app_label','fields','fieldsets','inlines','label','model_name','password_change','permissions','pk','save_options','view_on_site_url'].
So a consumer whose change pages carry operational object-level actions (reprocess / re-run / regenerate-style buttons, the de-facto django-object-actions change_actions pattern) cannot run any of them in the SPA. Read/CRUD parity is otherwise clean (86/86 lists, 61/61 details, 0×5xx), so for an operations-heavy admin this is the remaining thing that prevents a full swap.

Actionable design (object-level actions half of this issue)

Object-level change-page actions are not in Django's built-in admin — they come from django-object-actions (ModelAdmin.change_actions / get_change_actions(request, object_tools=...)), which is the popular standard. Support it gracefully/optionally (no-op for plain-Django consumers):

Backend

• In the detail view, if the admin exposes get_change_actions/change_actions, build an object_actions: [{name, label, description}] list, each gated by the action's own permission (coordinate with Security (LOW): custom actions gate on has_change_permission only — honour action.allowed_permissions? #302's allowed_permissions). Omit/empty for admins without it.
• New endpoint POST /api/v1/<app>/<model>/<pk>/action/<name>/ that resolves the named change-action via the ModelAdmin, runs it for the single object (django-object-actions calls the method with (request, obj)), and returns {ok, message?, redirect?}. Run server-side; do NOT 302 — if the action returns an HttpResponse/redirect, surface the URL in the body for the SPA to handle, don't follow it.

Frontend (DetailPage)

• Render object_actions as buttons next to Edit/Delete. On click: POST async, show a spinner, then on success re-fetch the detail payload (so computed/readonly fields + status reflect the action) and toast the result. No full-page navigation.

Note: the new endpoint + object_actions in the contract is a Tier 5/6 API-contract change → human review required (per CLAUDE.md / docs/api-contract.md). Flagging for a human author rather than an autonomous auto-merge. This is the highest-leverage remaining parity item for the swap.

[martin-castro-laminr-ai]

Drafting the object-level-actions implementation per the design above as a human-review PR (Tier 5/6 — API-contract change; will be opened as a draft flagged do-not-auto-merge, for a human author/reviewer to take over). Not an autonomous merge.

[martin-castro-laminr-ai]

Validation update (live consumer admin) — important scoping note

I deployed the #427 draft and validated against a live, action-heavy consumer admin. The implementation is correct and works, but it surfaced no object actions there — because that consumer does not use django-object-actions: it isn't a dependency, and 0 of 86 registered models have change_actions / get_change_actions. Their operational change-page buttons (reprocess / regenerate / etc.) are custom — get_urls() views + custom change-form object-tools templates (via a base class).

Implication:

• feat(api): object-level change-page actions (#236) — DRAFT, human review required #427 remains valuable for the (many) consumers who do use django-object-actions — please test it against such a project before merging.
• It is not the blocker for consumers that wire object actions via custom views/templates. That path is Custom admin views (ModelAdmin.get_urls / AdminSite.get_urls) are unreachable in the SPA #439 (custom admin views). Broad object-action parity needs both.