Code

Opened 21 months ago

Last modified 16 months ago

#18665 new New feature

Making it easier to customize Django Admin

Reported by: frankwiles Owned by: nobody
Component: contrib.admin Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: yes

Description (last modified by jezdez)

I wrote django-admin-views recently (https://github.com/frankwiles/django-admin-views) based on suggestions from Julien Phalip and Jacob Kaplan-Moss they would like to see this be included into the admin.

Specifically I would like to add the following abilities:

1) Easily link up custom admin views to admin:index

2) Include reverse()-able links and off site URLs to admin:index on a per app basis (i.e. defined by the app's admin.py)

3) Include blocks in admin:index to customize the displaying of each app block

4) Ability to define the sort order of the apps manually. Give the user full control or if they just define 2 of 10 apps put the defined 2 at the top in their order and alphabetize the remaining apps to ensure no apps are missing due to not including them in this setting. Would obviously continue to default to alphabetical by app name.

I'm willing to do the work on this and Julien has offered to help mentor/work me through the process.

Attachments (0)

Change History (6)

comment:1 Changed 21 months ago by jezdez

  • Description modified (diff)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Accepting this in general since I've also had those problems and used django-admin-tools to solve it. I like the simplistic proposals you made to extend the ModelAdmin.

But, I think at least 3 and 4 are separate issues that should have their own ticket as they can easily be implemented without waiting for the "custom view" feature to be implemented. I'm not entirely happy about introducing yet another name next to AdminSite and ModelAdmin/InlineModelAdmin and would suggest to add the features to ModelAdmin directly.

comment:2 Changed 21 months ago by julien

I completely agree with Jannis' review. I too would prefer to keep the work on adding custom views/urls and on customizing the admin dashboard's template in two separate tickets.

Regarding the custom views, my only concern is that the approach in django-admin-views seems to tie the views to ModelAdmin. If an app has no models of its own, then there wouldn't be any easy way to create such custom views.

I haven't used django-adminplus, but the approach there looks a bit different as it ties the custom views to AdminSite. However, in the django-admin-views README you say: "There are several third party project such as AdminPlus, but they require the user to redefine the Admin.site object. This is fine for developers who are setting up a Django project, but not ideal for developers who are writing third party tools for other developers to use in their projects."

Could you explain further the limitations of that approach based on your experience?

Ideally I'd like to find a way to easily add custom views to the admin, but without necessarily relying on the presence of models.

Thanks!

comment:3 Changed 21 months ago by frankwiles

Sounds good to me on #3 and #4, I'll make those separate tickets.

As for the problem with AdminPlus is if I'm writing a reusable app and others use it. If I wanted to add custom views to say my django-app-metrics project, I can get the URLs mapped to views no problem, but I can't display the links without forcing the user to use a sub-class of Admin.site or messing with the templates. Add in another app that might want to do the same thing and you likely cannot have both at the same time working.

I'm not looking to add another name next to AdminSite, ModelAdmin, etc. but instead build this functionality into them so they can be picked up, detected, and rendered using the normal classes. Akin to list_display for ModelAdmins and perhaps a concept of a "AppAdmin" or other standardized way of discovering app level links/views for applications that do not have models. Definitely open to suggestions!

Last edited 21 months ago by frankwiles (previous) (diff)

comment:4 Changed 21 months ago by Alex

Having some sort of AppAdmin sounds sane to me, we kind of have that now except it's not exposed and it's just a dict (IIRC) on the AdminSite. Basically being able to provide custom groupings of ModelAdmin and the hooks you're designing, with the default being an AppAdmin per django-app. But don't name it AppAdmin, because that's not really what it is.

comment:5 Changed 20 months ago by frankwiles

Been looking over the admin internals to get started in ernest on this. Before I lay down a bunch of code, wanted to get a double check on my design ideas. My plan is to:

  1. Create a AdminLink base class that will allow apps without models to define links that appear on admin:index. It will give the user a place to define the admin_links tuple. I think 'admin_links' is a better name here than 'admin_views' I was using in django-admin-views. Don't want to use 'admin_urls' to avoid confusion between urls.py files and get_urls() in admin classes. User would admin.site.register() their instances of AdminLink classes and they would appear in app order by default. This will require a bit of complication to register() that might not be the cleanest, open to the idea of admin.site.register_app_links() or something like that if you all feel it would be better.
  1. ModelAdmins could then also define an 'admin_links' tuple exactly as the same as django-admin-views.

Looking for feedback so let me know how this plan sounds. Thanks!

comment:6 Changed 16 months ago by abki

cf. #16213

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.