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.
(I do agree though that thumbnail display might be critical for admin, depending on project specifics.)