Detail page: per-object action buttons reusing the changelist actions API (single-pk runs)

[MartinCastroAlvarez]

Problem

The detail page currently exposes History / Edit / Delete, but no admin-action buttons — so an admin's `actions = […]` is reachable from the changelist (bulk) but not from the detail of a single object. A user looking at one record can't run the same action on just that record without going back to the list, selecting the single row, and dispatching from there.

Expected

The detail page surfaces the model admin's standard `actions` as buttons (alongside History / Edit / Delete), reusing the same actions API the changelist uses — just sending a single pk (the current object) instead of the multi-pk array.

• Same wire endpoint as the bulk action runner (`POST //actions//`).
• Same permission gate (`get_actions(request)` re-resolved server-side per action).
• Same `message_user` / redirect / intermediate-response handling already wired in the changelist runner — so an action that returns an HttpResponse opens it in a new tab here too (the Actions: support intermediate / form-returning admin actions (not just instant runs) #250 minimum).
• Confirmation modal (`requires_confirmation`) and the single-pk count ("Run X on 1 selected item?") both work.

Out of scope

• Object-level change-page actions (django-object-actions `change_actions`) are a separate concern, already covered by Detail page: action affordances missing (object History link, save-flow buttons, custom object actions) #236/feat(api): object-level change-page actions (#236) — DRAFT, human review required #427 — those are admin-declared per-instance actions. This issue is about the standard `ModelAdmin.actions` (the same ones the changelist runs) becoming reachable from the detail page over a single pk.

Acceptance

• Each action declared in `ModelAdmin.actions` (and permitted for the request) renders as a button on the detail page.
• Clicking it runs the action endpoint with a one-pk array; the result flow matches the changelist (`message_user`, toast, redirect-in-new-tab on intermediate response).
• Buttons hidden when the model has no actions or the user has no `change` permission.

[MartinCastroAlvarez]

Re-opening — laminr pilot is still seeing this on react 1.0.0. Tracking as pending work the agent can pick up.

[MartinCastroAlvarez]

Clarification from the laminr /admin2/ pilot (react 1.0.0):

Actions registered via the modern @admin.action(description=...) decorator (not just the static ModelAdmin.actions = [...] list) are not surfacing on the detail page. The agent should resolve actions the same way Django's changelist does — via model_admin.get_actions(request) — which already returns both:

• callables listed in ModelAdmin.actions = […]
• functions decorated with @admin.action and bound on the admin class

…and then re-validate the action name server-side per request. The single-pk run flow + the rest of the issue's acceptance criteria stay the same.

[MartinCastroAlvarez]

Further observation (laminr /admin2/ pilot on react 1.0.0):

The detail page currently shows the changelist bulk-action buttons (with their multi-select labels: Delete selected files, Disable All Selected Files, Reprocess selected files, Clear parser cache for selected files, …). What's missing is the per-object actions the admin declares — handlers intended to act on the single current object, not on a selection.

Two things the agent should cover:

1. Per-object surfacing — actions declared via @admin.action (or any other ModelAdmin per-object hook the consumer wires up) need to surface on the detail page even when they're not present in the actions = […] list (which is the changelist's bulk surface). The detail view should consult get_actions(request) AND any change_actions / per-object action hooks the ModelAdmin exposes, and render the union.

2. Single-object labelling / semantics — when an action is rendered on the detail page, its button should run with the single current pk and the action's confirmation/result handling should match the single-object framing (a {count} of 1 etc.). Bulk-style labels like Delete selected files are fine to reuse mechanically, but the agent should consider also offering admins a way to declare per-object descriptions (out of scope for v1 — the minimum is just surfacing them at all).

[MartinCastroAlvarez]

Already shipped in v1.0.0 — merged in PR #562 (commit c74e252): per-object action buttons on the detail page reuse the changelist actions API for single-pk runs (supports requires_confirmation, message_user toasts, intermediate-redirect-in-new-tab).