How to Add Custom Action Buttons to Django Admin

For a better reading experience, check out this article on my website.

We are big fans of the Django admin interface. It’s a huge selling point for Django as it takes the load off developing a “back office” for support and day to day operations.

In the last post we presented a pattern we use often in our Django models. We used a bank account application with an Account and account Action models to demonstrate the way we handle common issues such as concurrency and validation. The bank account had two operations we wanted to expose in the admin interface — deposit and withdraw.

We are going to add buttons in the Django admin interface to deposit and withdraw from an account, and we are going to do it in less than 100 lines of code!

What Does it Look Like?

Our custom actions are the nice looking deposit and withdraw buttons next to each account.

Why Not Use the Existing Admin Actions?

The built-in admin actions operate on a queryset. They are hidden in a dropbox menu in the top toolbar and they are mostly useful for executing bulk operations. A good example is the default delete action — mark as many rows as you like and hit delete — this is not our case.

Another downside of using Django actions is that the actions are not available in the detail view. To add buttons to the detail view you need to override the template — a huge pain and usually not worth it.

The Forms

First thing first — we need some data from the user to perform the action so naturally, we need a form — one for deposit and one for withdraw.

In addition to performing the action we are going to add a nifty option to send a notification email to the account owner informing him about an action made to his account.

All of our actions have common arguments (comment, send_email) and they handle success and failure in a similar way.

Let’s start with a base form to handle a general action on the account:

So what do we have here:

  • Every action has a comment and an option to send a notification if the action completed successfully.
  • Similar to a ModelForm, we execute the operation in the save function.
  • The caller must specify the user executing the action for logging and audit purposes.
  • We raise NotImplementedError for required properties to make sure we get a nice error message if we forget to override them.
  • We used a base exception in our models so we can catch all account related exceptions and handle them appropriately.

Now that we have a simple base class let’s add a form to withdraw from an account. The only additional field is the amount to withdraw:

Pretty straight forward:

  • We added the additional field (amount) with the proper validations.
  • Provide the required attributes (email body template).
  • Implemented the form action using the classmethod from the previous post. The method takes care of locking the record, updating any calculated fields and adding the proper action to the log.

The deposit action has additional fields — reference and reference type:


The Admin

Before we add fancy buttons we need to set up a basic admin page for our Account model:

Side Note: We can make the list view much better — add a link to the user and to the account actions, add search fields and many more but this post is not about that. I previously wrote about performance considerations in the admin interface when scaling a Django app to hundreds of thousands of users and there are some nice tricks there that can make even this simple view much nicer.

Adding the Action Buttons

We want to add action buttons for each account and have them link to a page with a form. Luckily, Django has a function to add URL’s so let’s use it to add the routes and corresponding buttons:

We render two buttons, each linking to a view that executes a corresponding process_deposit/withdraw function. The two views will render an intermediate page with the relevant form. When the form is submitted the view will redirect back to our detail page or inform the user of an error.

A nice feature of using the account_actions field is that it is available in both the detail and the list view because it’s a regular field in the admin.

The function that handles the actual action:

We wrote a function called process_action that accepts the form, the title of the action and the account id, and handles the form submission. The two functions, process_withdraw and process_deposit, are used to set the relevant context for each operation.

There is some Django admin boilerplate here that is required by the Django admin site. No point in digging too deep into it because it’s not relevant to us at this point.

Only thing left to do is to add the template of the intermediate page containing the form. Once again, no need to work too hard — Django already has a detail page template we can extend:

This is it!

Staff members can now easily deposit and withdraw directly from the admin interface. No need to create an expensive dashboard or ssh to the server.

I promised we will do it in 100 lines and we did it in less!



Big parts of the implementation are taken from the excellent (excellent!) package django-import-export. It saved us hours of “Can you just send me the data in Excel?” and we love it for it. If you are not familiar with it you should definitely check it out.

Where Can We Take It From Here

Now that we nailed this technique we can pretty much do whatever we want with it — we have total control over the route and what’s being rendered. It’s also possible to add buttons for action that don’t require additional data without the intermediate page.

The next step would be to abstract this functionality and put in a mixin, but, we will cross that bridge when we get there.

Full Stack Developer, Team Leader, Independent. More from me at