I've come to treat Django admin as just that: a raw data browser for admin staff. If there's a need for access control or custom display requirements—or anything else Django admin doesn't offer by default—it's a sign that admin site is probably going to be used too often, and simple UIs built for specific use cases deserve consideration. Otherwise too much time might be spent on endless customizations.
(I do agree though that thumbnail display might be critical for admin, depending on project specifics.)
If you write your own custom admin for some models or apps then you've either got to write it for all apps or users will have two inconsistant admin interfaces to deal with with a different UI and feature set between them.
So you decide write a custom CRUD for all apps including all those pesky 3rd party ones. To avoid all that boilerplate you write a few bits of code to introspect models and declaratively customize the interface.
Guess what. You've just reinvented contrib.admin with less features and more bugs.
Learning to customize the admin isn't hard and takes surprisingly little code.
In return you get a single consistant UI for all your code.
I see your point. I'm not against customization. If your admin site is used a lot, you don't really have other choice. However, customizations tend to pile up and become maintenance burden, so personally I prefer to strictly limit use cases for the admin site. Hence, problems listed in original post may signify that the admin site is overused, a higher-level problem that would need to be solved first.
Just a note, the Django authentication system comes with a permissions system that seems[1] well supported by the admin interface (with the notable exception of the AdminSite issue mentioned in the article).
[1] Seems. I've never implemented anything complex around it yet.
Admin does take into account permissions from `django.auth`. However, they aren't very flexible: no per-object access control available by default, for example. Also, anyone not trusted probably shouldn't be able to access admin site anyway, if possible.
Permissions could be useful for quick customization, though—you can hide the apps admin staff certainly won't need to access, and simplify the UI that way.
Funny, because I agree with you about the primary purpose ad the admin being a data browser -- but my biggest complaint about the admin is that it does not have a "view" mode for a record, but only an "edit" mode.
This makes it difficult for browsing, because you can't link to and explore relationships in you data (think of how IMBD works) nor can you tweak the edit page very meaningfully.
There is actually a more or less abandoned contrib app called databrowse, but I don't think it was ever much good. Unfortunately I haven't seen anything to indicate true data browsing is on the horizon for admin.
Well, it appears to me we still somewhat disagree about the nature of use case for admin site—IMO not only Django admin is a data browser, but also a rarely needed one. Admin staff should only have to access it when looking into some problem. In that case lack of view mode probably wouldn't matter much, and fixing other minor inconveniences may not be worth it.
Meanwhile, if there's some ‘legitimate’ use case involving browsing your data—well, Django makes building a dedicated UI for that quick and easy enough. Take class-based list/detail views[0], throw in a couple of templates, and you're done—and the result is easier to customize than the admin site.
This, of course, depends on a project—the amount of maintenance involved, possibility of change in requirements, and other factors.
agreed. it's a nice shortcut for getting data into the system while building the system. but you still have to write UI's for the app. django != drupal.
Lists like these are all well and fine, but there's almost certainly something you can do about them in Django. You can make third party apps that do what you want, it's the best way to prove that it's possible, and to make forward motion, and to scratch your own itch, and to see if people like it. I don't find much value at all in airing grievances about minor annoyances in OSS.
#1. The default ModelAdmin can not, This is totally true. You could overwrite every applicable method until it does for a specific set of models, though I'd gather that this is more trouble than it's worth.
#2. You can restrict permissions to staff members that are not superusers. You do this via the permissions system, either the built-in one or the custom one. It's true that in the default admin.site, staff members can access the index page, but the index page may be empty for them.
#3. With the proper permissions, modules or models are hidden from that user. django-admin-tools gets you the rest of the way to that goal.
#4. There are workarounds as you note, they almost all would require some concession on more third-party libraries in the core, or the possibility of linking a 15MB image to a page.
#5. Solution Noted :)
#6. You could probably subclass ModelAdmin to fix this one. I'd like to see it done, though personally I don't see it as a big deal.
#7. I don't like GFKs, I don't have any strong opinion on their widgets or what could be better, You could make a very detailed widget presumably though
#8. This isn't entirely true, you can use inlines. You could probably hack the normal widgets too to give you an edit button with ?popup=True (not positive about that)
Very nice list! I would add to that a few things I've run across in my own experience:
* customizing the templates is a real pain often requiring a lot of copy-pasta to change just a small thing, particularly the index -- more granular control would be nice (through the use of includes and snippets perhaps): https://github.com/django/django/blob/master/django/contrib/...
* support for custom "admin panels" or the like to display on a dashboard, user-defined widgets that perform actions that go beyond a CRUD style form -- I authored the flask-peewee project that comes with an admin and have used panels for things like provisioning API keys, showing login/signup stats, etc.
* built-in support for exporting records in various formats (also exists in flask-peewee)
Django admin filters aren't as flexible as we sometimes want them to be.
I opened a ticket and would be glad also to fix it (as Rob Pike says something like don't just say about bug, fix it!). But I'd like to have someone from django developers to give me some feedback if it makes sense at all etc.
I agree with the author how much django admin could be better as developers we can fix it, aren't we? ;)
We do a good bit of consulting, building custom websites, and though the Admin is fine for our use, despite considerable effort (granted a while ago) I was never able to get the Admin interface where I wanted for our clients.
It is very similar to the Admin package but a bit more useful I think. If you find yourself hating some of the still existing boilerplate in Django, this might be your ticket.
From my experience with Django (Over 50 websites), using Django Admin with non-technical clients is asking for trouble. Don't get me wrong, it's awesome for prototyping or building the website.. but tweaking it is way too complicated.
You need to alter the style of everything, add new fields, remove fields, use all kind of ugly hacks for simple tweaks.. and at the end, you realise that it would have been so much faster and easier to get that page done from scratch, like you'd do for all the normal pages of the website.
IMO asking for much from the Django admin misses the point of the Django admin. As someone who was in the trenches for over a year stretching and pushing the admin's capabilities, there comes a time when it's just time to prioritize making your own site that does what you need it to.
(I do agree though that thumbnail display might be critical for admin, depending on project specifics.)