Django Admin: внутренний интерфейс редактора

Оглавление курса · Скачать все состояния проекта.

Учебная задача: Зарегистрировать Note в Django Admin и настроить поиск, фильтр и список.

Входное состояние: Снимок lesson-06: список выбирает заметки из базы. Выходное состояние: Модель зарегистрирована в admin, таблица показывает заголовок и дату, есть поиск. Эта глава продолжает «Редакционный стол» — небольшой сайт заметок. Нужны основы Python, HTML и устройство HTTP-запроса. Используем Python 3.12 и Django 5.2.18 LTS; номер ветки выбран для этой серии. Полный каталог lesson-07 в архиве содержит собственные настройки, шаблоны и историю миграций. При самостоятельном прохождении выберите один снимок и отдельную локальную базу; смешивание файлов разных глав меняет договор примера.

Исходники подготовлены редакционным чтением. Зависимости, миграции, сервер и команды работы с данными здесь не выполнялись. Все описанные ответы и изменения являются ожидаемыми, example_execution: not_run.

Редакционный сайт уже умеет читать записи, но пользовательского интерфейса сохранения пока нет. Django Admin предоставляет готовое внутреннее место для работы с моделями. Используем его, чтобы редактор создавал заметки, а публичная страница читала те же записи. Это не замена будущей форме автора: административный интерфейс ориентирован на доверенных сотрудников и устройство данных. Его полезно применять по назначению, не превращая каждый пользовательский сценарий в административную операцию.

В главном списке адресов /admin/ уже подключён. Приложение административной панели и необходимые системные компоненты зарегистрированы в настройках. Теперь надо сообщить панели о нашей модели Note. Файл admin.py загружается для установленного приложения, а декоратор @admin.register(Note) связывает модель с классом NoteAdmin. После самостоятельной подготовки базы и учётной записи ожидается появление заметок в доступном административном списке.

Регистрация и полномочия

Класс NoteAdmin наследует ModelAdmin. Настройки класса меняют представление записей, но не создают таблицу в базе. Ранее модель и миграция отвечали за структуру; сейчас мы описываем рабочее место редактора. Если поле отсутствует в модели, его нельзя просто добавить в list_display и ожидать появления в таблице хранения. Внутренний интерфейс использует уже существующий договор данных.

Для административного входа нужна активная учётная запись с признаком сотрудника и соответствующими полномочиями. Суперпользователь удобен для первого собственного знакомства, потому что имеет полный доступ, однако это не роль каждого будущего автора. Команда createsuperuser упомянута в инструкции архива, но не выполнялась при подготовке. Не считайте наличие ссылки /admin/ доказательством, что в проекте уже есть редактор или настроена политика выдачи прав.

Административный интерфейс использует систему аутентификации Django и стандартные разрешения модели. Разрешение редактировать Note относится к типу модели; оно само по себе не означает проверку владельца конкретной заметки. Позже пользовательская форма ограничит операции текущим автором. Это различие важно: сотрудник редакции и автор публичного кабинета имеют разные задачи, даже если обе роли сохраняют строки в одной таблице.

Список как рабочий инструмент

list_display задаёт столбцы title и created_at. Заголовок помогает узнать запись, дата — выбрать недавно созданную. Полный текст в таблицу не выводим: длинные абзацы сделают список трудным для просмотра. Когда поле статуса появится, добавим отдельный столбец. Рабочий список должен показывать признаки, по которым сотрудник принимает решение, а не все поля модели подряд.

search_fields содержит заголовок и текст. Редактор сможет искать известное слово, даже если оно отсутствует в названии. Поиск не заменяет индексирование и анализ скорости для большой базы. В небольшом учебном наборе его задача — продемонстрировать настройку рабочего инструмента. Не обещайте одинаковую быстроту на миллионе заметок только потому, что конфигурация занимает одну строку. Поведение зависит от числа записей и базы.

