{"id":75921,"date":"2020-01-20T12:33:13","date_gmt":"2020-01-20T07:03:13","guid":{"rendered":"https:\/\/www.vskills.in\/certification\/tutorial\/?p=75921"},"modified":"2024-04-12T14:17:42","modified_gmt":"2024-04-12T08:47:42","slug":"creating-custom-admin-views","status":"publish","type":"page","link":"https:\/\/www.vskills.in\/certification\/tutorial\/creating-custom-admin-views\/","title":{"rendered":"Creating Custom Admin Views"},"content":{"rendered":"

At this point, anyone looking to add custom behavior<\/em> to Django\u2019s admin interface is probably starting to get a bit frustrated. \u201cAll you\u2019ve talked about is how to change the admin interface visually<\/em>,\u201d we hear them cry. \u201cBut how do I change the way the admin interface works<\/em>?\u201d The first thing to understand is that it\u2019s not magic<\/em>. That is, nothing the admin interface does is \u201cspecial\u201d in any way \u2014 the admin interface is just a set of views (they live in django.contrib.admin.views) that manipulate data just like any other view.<\/p>\n

Sure, there\u2019s quite a bit of code in there; it has to deal with all the various options, field types, and settings that influence model behavior. Still, when you realize that the admin interface is just a set of views, adding custom admin views becomes easier to understand. By way of example, let\u2019s add a \u201cpublisher report\u201d view to our book application from Chapter 6. We\u2019ll build an admin view that shows the list of books broken down by publisher \u2014 a pretty typical example of a custom admin \u201creport\u201d view you might need to build. First, let\u2019s wire up a view in our URLconf. We need to insert this line:<\/p>\n

(r’^admin\/books\/report\/$’, ‘mysite.books.admin_views.report’),<\/p>\n

 before<\/em> the line including the admin views. A bare-bones URLconf might look like this:<\/p>\n

from django.conf.urls.defaults import *
\nurlpatterns = patterns(”,
\n(r’^admin\/bookstore\/report\/$’, ‘bookstore.admin_views.report’),
\n(r’^admin\/’, include(‘django.contrib.admin.urls’)),
\n)<\/p>\n

Why put the custom view before<\/em> the admin inclusion? Recall that Django processes URL patterns in order. The admin inclusion matches nearly anything that falls under the inclusion point, so if we reverse the order of those lines, Django will find a built-in admin view for that pattern, which won\u2019t work. In this particular case, it will try to load a change list for a Report model in the books application, which doesn\u2019t exist. Now let\u2019s write our view. For the sake of simplicity, we\u2019ll just load all books into the context and let the template handle the grouping with the {% regroup %} tag. Create a file, books\/admin_views.py, with this code:<\/p>\n

from mysite.books.models import Book
\nfrom django.template import RequestContext
\nfrom django.shortcuts import render_to_response
\nfrom django.contrib.admin.views.decorators import staff_member_required
\ndef report(request):
\nreturn render_to_response(
\n“admin\/books\/report.html”,
\n{‘book_list’ : Book.objects.all()},
\nRequestContext(request, {}),
\n)
\nreport = staff_member_required(report)<\/p>\n

Because we left the grouping up to the template, this view is pretty simple. However, there are some subtle bits here worth making explicit:<\/p>\n