Opened 8 years ago

Last modified 3 years ago

#18665 new New feature

Allow registering custom admin views with the admin's index

Reported by: Frank Wiles 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 Jannis Leidel)

I wrote django-admin-views recently ( 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

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.

Change History (7)

comment:1 Changed 8 years ago by Jannis Leidel

Description: modified (diff)
Triage Stage: UnreviewedAccepted

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 8 years ago by Julien Phalip

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 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.


comment:3 Changed 8 years ago by Frank Wiles

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 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 8 years ago by Frank Wiles (previous) (diff)

comment:4 Changed 8 years ago by Alex Gaynor

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 8 years ago by Frank Wiles

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 files and get_urls() in admin classes. User would 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 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 8 years ago by Amirouche

cf. #16213

comment:7 Changed 3 years ago by Tim Graham

Summary: Making it easier to customize Django AdminAllow registering custom admin views with the admin's index

I retitled this ticket to reflect idea 1. #28506 was a duplicate and pointed out the django-adminplus package. "AdminPlus allows you to add simple custom views (well, they can be as complex as you like!) without mucking about with hijacking URLs, and providing links to them right in the admin index."

Probably the other ideas should have their own tickets if they are still relevant.

Note: See TracTickets for help on using tickets.
Back to Top