Opened 15 years ago
Closed 15 years ago
#11895 closed (duplicate)
Grouping and reordering apps on the admin index page
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | contrib.admin | Version: | 1.1 |
Severity: | Keywords: | ||
Cc: | andy@… | Triage Stage: | Unreviewed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
referring to this posting http://groups.google.com/group/django-developers/browse_thread/thread/ea852f1cd590e5ec#, here are the first patches for grouping and reordering apps on the index-page of the admin-interface.
background: currently, the admin index site reflects the structure of your applications/models. I don´t think editors (who use the admin site) are interested in the structure of your project/applications. what they want is the most reasonable list of models, divided into different sections/groups (not necessarily apps).
example: when I´m using djangos auth-app and I´m extending the user-model with a user-profile, I´m having "auth" (with users and groups) and "user" (with user profile) on my admin index page. orderd by names, auth is very much on the top of my page while user is at the bottom. for an editor, this is probably hard to understand (because the editor
doesn´t know anything about apps). for him/her, it´s probably more comfortable having a headline "user management" with the apps "users", "groups" and "user profiles".
Attachments (4)
Change History (7)
by , 15 years ago
Attachment: | screenshot.tiff added |
---|
by , 15 years ago
Attachment: | sites.diff added |
---|
comment:1 by , 15 years ago
one note about this whole issue: I know that this can be done by hardcoding (overriding) the index-template, but I don´t think it´s a nice solution. doing so results in a template with hundreds of "if has perms" for a larger project.
comment:2 by , 15 years ago
Cc: | added |
---|
comment:3 by , 15 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
First off, a minor administrative note - patches should be generated relative to the root of the Django tree, not just a diff of a particular file.
Secondly, as far as I can make out, this can be almost entirely implemented using subclassing and overriding the constructor and the index() method. The only bit that might not be is the insertion of app_label in each app_dict - but that app_dict is keyed by app_label, so I'm not entirely sure I see why that change is required anyway.
Thirdly, this isn't the first time this idea has been proposed - see ticket #7497 - so a new ticket isn't required.
screenshot of the admin index page with groups