Django Admin actions configurable as buttons in the change view's object tools

[benjaoming]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

In this feature proposal, we utilize Django 6.1's new admin.action() decorator's location parameter (see docs) to add a choice for actions to be displayed as buttons on the change view, rather than the current drop down. Location options will thus be:

• location=ActionLocation.CHANGE_LIST (current)
• location=ActionLocation.CHANGE_FORM (current)
• location=ActionLocation.OBJECT_TOOLS (NEW!)

The new action buttons are located together with other object tools (the pill-shaped buttons).

Bulk actions continue to be the default, while single object actions are a configurable non-default behavior, meaning that the proposal is backwards compatible.

Thanks to people at the DjangoCon Europe 2026 sprints who took time to discuss this with me 💚

References:

• https://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#admin-action-availability
• This is a concrete proposal to implementing #12090 Show admin actions on the edit pages too
• An alternative discussion and PR emerged from the forum post
  Admin-Actions also in the object details view from 2023.

Problem

Django Admin only supports actions on the list view, or as a dropdown+button on the change form (which takes up space on the screen and adds more clicks than necessary). But with the addition of django/django#16012, we opted for new future action options to be added.

Evidence of the significance of the problem is seen from all the packages providing this functionality in various ways.

Request or proposal

proposal

Additional Details

• The current implementations for deleting single or multiple objects may be unified under this new definition. This could be explored subsequently.
• I suggest we leave this outside of the scope: If the action button is clicked on an unsaved/dirty change form, we might want to warn the user of losing unsaved changes.
• Button design hasn't been discussed. Should they appear in a separate row? Have a separate color? CSS class names?
• Confirmation is a universal issue for all actions: However, with a single-click button it becomes even more critical. By adding this feature, we should be aware that the avenue of a confirmation step might need to be explored subsequently.

Implementation Suggestions

(the proposal was modified and has only 1 suggestion)

Suggestion 1: CHANGE_FORM and OBJECT_TOOLS make no sense in combination

In this suggestion, we utilize a very simple logic: If you've added the action as a button, you probably don't want it in a drop-down at the same time.

Thus, we can distinguish between description and description_plural to create a meaningful short button label:

@admin.action(
    location=[ActionLocation.OBJECT_TOOLS, ActionLocation.CHANGE_LIST],
    description="Publish",
    description_plural="Mark selected stories as published",
)
def make_published(self, request, queryset):
    queryset.update(status="p")

Updates

• 2026-06-30: Updated to match the new location option introduced in 6.1

[github-actions]

Thank you benjaoming for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[parisk]

Great proposal.

This is relevant to us already. Right now we are implementing this downstream for every Django project that we implement, because we are reluctant to install an extra package for this functionality.

A few thoughts on UX

Top-positioned buttons

Positioning the action buttons on the top needs a bit of extra care. Right now the only top positioned buttons (history, view on site) are explicitly read-only. Actions on the contrary can (and usually do) write on the database. A visual distiction between these two kinds of function would be useful.

Form state

Clicking an action is not (?) expected to store any changed state of the form (e.g. clicking on "Approve" after changing the title of a blog post). Users who change the form and then click on an aciton they might need to be notified that their changes will probably be lost. On the flip side of the comment above, placing the action buttons on the top already facilitates this, since the user sees the buttons first and then the form. This was already brought up by. @benjaoming during the sprints discussions.

If needed, we are happy to commit resources to the implementation of this feature.

[benjaoming]

UX

Amazing inputs: 1) There are problems about distinguishing the buttons from normal navigation, 2) Mis-clicks can cause issues since it's just 1 button click, 3) form data isn't saved (previously noted as out of scope)

I did wonder about distinguishing the buttons. Here are some options we discussed at the sprints:

1. Put action buttons in their own row.
2. Change their color.
3. Add optional confirmation dialog (to avoid mis-clicks).
4. Encourage users (via docs examples) to add icons to the label: For instance, one of the FontAwesome icons available (or an emoji?).

NB! They don't exclude each other - can do all of them.

Comments gathered:

1. Put action buttons in their own row: It doesn't solve mis-clicks, it gives a little bit extra distinguishability, but not a big thing
2. Colors of buttons: Some accessibility issues, if relying only on color, can it be solved?
3. Optional confirmation dialog: YES, this would be a big feature addition, especially since extra guidance can be added as a supplement to shorted labels, both in buttons and the current drop downs.
4. Icons: We didn't have time to talk about it.

Direction: Add a confirmation step

Does the proposal almost definitely need to add a confirmation step as default behavior for a single object actions? Please add 👍 👎 on this comment to weigh in.

[benjaoming]

Future trajectory / out of scope

• Firstly, it should be noted that there's a lot of potential improvements that this opens up for. So it would be nice if we can separate out the suggestions that are critical for the proposal to move forward (currently, that means to discuss if a confirmation step is critical or not).

• Secondly, notice that the action_type option is designed to open up for new types of actions that can be suggested in the future, or a way for apps and projects to define how they will render and handle self-defined action types.

[James-Osgood]

I suggest not adding a JavaScript confirmation. While useful, it seems outside the scope of this proposal. Whether the action has a confirmation step like the Delete action is up to the author of the action.

[jacobtylerwalls]

Something very similar is already close to landing in django/django#16012, using the same dropdown instead of pill buttons.

[benjaoming]

@jacobtylerwalls yes, thanks for the cross-reference 👍 this was known at the time of the feature suggestion - forum thread (related to the PR) and Trac issue are both linked. I wouldn't use the word "similar" here.. It's certainly addressing the same problem, but it quickly jumped into quite a different solution. In terms of UX, configurability and future options, I'd encourage we re-do design in this issue and implement it again.

[sarahboyce]

We should aim for an agreement on the API within django/django#16012 as we shouldn't introduce new fields we aim to deprecate.

The current proposed API is:

 @admin.action(
    permissions=["publish"],
    description="Publish",
    description_plural="Mark selected stories as published",
    show_on_change_form=True,
)
def make_published(self, request, queryset):
    queryset.update(status="p")

However, I quite like the suggestion of action_type rather than show_on_change_form. I don't think that's a big change to incorporate in the current PR.
I am not currently convinced having bulk_label and single_label is better than description and description_plural as this mirrors verbose_name verbose_name_plural and would avoid needing to deprecate description which has been used a long time.

I hope that after django/django#16012 this is reduced to a request to have this rendered as buttons/make it easy to customize the UI

[benjaoming]

I did not see that django/django#16012 had new activity almost exactly when I started this design work. That's unfortunate! @sarahboyce @mgaligniana pinging you because of this, I'd like to hear your thoughts on an alternative proposal.

[benjaoming]

@sarahboyce that's brilliant, if we can use action_type from the beginning, we can keep the description and description_plural options, I agree they align well 👍

[benjaoming]

I can update the feature description to anticipate django/django#16012 and build on top of that.