This is the same problem I have with most ORM's as well: the easy stuff is easy, and the hard stuff is harder than just doing your own thing (using SQL directly). My solution to this ORM problem and the admin situation is the same: use admin (and ORM) for doing easy things, and don't use it for hard things. It works well!

I've seen a lot of Django codebases where they try to build the whole app around the admin interface, and it's way more trouble than it's worth. Reasonable people could disagree about this, but my stance is to use it for the easy goodness it provides, but get away from it when it starts getting in the way.

With the ORM though there is usually a good reason for why the hard things are hard, and writing your own SQL where needed adds very little friction.

With the admin adding a button to kick off some task should be trivially easy, but for whatever reason involves either using all sorts of terrible hacks that make the codebase completely unreadable, or else creating an entire second admin. That doesn't feel right.

Those two particular customisations should be a lot easier to do, and it might even be something I'll look to implement as a 3rd party library or directly within Django.

https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#dj...

https://groups.google.com/d/topic/django-developers/Vozu6U3g...

My understanding is it's not something they care enough about yet to fix - or it's too hard/expensive.

UPDATE: Also found this blog post from one of the core devs/founders:

https://jacobian.org/writing/so-you-want-a-new-admin/

This matches my experience. I can't escape the feeling that 90% of that complexity is irrelevant at best, and counterproductive at worst, for my current use-case -- but I haven't quite mustered the bravery to write my own custom admin site for my app.

I wonder if DRF's CoreAPI schemas would make this easier, since you can now auto-generate a JS client for your API models, so you just need to wire up routers and views for your CRUD.

Also, I think the admin traditionally has been a good driving force for feature improvement.

If you have a complicated application then you should be building your own admin interface, with specialised workflows that make it easy for your (admin) users to enter and manipulate the data you wish to manage.

If you want to add a custom action to the instance view of one of your models you have to:

- write a view for your custom action

- override the generated urls for the model admin

- override the template(???) for the admin instance view to show the action

Considering the Admin itself already has the styling in place to add more custom actions, the main issue is that no one has put in place enough infrastructure to make this easier for people.

(Internally we've written a couple helpers for this, though our way of doing thing relies on internal patterns so might not be great for Django itself)

Eventually we built an actual operations/management/sales interface because Django's admin had too much extra stuff and lacked certain things we wanted to implement, but it wasn't that difficult to put together and it worked well for several months.

[0] http://djangosuit.com/

The admin is easy; but it's not simple. Behind the simple UI there's a lot of work going on, and a lot of is so that the simple customizations most people work can be done trivially.

Have no shame in making your own templates and views within the admin. That's why it provides those escape hatches.

Django admin is easy to get started with, but a huge pain to extend.

I've always seen the admin as a sort of phpmyadmin. For doing very basic crud.

It's doable. One of the former companies I worked for used to run its entire lead-management-based system on top of a modified 0.96 Django admin, that was ~10 years ago (said company was a mortgage broker). Monkey-patching is a hell of a drug. I'm pretty sure things are way easier to extend now.

In Django, you need to explicitly do some things and that's okay.