The Django Admin: Basics

Almost everything covered so far — models, views, templates, forms — has been about building TaskFlow's public-facing side, the pages regular users interact with. But someone still needs a way to manage the underlying data directly: fix a task with the wrong due date, remove a spam account, or check what's actually in the database right now. Writing a full set of CRUD views and templates just for internal data management would be a lot of repetitive work — which is exactly what the Django admin exists to make unnecessary.

What the Admin Actually Is

The Django admin is a complete, working web interface for managing your model data, generated automatically from your model definitions — no views, no templates, no forms of your own required. It's one of Django's most genuinely distinctive features: register a model, and within seconds you have a working list page, a working add/edit form, and working delete confirmation, all without writing a single line of view code for any of it.

Creating a Superuser

The admin requires a logged-in account with staff access, and a superuser account has full access to everything in it automatically. Django provides a management command that creates one interactively, prompting for a username, email, and password:

python manage.py createsuperuser

Once it finishes, that account can log into the admin with full permissions over every registered model — remember from Groups & Permissions that is_superuser=True bypasses every individual permission check, which is exactly what makes this account able to manage anything in the admin immediately.

Logging Into /admin/

The admin is available at the /admin/ path of a running project by default, wired up automatically in a new project's URL configuration. Visiting it presents a login form — sign in with the superuser account just created, and you land on the admin's index page, which starts out mostly empty until models are registered with it.

Registering a Model

Registering a model tells the admin "manage this one too." It's done in each app's admin.py file, and it's usually just a single line per model:

# taskflow/admin.py
from django.contrib import admin
from .models import Task, Project, Tag

admin.site.register(Task)
admin.site.register(Project)
admin.site.register(Tag)

Save that file, refresh /admin/, and all three models now appear on the admin index — each one with its own list page, its own add form, and its own edit form, generated entirely from the fields already defined on Task, Project, and Tag.

What You Get For Free

The moment a model is registered, without writing anything beyond that one register() call, the admin gives you:

The @admin.register Decorator

Calling admin.site.register(Task) directly works fine, but Django also offers a decorator form that reads a little more cleanly — especially once you start subclassing admin.ModelAdmin to customize a model's admin appearance, which is exactly the subject of the next lesson:

# taskflow/admin.py
from django.contrib import admin
from .models import Task

@admin.register(Task)
class TaskAdmin(admin.ModelAdmin):
    pass

Both forms register the model identically — the decorator is purely a stylistic preference that pairs naturally with defining a dedicated ModelAdmin subclass right above it, instead of registering the plain model and configuring it somewhere else.

Honestly, the Default Admin Is Bare-Bones

Registered exactly as shown above, the admin works, but it isn't particularly pleasant to use once a table has more than a handful of rows — every column shows up whether it's useful in a list view or not, there's no filtering, and no search box. That's fine for a quick look at your data, but it's usually worth a little customization before you'd want to actually work in it every day. That's the entire subject of the next lesson.