list_filter включает дату создания. Это отдельный способ сужения списка, удобный, когда сотрудник помнит период, а не текст. Поиск и фильтр могут дополнять друг друга. Параметры административной страницы не нужно переносить в публичную ссылку списка заметок: это разные маршруты со своими правилами. Публичное представление продолжает использовать QuerySet из предыдущей главы и не получает настройки ModelAdmin автоматически.

От редактирования к отображению

Созданная через Admin запись сохраняется в той же базе, которую читает note_list. Между ними нет отдельной операции копирования HTML. На следующем запросе публичная функция заново построит выборку, шаблон получит модель и сформирует страницу. Пока все заметки видимы публично, потому что поле публикации ещё не введено. Не записывайте в такой учебный экран конфиденциальный черновик; сначала должна существовать явная граница видимости.

Ожидаемый сценарий самостоятельной работы: редактор создаёт третью заметку с заголовком «Подготовка номера», затем открывает публичный список. Новая запись должна находиться выше fixtures, поскольку дата её создания позже. При редактировании тела дата created_at не меняется: она фиксирует создание, а не каждую правку. Если хотите видеть изменение позиции после редактирования, сначала нужно изменить модель временных данных, а не конфигурацию столбца.

Если модель не появилась в панели, проследите регистрацию приложения и импорт класса. Если появилась, но нет прав, исследуйте учётную запись и разрешения. Если сохранение сообщает об отсутствии таблицы, вернитесь к истории миграций. Эти причины удобно различать по тому, на каком этапе цепочки произошёл сбой. Простое повторное создание модели не решает все три ситуации и может затруднить сравнение файлов.

Для самостоятельного задания добавьте id в список столбцов и объясните, почему идентификатор полезен для различения одинаковых заголовков. Затем верните список к компактному виду. При сохранении ориентируйтесь на редакционную задачу, а не на максимальное количество колонок. Следующий урок даст отдельные карточки заметок и адрес по slug. При добавлении адресного поля административный интерфейс поможет заполнять удобные значения.

Разбор связи файлов

Для доступа к панели недостаточно существования пользователя. Django различает активность, статус сотрудника и назначенные права на модели. Обычная регистрация автора, которую добавим дальше, не должна автоматически делать его сотрудником. Панель решает задачи доверенного редакционного персонала, а публичные формы имеют более узкие обязанности.

Настройка list_display определяет колонки, но не добавляет эти поля в таблицу базы. Аналогично search_fields задаёт способ поиска в уже существующих данных. Когда нужно новое сохраняемое значение, сначала меняется модель и история миграций. Такой порядок помогает не искать ошибку схемы в визуальной конфигурации панели.

Ожидаемый список содержит короткий заголовок и дату, поэтому сотрудник может понять, какой материал выбирает. Метод __str__ даёт читаемое название объекта в связанных местах интерфейса. Не используем полный текст заметки как подпись: длинное содержимое сделает выбор менее удобным и может показывать лишние сведения. Для самостоятельного разбора представьте десять материалов с одинаковым заголовком. Дата и поиск помогают найти нужный объект, однако устойчивым идентификатором остаётся первичный ключ; визуальная подпись не обязана быть уникальной.

Полные файлы этого шага

Следующие файлы показаны полностью. Остальные согласованные файлы находятся в том же снимке архива; переносите весь каталог при выборе исходного состояния.

notes/admin.py

from django.contrib import admin
from .models import Note

@admin.register(Note)
class NoteAdmin(admin.ModelAdmin):
    list_display = ("title", "created_at")
    search_fields = ("title", "body")
    list_filter = ("created_at",)

Документация и исходники

Механизм этой главы описан в официальной документации Django 5.2. При самостоятельной проверке сначала сопоставьте маршрут, представление и состояние данных, затем сравните результат с указанным ожидаемым поведением. Архив учебного проекта содержит все шестнадцать самостоятельных этапов и договор эксплуатации.