Djangocon: Pushing the pony’s boundaries - Ola Sitarska¶

Insides of the admin¶

AdminSite: encapsulates one instance of the django admin pages. If you add /admin to your urls.py, you’re effectively instantiating an AdminSite. Which means you can do it yourself by hand, too. With a different name and different behaviour.

.get_urls() is an important method. It sets up the urls, for instance for login and logout. And it iterates over all registered models, ading urls for them.

There’s also some basic config you can do on AdminSite, like site_title, site_header, index_title.

ModelAdmin: this encapsulates the models and allows you to edit them. It contains all the options and functionality for showing the models. There are a lot of things you can tweak. Look up the full documentation and see the goodness that is available. Some favourites: actions_on_top, fieldsets (handy for grouping fields to make the form more clear), list_display, list_editable (but note that there is a bug report for that, it might be unsafe to edit a list when other people might swap the order around at the same time). radio_fields.

Also very useful: save_as. That gives you a “save as new” button that is handy for making almost-duplicates of existing entries.

ChangeList: you often don’t have to touch this. If you’re modifying it, you’re probably delving a couple of levels too deep.

Magic things¶

There are some tricks that she uses almost always to make the admin more useable and beautiful. As an example, she used the djangogirls website(s): all of them are edited from one single django admin.

One admin and multiple djangogirls workshop organizers? That means permissions need to be set per-event. For this, you can add a get_queryset() method to your ModelAdmin that limits the results to the ones the user is allowed to see. The method gets passed the request, so this is reasonably simple.

For even more customization, you can edit the get_form() method to override certain fields. A dropdown can thus be limited to show only the values the user is allowed to enter. You can do all sorts of adjustments here.

Organizers can now edit only their own events. And… they can only edit future events.

Custom method fields. The list_display list can include method names. You can then write a method with that name that collects the information you need. For example a string with all the organizers and their email addresses.

You can also show images. A def get_logo_display() that returns a bit of html with an image tag. And a line afterwards get_logo_display.allow_tags = True to allow it to output html.

Actions are handy. They’re just a method on the ModelAdmin (show_on_homepage) that is configured as an action.

Don’t fall into the trap¶

• Don’t use the django admin as your user-facing interface. The admin is great for quickly looking at your data. It is fine for someone managing a website. But it is not intended for the generic public.

• Don’t waste too much time trying to customize something. But do make your admins’ lives easier with small quick tricks.

• Make sure your admins can’t break the website with too much power.

Future of the admin¶

There are a couple of efforts to replace/rewrite the admin. None have been succesful yet. The current django admin just works and does a lot well and apparently it is hard to beat! The UI is a bit dated, though.

There is something that might land in a future django version. You can try it out yourself already by installing django-flat-theme.