Django — Django Admin Panel


Содержание

django.admin¶

AdminSite¶

Объет, который конфигурирует админку сайта

>django.admin. AdminSite ¶ site_header ¶

ModelAdmin¶

Объект настраивающий внешний вид админки для модели

Список действий в админке

Булево, список действий снизу

Булево, список действий сверху

Поле, по которому также можно фильтровать объекты в разрезе дат

Список полей модели, которые необходимо скрыть

Список полей модели, которые можно редактировать

Группирует поля модели

Список встаиваемых моделей

Список полей, которые отображаются на странице списка объектов

Список полей, по которым можно перейти на страницы редактирования

Список полей, которые можно редактировать прямо в списке

Список полей, по которым можно отфильтровать объекты на странице списка объектов

Макисмальное количесвто элементов, после которого появится кнопка отобразить все

Список полей, по которым отсртировываются список объектов на стрице списка объектов

Булево, запоминать фильтрацию списка при редактировании элемента

Список полей, только для чтения

Булево, включить кнопку сохранить как новый объект

Булево, кнопки сохранить и удалить в верху страницы

Список полей, по которым можно произвести поиск объектов на странице ссписка объектов

StackedInLine¶

Вложенный набор форм, в которых элементы управления распологаются один за другим по вертикали

Булево, возможность удалять записи

Максимальное количесвто выводимых пустых форм для создания новых записей

fields ¶ fieldsets ¶ model ¶

Максимальное количесвто форм в наборе

ordering ¶ radio_fields ¶ readonly_fields ¶ verbose_name ¶

Надпись для формы

Надпись для всего набора форм

TabularInline¶

Вложенный набор форм, организованный в виде таблицы.

Используется для добавления возможности добавлять связанные объекты одной модели в другую.

Булево, возможность удалять записи

Максимальное количесвто выводимых пустых форм для создания новых записей

fields ¶ fieldsets ¶ model ¶

Максимальное количесвто форм в наборе

ordering ¶ radio_fields ¶ readonly_fields ¶ verbose_name ¶

Кастомизация админки Django

Что такое админка в django и зачем ее кастомизировать, я думаю, вы уже знакомы. Для кастомизации админики есть множество инструментов, наподобие django-admin-tools и django-admin2. Но мы не будем рассматривать их в этой статье, а кастомизируем ее с помощью самой джанго. И увидим, что это не так трудно, как кажется:Итак, начнем с того, что админка django — это отдельное приложение, которое находится в django\contrib\admin. Исходники в сети можно увидеть на официальном сайте django.

С чего начнем? Как правило, чтобы кастомизировать админку django, надо унаследоваться от ModelAdmin.

Создадим admin.py в корне папки нашего приложения и напишем в нем следующие строки:

И мы можем добавить нашу модель для отображения вот так:

Первый шаг положен. И первое, что, как правило, необходимо в админке — это изменение ее внешнего вида, например, названия сайта в заголовке.

Итак, идем в Lib\site-packages\django\contrib\admin\templates\admin нашего виртуального окружения либо папки с Python. В моем случае — D:\django\hello\Lib\site-packages\django\contrib\admin\templates\admin. Ищем там base_site.html и копируем его в папку с шаблонами своего проекта в подпапку admin: templates\admin . Открываем его и видим следующую картину:

Все, готово . Если вы перезагрузите страницу, то увидите, что ничего не изменилось. А все дело в том, что загрузчик шаблонов джанго загрузит первый найденный шаблон в иерархии наследования NewAdmin. Соответственно, если у нас в settings.py приложение django.contrib.admin стоит перед нашим приложением, то NewAdmin подхватит стандартный шаблон из D:\django\hello\Lib\site-packages\django\contrib\admin\templates\admin . Спасибо за эту подсказку источнику, который, к сожалению, на момент написания статьи открывался только в мобильной версии. Надеюсь, пофиксят. Так ставим наше приложение вперед:

Перезагружаем страницу и любуемся. Мы молодцы.

В целом — скажу вам по секрету — этот путь не является оптимальным для изменения названия сайта в админке. Да. Ведь можно было просто переопределить site_header дефолтного AdminSite:

Либо вовсе переопределить весь AdminSite:

и указать его в маршрутизации:


Спасибо посту Reto Aebersold. Но последний вариант из ссылки, на мой взгляд, в большинстве проектов слишком избыточный, и его следует использовать, когда вы столкнулись с необходимостью сделать несколько раздельных админок. А зачем нам танковая артиллерия здесь? Первый вариант с переопределением admin.site.site_header — это то, что надо последовательного программирования. Но одно но… — это не то, что нам было нужно. Смысл нашего примера с переопределением шаблона — показать, как можно изменять пользовательский интерфейс админки джанго. И мы это сделали…

И это еще не все. Выше мы узнали как переопределять административные шаблоны. Теперь попробуем переопределить поля модели Profile для панели администратора. Изменим код нашего класса NewAdmin:

И в админке джанго будет отобраться только эти поля, доступные для редактирования. На этом сделаем перерыв, но это еще не все. До новой встречи

Создаем свое первое веб-приложение при помощи Django

Django — это Open Source фреймворк для создания веб-приложений различной сложности. Одним из основных преимуществ Django является то, что вам нужно позаботиться только о логике вашего будущего приложения, остальное сделает Django.

Мы создадим веб-приложение, у которого будет панель администратора и возможность загружать загадки, а у пользователей, соответственно, возможность отвечать на них. Во время разработки будут использоваться Python 3.4.3 и Django 1.9.1.

Устанавливаем Django

Делается это очень просто, в командной строке нужно написать: pip install Django==1.9.1 .

Создаем проект

Если вы правильно установили Django, то после запуска django-admin —version вы увидите текущую версию фреймворка. Теперь создадим проект. Это можно сделать следующим образом: django-admin startproject django_example .

Как только создание проекта будет завершено, взглянем на директорию нашего проекта:

  • django_example/__init__.py — пустой файл, который говорит Python, что данная директория должна восприниматься в качестве пакета.
  • django_example/settings.py содержит конфигурацию нашего проекта.
  • django_example/urls.py — здесь объявляются URL.
  • django_example/wsgi.py — с помощью него приложение может работать с веб-сервером по протоколу WSGI.
  • manage.py позволяет взаимодействовать с проектом.

Теперь пришло время запустить наше приложение. Для этого в командной строке нужно написать python manage.py runserver . После этого в адресной строке браузера нужно написать: http://127.0.0.1:8000/ . Если вы увидели «You have unapplied migrations; your app may not work properly until they are applied.», то не волнуйтесь, мы вернемся к этому чуть позже.

Создаем приложение

Определим различие между проектом и приложением. Приложение — это программа, которая что-то делает, а проект — это группа приложений.

Итак, приступим к созданию приложения. Это делается следующим образом: python manage.py startapp riddles .
Как только приложение создано, давайте напишем простой вид, по правилам Django все виды должны храниться в файле views.py .

Теперь, чтобы привязать наш вид к URL, создадим файл urls.py .

В urls.py мы должны написать следующее:

Теперь, если мы запустим наше приложение http://127.0.0.1:8000/riddles/ , мы увидим «Hello, World!».

Установка базы данных

По умолчанию в Django используется SQLite, если она вас не устраивает, то вы можете ознакомиться с нашей статьей, в которой мы рассказываем, как безболезненно перейти с SQLite на MySQL.

4 октября 2020 – 1 марта 2020, Москва и онлайн, беcплатно

Теперь откроем django_example/settings.py и взглянем на переменную INSTALLED_APPS , она хранит все приложения, которые активны в текущем проекте. По умолчанию она содержит:

  • django.contrib.admin — админка, скоро мы ей воспользуемся.
  • django.contrib.auth — система аутентификации.
  • django.contrib.contenttypes — фреймворк для content types.
  • django.contrib.sessions — сессионный фреймворк.
  • django.contrib.messages — фреймворк для отправки сообщений.
  • django.contrib.staticfiles — фреймворк для работы со статичными файлами.

Некоторые из этих приложений используют базы данных, но они еще не установлены, поэтому мы и видели «You have unapplied migrations; your app may not work properly until they are applied.». Поправить это можно следующим образом: python manage.py migrate . Вы должны увидеть следующее:

Теперь создадим нашу модель. Для начала создадим Riddle и Option . В Riddle будет содержаться загадка, в Option — один из возможных ответов на нее.

Данная модель обеспечивает Django информацией, необходимой для создания схемы базы данных и database-access API для доступа к объектам. Теперь нам нужно привязать наше приложение к нашему проекту, делается это следующим образом:

После этого нужно сделать миграцию: python manage.py makemigrations riddles . Вы должны увидеть следующее:

Так мы говорим Django, что в моделях были сделаны некоторые изменения, и их нужно сохранить в качестве миграции.

Проверить, что сделает миграция, можно так: python manage.py sqlmigrate riddles 0001 (0001 — версия миграции, которую мы хотим проверить). На выходе мы получим:

Заметьте, что команда sqlmigrate нужна только для проверки, каждый раз ее запускать необязательно.

Теперь мы можем начать пользоваться панелью администратора. Но для этого нам нужен пользователь. Создать его можно следующим образом: python manage.py createsuperuser . После этого запускаем сервер, если он не запущен, и переходим на http://127.0.0.1:8000/admin/ . Вы увидите следующее:

Теперь дадим админу возможность изменять наши модели. Делается это так:

Вот что получится в итоге:

Возьмите небольшую паузу и поиграйтесь с панелью администратора. Вы будете приятно удивлены тем, что умеет Django.

Главная страница

Что нам нужно для создания главной страницы?

  • Templates: скелет нашей страницы.
  • Views: функция на Python для отображения контента.

Начнем с шаблонов. Создадим папку templates внутри папки riddle , а в ней создадим index.html .

Теперь создадим макет для ответов:

Здесь мы используем csrf_token , он нужен для защиты от межсайтовой подделки запроса, каждая внутренняя форма должна его использовать. Теперь напишем виды для рендеринга наших шаблонов:

Давайте пройдемся по каждой функции отдельно:

  • index: Index использует функцию render . На вход она получает HttpRequest, местонахождение шаблона и его содержимое, а возвращает HttpResponse с окончательным html.
  • detail: Detail делает практически то же самое, но только функция get_object_or_404 возвращает HttpResponse404, если нужный объект не был найден.
  • answer: Answer ищет предоставленную загадку (и возвращает 404, если она не найдена) и проверяет правильность ответа.

Теперь добавим наши функции в urls.py :

Добавим немного стилей

Для начала создадим директорию static , а в ней создадим файл main.css .

Немного изменим наши шаблоны:

Первая строка загружает статические файлы, потом мы используем <% static '#' %>, где # — путь к вашему файлу. Аналогичная процедура проводится и для JavaScript.

Теперь вы можете создавать свои собственные приложения на Django.

Исходный код нашего приложения можно скачать по этой ссылке.


Улучшаем админку Django. Как изменить панель администратора для модели Post

Добрый день! Сегодня я постараюсь вам рассказать о том, как изменить отображение статей в административной панеле Django. Сейчас это выглядит очень просто — кнопка добавить статью, название статьи и возможно выделить нужную статью и отформатировать ее или удалить. А сделаем мы вот такое отображение:

Для начала давайте взглянем на нашу модель поста

Из нового я сюда добавил только STATUS CHOICE. Сделал я это для того чтобы в дальнейшем настроить отложенный постинг записей в блоге. Чтобы можно было писать статьи согласно контент плану. Это очень удобно. Вы садитесь, сразу пишите статьи на месяц вперед, планируете время и все — далее блог django будет сама публиковать в нужное время записи.

Настройка нашей админки осуществляется в файле admin.py сейчас он выглядет так.

Как видите, мы включили в админку модель Post. Давайте теперь сделаем так, что у нас отображались фильтры, поиск, поля новые.

Расширяем возможности приложения администрирования Django

Три способа доработки этого мощного приложения для соответствия вашим нуждам

Приложение администрирования Django

Платформа Django предлагает разработчикам множество функциональности: зрелую стандартную библиотеку, активное сообщество пользователей и все преимущества языка Python. В то время как другие инфраструктуры разработки Web-приложений могут предложить то же самое, уникальным достоинством Django является ее встроенное приложение администрирования — admin.

Приложение администрирования предоставляет «из коробки» расширенную функциональность для создания, чтения, обновления и удаления данных (Create-Read-Update-Delete или CRUD), избавляя разработчиков от часов повторяющейся работы. Это является важным как при разработке Web-приложений, потому что с его помощью программисты могут быстро изучать свои модели данных, так и при развертывании приложений, потому что не имеющие отношения к технике конечные пользователи могут пользоваться приложением администрирования для добавления и редактирования содержимого сайта.

В реальной жизни всегда требуется сделать какую-либо подгонку приложения. В документации Django приводится множество руководств по преобразованию базового вида приложения администрирования, а также Django предоставляет несколько простых методов для переопределения части поведения приложения. Но что, если вам нужно больше? С чего начать? В этой статье рассказывается о нескольких направлениях, в которых можно вести серьезную переработку приложения администрирования.

Краткий обзор приложения администрирования

Возможности приложения администрирования с настройками по умолчанию знакомы большинству разработчиков Django. Сделаем краткий обзор этих возможностей. Для начала включим приложение администрирования, отредактировав файл верхнего уровня urls.py, как показано в листинге 1.

Листинг 1. Включаем приложение администрирования в urls.py
Версии ПО, используемые в этой статье
  • Django V1.0.2
  • SQLite V3
  • Python V2.4–2.6 (Django пока не поддерживает Python 3)
  • IPython (для работы в консоли)

Механизм объектно-ориентированного отображения (Object-Relational Mapper или ORM) Django поддерживает множество баз данных, среди которых проще всех в установке sqlite3. Кроме того, sqlite3 поставляется в комплекте со многими ОС. Примеры из этой статьи должны работать с любой базой данных. С полным списком баз данных, поддерживаемых Django, можно ознакомиться в разделе Ресурсы.

Django предоставляет удобный способ настройки рабочего окружения с помощью команды python manage.py shell . Во всех примерах кода, приводимых в этой статье, предполагается, что окружение настраивается именно таким образом.

В терминах Django, в этой статье предполагается следующее:

  • Проект Django называется more_with_admin.
  • В проекте more_with_admin имеется приложение с именем examples.
Цукерберг рекомендует:  5 бесплатных open source движков для игр на JavaScript

Приложение examples моделирует простую, похожую на блог систему документов, каждый из которых может иметь комментарии. Все примеры работы в командной строке выполняются из корневой директории проекта more_with_admin.

Также необходимо добавить приложение django.contrib.admin в кортеж settings.INSTALLED_APPS .

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

Приложение администрирования живет внутри пакета Django. Если вы его установили с помощью setuptools, приложение администрирования должно находиться в директории site-packages/django/contrib/admin. Ниже приводится пример создания в директории проекта символической ссылки, указывающей на исходный код приложения администрирования Django. Вы можете воспользоваться этой ссылкой, изменив ее в соответствии с вашей операционной системой и местонахождением пакета Django.

$ ln -s /path/to/Python/install/site-packages/django/contrib/admin admin-source

Метод admin.autodiscover() пробегается по всем приложениям, указанным в кортеже settings.INSTALLED_APPS и ищет файл с именем admin.py. Он обычно находится на верхнем уровне директории приложения, на одном уровне с models.py.

Приложению examples нужен файл models.py, показанный в листинге 2. Соответствующий файл admin.py приведен ниже.

Листинг 2. Пример файла models.py для этого приложения

Теперь можно запустить сервер разработки Django и взглянуть на приложение администрирования:

По умолчанию приложение администрирования доступно по адресу http://localhost:8000/admin/. Зарегистрировавшись, вы увидите главный экран администратора, показанный на рисунке 1.

Рисунок 1. Главный экран администратора Django
Изменение кода в admin.py

В отличие от остальных файлов приложения Django, если вы при работающем Web-сервере разработки Django вносите изменения в admin.py, то для вступления изменений в силу, возможно, придется вручную перезапустить сервер.

Заметьте, что модели приложения еще недоступны, потому что мы не создали файл admin.py. В листинге 3 показан код, который даст возможность работать с моделями через приложение администрирования.

Листинг 3. Пример файла admin.py

После перезагрузки основной страницы приложения администрирования, как показано на рисунке 2, новые модели становятся доступными для использования.

Рисунок 2. Администратор Django готов работать с пользовательскими моделями данных

Доработка страниц моделей в приложении администрирования

Имена директорий в папках приложения администрирования

Заметьте, что я использую в именах моделей только символы в нижнем регистре. Это согласуется с тем, как работают обычные страницы администратора при генерации адресов URL. В Django эти дружественные для адресов URL имена называются «ленивыми» (slug) именами. Если вы не уверены в том, каким должно быть ленивое имя для определенной модели, перед созданием собственных директорий исследуйте приложение администрирования и посмотрите, какие имена появляются в URL-адресах.

Чтобы понять, как дорабатывать приложение администрирования не меняя исходного кода Django, важно помнить, что мы имеем дело с обычным приложением Django, таким же, как и все остальные. В первую очередь это означает, что к нему применима система наследования шаблонов Django.

В Django шаблоны проекта имеют больший приоритет по сравнению с системными шаблонами. Кроме того, перед обращением к шаблонам по умолчанию приложение администрирования пытается найти жестко закодированные шаблоны с именами, соответствующими каждой модели. Это предоставляет точку входа для доработки приложения.

Сначала отредактируем файл settings.py проекта, указав в нем директорию, в которой Django должен искать шаблоны (листинг 4).

Листинг 4. Добавляем в settings.py директории с шаблонами

Затем создадим в проекте следующие директории:

Приложение администрирования Django сначала попытается найти шаблоны в директории с именем, совпадающим с названием вашего приложения (здесь examples ), затем с названием моделей ( document и comment ) и только потом, в случае неудачи, будет использовать системные шаблоны для отображения страницы.

Переопределяем страницу добавления/удаления экземпляра модели


Для добавления и редактирования экземпляров модели приложение администрирования использует страницу change_form.html. Для начала создадим в директории templates/admin/examples/document/ страницу с именем change_form.html и поместим в нее следующую строку для наследования шаблона Django: <% extends "admin/change_form.html" %>.

Теперь все готово для доработки приложения. Уделите некоторое время знакомству с содержимым реального шаблона admin/change_form.html. Он довольно хорошо организован в блоки, которые можно переопределять, но в некоторых случаях доработка может потребовать «оптового» копирования блоков. Тем не менее, переопределение основанных на блоках шаблонов всегда предпочтительнее копирования страницы целиком.

Какого рода доработку можно сделать на странице добавления/редактирования? Допустим, мы хотим для каждого документа добавить предварительный просмотр пяти последних комментариев.

Сначала создадим тестовые данные(листинг 5).

Листинг 5. Создаем с помощью оболочки Django экземпляр модели Document с несколькими комментариями

Теперь в администраторе на странице списочного отображения показан один документ . Выберем этот документ, чтобы увидеть показанную на рисунке 3 страницу добавления/редактирования по умолчанию.

Рисунок 3. Стандартная страница добавления/редактирования для модели Document

Обратите внимание, что связанные с документом комментарии не показаны вообще. Обычно в приложении администрирования работа с взаимосвязанными моделями организуется посредством классов Inline . Эти мощные классы позволяют пользователям приложения администрирования редактировать или добавлять несколько взаимосвязанных моделей на одной странице. Чтобы увидеть классы Inline в действии, отредактируйте файл admin.py приложения так, как показано в листинге 6.

Листинг 6. Добавляем модель комментария к модели документов в приложении администрирования

На рисунке 4 показан новый вид страницы добавления/редактирования после добавления элемента управления TabularInline .

Рисунок 4. Страница добавления/удаления документа после добавления модели комментария в виде класса Inline

Несомненно, это мощный способ доработки приложения администрирования, однако при нем результат может оказаться слишком громоздким, тогда как мы всего лишь хотели организовать быстрый просмотр комментариев.

В таком случае имеется два подхода. Первый подход – отредактировать HTML-виджеты, ассоциированные с классами inline , с помощью предоставляемого Django интерфейса администрирования виджетов. Виджеты в документации Django описаны весьма подробно. Другой подход — модифицировать шаблон добавления/редактирования напрямую. Этот подход наиболее полезен, если вы вообще не собираетесь использовать специфическую функциональность администратора.

Если вы не хотите разрешать редактировать комментарии (например, потому что пользователи не имеют для этого достаточных прав), но вы хотите, чтобы они могли видеть комментарии, можно модифицировать шаблон change_form.html.

Переменные, предоставляемые приложением администрирования Django

Чтобы добавить функциональность на страницу отображения экземпляра модели, нужно знать, какие данные приложения администрирования уже доступны. В таблице 1 дано описание двух переменных, которые вам в этом помогут.

Таблица 1. Переменные, необходимые для доработки шаблона приложения администрирования
Переменная Описание
object_id Это первичный ключ для редактируемого объекта. Если вы дорабатываете страницу экземпляра какой-либо одной модели (например, документа), это все, что вам понадобится.
content_type_id Если вы переопределяете страницы, работающие с множеством моделей, используйте эту переменную, чтобы опрашивать инфраструктуру ContentTypes для получения имени модели. Больше информации о типах содержимого можно получить в разделе Ресурсы.

Создаем тэг шаблона и включаем его в страницу приложения администрирования

Чтобы вывести комментарии, относящиеся к документу, необходим код, который нельзя вводить непосредственно в шаблон Django. Для таких случаев наилучшим решением является использование тэга шаблона. Сначала создадим директорию тэгов шаблонов и файл __init__.py в ней:

Создадим новый файл с именем examples/templatetags/example_tags.py и добавим в него приведенный ниже код (листинг 7).

Листинг 7. Тэг шаблона для извлечения комментариев к документу с заданным >

Так как здесь используется тэг включения шаблона, необходимо создать соответствующий шаблон: comments.html. Отредактируем файл examples/templates/comments.html file и поместим в него код, показанный в листинге 8.

Листинг 8. Шаблон для предварительного просмотра комментариев

Теперь пришло время добавить это на страницу приложения администрирования. Закомментируйте в admin.py ссылки на CommentInline и сделайте в вашей локальной версии шаблона change_form.html изменения, показанные в листинге 9.

Листинг 9. Включение тэга шаблона в страницу добавления/редактирования

Перед использованием object_id надо проверять, что он существует, так как шаблон change_form.html также используется для создания новых экземпляров модели, при котором object_id экземпляра еще не доступен. Блок after_field_sets – один из многих элементов, предоставляющих возможности для расширения приложения администрирования. Остальные подобные блоки можно найти в исходном коде страницы change_form.html.

На рисунке 5 показана обновленная форма.

Рисунок 5. Страница добавления/редактирования документа после добавления на нее собственного тэга шаблона

Модифицируем поведение приложения администрирования

Как видите, одним только переопределением шаблонов можно добиться довольно многого. Но что, если мы хотим поменять само поведение приложения администрирования? Это можно сделать, подправив исходный код, но тогда вы будете ограничены только той версией Django, которую будете использовать на момент внесения исправлений.

Переопределяем методы в AdminModel

По умолчанию нажатие кнопки Save в приложении администрирования возвращает пользователя на страницу списочного отображения экземпляров модели. Обычно это всех устраивает, но что, если мы хотим переходить сразу на страницу предварительного просмотра объекта, находящуюся вне приложения администрирования? Это распространенное поведение в системах управления содержимым (content management system или CMS).

Метод

В листинге 10 предполагается, что класс Document был изменен и теперь включает в себя метод get_absolute_url() , который является рекомендуемым способом определения моделями Django своего канонического представления. Если метод определен, в администраторе Django на каждой странице этой модели также появляется полезная кнопка View on site.

Большая часть функциональности приложения администрирования реализована в классе admin.ModelAdmin . От этого класса наследуются объекты в admin.py. В нем имеется очень много публичных методов, которые можно переопределять. Определение этого класса можно посмотреть в файле admin-source/options.py.

Есть два способа поменять поведение кнопки Save: можно переопределить метод admin.ModelAdmin.response_add , отвечающий за само перенаправление после сохранения объекта, а также можно переопределить метод admin.ModelAdmin.change_view . Последний способ немного проще.

Листинг 10. Переопределяем страницу, на которую перенаправляются пользователи после сохранения документа

Теперь, когда пользователь нажимает кнопку Save, он перенаправляется на страницу предварительного просмотра сохраненного документа, а не на страницу списочного отображения всех документов.

Добавление функциональности в приложение администрирования с помощью сигналов

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

В приложении администрирования имеется функциональность, которую разработчики желают поменять особенно часто – это управление пользователями с помощью класса django.contrib.auth.models.User . Часто приложение администрирования является единственным местом, где добавляются или модифицируются пользователи Django, что делает сложной доработку под себя этого полезного класса.

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

В листинге 11 демонстрируется, как легко добавить функцию, выполняющуюся при каждом сохранении экземпляра класса User . Сигналы обычно добавляют в models.py.

Листинг 11. Использование сигналов Django для уведомления о создании новых пользователей

Сигнал post_save предоставляется Django, он генерируется каждый раз при создании или сохранении экземпляра модели. Метод connect() здесь принимает два аргумента: функцию обратного вызова ( notify_admin ) и аргумент sender , который сообщает о том, что эту функцию следует вызывать только при сохранении экземпляров модели User .

Внутрь функции обратного вызова сигнал post_save передает отправителя (класс модели), экземпляр этой модели и булево значение, обозначающее, был ли этот экземпляр только что создан. В этом примере метод посылает электронное сообщение только при создании нового экземпляра модели User ; в противном случае не делается ничего.

В разделе Ресурсы можно ознакомиться со списком предоставляемых Django сигналов, а также с документацией по созданию собственных сигналов.

Более глубокие изменения: добавляем права строкового уровня

Почему ?

Возможно, не сразу становится понятным, почему поле ForeignKey будет выставляться с флагом blank=True , когда оно не является текстовым полем. В данном случае это так потому, что приложение администрирования использует blank вместо null , чтобы определять, должно ли значение быть выставлено вручную перед сохранением модели.

Если задать только null=True или вообще ничего, то приложение администрирования Django перед сохранением заставит пользователя вручную выбрать значение «added by», хотя вместо этого мы хотим, чтобы при сохранении по умолчанию выбирался текущий пользователь.

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


В ряде случаев хочется разрешить пользователям изменять только какие-либо специфичные объекты. Такие права часто называют правами строкового уровня, так как они отражают способность изменять только некоторые строки в таблице базы данных вместо права изменять любые записи в таблице без ограничений. Например, в приложении examples можно разрешить пользователям видеть только их собственные документы.

Сначала, как показано в листинге 12, добавим в models.py атрибут, в котором будет храниться имя создателя экземпляра модели Document .

Листинг 12. Добавляем в models.py информацию о пользователе, создавшем каждый экземпляр модели Document

Затем нужно добавить код для автоматического заполнения этого поля при создании экземпляра модели Document . Сигналы в этом случае не подходят, так как они не имеют доступа к объекту пользователя. Однако класс ModelAdmin предоставляет метод, включающий в себя запрос, а значит, как параметр, и текущего пользователя.

Поменяем метод save_model() в файле admin.py так, как показано в листинге 13.

Листинг 13. Переопределяем метод в DocumentAdmin для сохранения текущего пользователя в базу данных при создании экземпляра модели

Если атрибут added_by равен None , значит это новая запись, которая раньше не сохранялась. (Также можно проверять, что change равно false , это обозначает, что запись добавляется, но проверка пустоты поля added_by обеспечивает, что будут заполняться и записи, которые были добавлены не из приложения администрирования.)

Далее надо ограничить список документов, доступных пользователю, только документами, созданными этим пользователем. Это можно сделать с помощью находящегося в классе ModelAdmin метода queryset() , который определяет результат запроса, по умолчанию возвращаемый любой страницей списочного отображения.

Переопределим метод queryset() так, как показано в листинге 14, чтобы ограничить список только документами, созданными текущим пользователем. Суперпользователи могут видеть все документы.

Листинг 14. Переопределяем результат запроса, возвращаемый списочными страницами

Теперь все запросы к странице списочного отображения модели Document приложения администрирования будут показывать только документы, созданные текущим пользователем (за исключением суперпользователей, которым показываются все документы).

Конечно, на данный момент ничто не мешает находчивому пользователю получить доступ к странице редактирования чужого документа, зная его ID. По-настоящему безопасные права строкового уровня требуют переопределения большего количества методов. Так как пользователи с правами администратора, как правило, пользуются определенным доверием, иногда оказывается достаточно такой простой системы прав для обеспечения хорошо налаженного рабочего процесса.

Заключение

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

Доработка под свои нужды существующего приложения администрирования имеет много преимуществ по сравнению с созданием нового интерфейса администрирования:

  • ваше приложение может выиграть от развития проекта Django по мере продолжения его активной разработки;
  • приложение администрирования уже поддерживает большинство типичных сценариев использования;
  • при добавлении в проект нового приложения оно так же, как и ваш собственный код, автоматически будет доступно для администрирования.

В Django версии 1.1 в приложении администрирования будут добавлены две часто запрашиваемые новые возможности: возможность линейного (inline) редактирования полей на страницах списочного просмотра и действия администратора (admin actions), которые позволяют обновлять за один раз множество объектов. Оба добавления устранят необходимость писать эту функциональность с нуля при расширении и доработке приложения

Ресурсы для скачивания

Похожие темы

  • Оригинал статьи: Doing more with the Django admin (EN).
  • Разработчикам, которые только начинают знакомиться с Django или приложением администрирования, следует начать с руководства Django (EN).
  • Главная страница документации приложения администрирования и исходный код приложения администрирования являются самым лучшим и полным справочником по этому приложению (EN).
  • Ознакомьтесь со списком сигналов, предоставляемых Django, и документацией по созданию собственных сигналов (EN).
  • Узнайте о двух новых возможностях приложения администрирования в Django версии 1.1: действиях администратора и редактируемых списках (EN).
  • В этой статье демонстрировалось редактирование страниц, специфичных для одной модели. Если вам нужно редактировать страницы, относящиеся к нескольким моделям, ознакомьтесь с имеющейся в Django инфраструктурой contenttypes (EN).
  • В документации Django содержится полный список баз данных, поддерживаемых Django. Начиная с версии 1.0, в Django также появилась возможность добавлять поддержку новых баз данных (EN).
  • Узнайте больше об изменении механизма перенаправления запросов в приложении администрирования (EN).
  • Многие дистрибутивы Linux®, а также Mac OS® X имеют в своем комплекте SQLite, однако если его нет в вашей системе, вы можете загрузить его с сайта проекта SQLite (EN).
  • SQLite V3: Начиная с версии 2.5, в Python появилась поддержка SQLite 3 без необходимости в дополнительных драйверах. В ранних версиях Python для этого приходилось загружать пакет pysqlite (EN).
  • Интервью и дискуссии разработчиков в подкастах developerWorks (EN).
  • Следите за developerWorks в Twitter (EN).
  • Разработайте ваш следующий проект с помощью пробного ПО от IBM, доступного для загрузки и на DVD.(EN)
  • Загрузите ознакомительные версии продуктов IBM или поработайте с онлайновой пробной версией IBM SOA Sandbox и получите практический опыт с инструментами разработки и связующим ПО от DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.(EN)

Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

Что нужно знать, чтобы управлять пользователями в Django Admin

Управление пользователями в админке Django – сложная тема. Если вы используете слишком много разрешений, вы можете утонуть в повседневные операциях по предоставлению прав. Если вы разрешаете свободно предоставлять права пользователем без надзора, то вы подвергаете свою систему риску.

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

Знаете ли вы, что сотрудники, которые управляют другими пользователями в Django Admin, могут редактировать свои собственные разрешения? Знаете ли вы, что они также могут стать суперпользователями? В админке Django нет ничего, что могло бы этому помешать, так что это решать вам!

К концу этого урока вы узнаете, как:

  • Защититься от повышения разрешений, запретив пользователям редактировать свои собственные разрешения
  • Поддерживать чистоту и удобство обслуживания, заставляя пользователей управлять разрешениями только с помощью групп.
  • Предотвратить утечку разрешений через настраиваемые действия, явно применяя необходимые разрешения

Модель Permissions (Разрешения)

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

Django поставляется со встроенной системой аутентификации. Система аутентификации включает пользователей, группы и разрешения.

При создании модели Django автоматически создает четыре разрешения по умолчанию для следующих действий:

  1. add : Пользователи с этим разрешением могут добавить экземпляр модели.
  2. delete : Пользователи с этим разрешением могут удалить экземпляр модели.
  3. change : Пользователи с этим разрешением могут обновить экземпляр модели.
  4. view : Пользователи с этим разрешением могут просматривать экземпляры этой модели. Это разрешение было очень ожидаемым, и, наконец, оно было добавлено в Django 2.1.

Имена разрешений следуют особому соглашению об именах: ._ .

Давайте рассмотрим это подробнее:

  • это имя приложения. Например модель User импортируется из auth (django.contrib.auth).
  • является одним из действий указаных выше ( add , delete , change , или view ).
  • это название модели, все строчные буквы.


Знание этого соглашения об именах поможет вам легче управлять разрешениями. Например, имя разрешения на изменение пользователя – auth.change_user.

Как проверяются права

Модель permissions предоставляется пользователям или группам. Чтобы проверить, есть ли у пользователя определенные разрешения, вы можете сделать следующее:

Стоит отметить, что .has_perm() всегда будет возвращать True для активного суперпользователя, даже если разрешение на самом деле не существует:

Как вы можете видеть, когда вы проверяете разрешения для суперпользователя, разрешения на самом деле не проверяются.

Как применяются права

Модели Django сами обычно не используют разрешения. По умолчанию единственные права доступа – это права для Django Admin.

Причина, по которой модели обычно не используют разрешения, заключается в том, что, как правило, модель не знает о пользователе, выполняющем действие. В приложениях Django объект пользователя обычно находиться в запросе. Вот почему в большинстве случаев разрешения применяются на уровне представления (вьюх).

Например, чтобы запретить пользователю без разрешений на просмотр в модели User доступ к представлению, отображающему информацию о пользователе, выполните следующие действия:

Если пользователь, сделавший запрос, вошел в систему и прошел проверку подлинности, то request.user будет содержать экземпляр User. Если пользователь не вошел в систему, то request.user будет экземпляром AnonymousUser. Это специальный объект, используемый Django для обозначения неаутентифицированного пользователя. Использование has_perm в AnonymousUser всегда возвращает False.

Если пользователь, отправляющий запрос, не имеет разрешения view_user, вы должны создать исключение PermissionDenied, и клиенту должен вернуться ответ со статусом 403.

Чтобы упростить применение разрешений в представлениях, Django предоставляет сокращенный декоратор под названием permission_required , который делает то же самое:

Чтобы применить разрешения в шаблонах, вы можете получить доступ к текущим пользовательским разрешениям через специальную переменную шаблона, которая называется perms. Например, если вы хотите, чтобы кнопка удаления отображалась только пользователям с разрешением на удаление, выполните следующие действия:

Некоторые популярные сторонние приложения, такие как Django rest framework, также предоставляют полезную интеграцию с разрешениями модели Django.

Django Admin и модель Permissions

Django admin имеет очень тесную интеграцию со встроенной системой аутентификации, в частности, с моделью permissions. Django admin «из коробки» использует модель permissions:

  • Если у пользователя нет прав доступа к модели, он не сможет увидеть ее или получить доступ к ней через панель администратора.
  • Если у пользователя есть права на просмотр и изменение модели, он сможет просматривать и обновлять экземпляры, но не сможет добавлять новые или удалять существующие.

При наличии соответствующих разрешений пользователи с правами администратора менее склонны совершать ошибки, и злоумышленникам будет труднее причинить вред.

Реализация пользовательских бизнес-ролей в Django Admin

Одним из наиболее уязвимых мест в каждом приложении является система аутентификации. В приложениях Django это модель User. Итак, чтобы лучше защитить ваше приложение, вы должны начать с модели User.

Во-первых, вам нужно взять под контроль страницу администратора модели User. Django уже поставляется с очень хорошей страницей администратора для управления пользователями. Чтобы воспользоваться этой замечательной работой, не нужно создавать новую страницу а нужно расширить уже встроенную модель User в Django admin.

Setup: Пользовательская регистрация модели User

Чтобы расширить страницу администратора для модели User, вам нужно отменить текущую регистрацию администратора модели, предоставленного Django, и зарегистрировать собственную:

CustomUserAdmin расширяет UserAdmin в Django. На этом этапе, если вы войдете в систему Django Admin по адресу http://127.0.0.1:8000/admin/auth/user, вы должны увидеть, что страница администратора пользователей не изменилась:

Запрет на обновление полей

Необслуживаемые формы администратора – главный кандидат на ужасные ошибки. Пользователь может легко обновить экземпляр модели через Django Admin, чего приложение не ожидает. В большинстве случаев пользователь даже не заметит, что что-то не так. Такие ошибки обычно очень трудно отследить и исправить.

Чтобы предотвратить такие ошибки, вы можете запретить администраторам изменять определенные поля в модели.

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

Когда поле добавлено в readonly_fields, оно не будет редактироваться в форме изменения по умолчанию. Когда поле помечено как доступное только для чтения, Django будет отображать элемент ввода как отключенный.

Но что, если вы хотите запретить обновление поля только некоторым пользователям?

Условный запрет на обновление полей

Иногда полезно обновить поля прямо в админке. Но что если вы не хотите, чтобы какой-либо пользователь делал это: вы хотите, чтобы это могли делать только суперпользователи.

Допустим, вы хотите запретить пользователям, не являющимся суперпользователями, изменять имя пользователя. Для этого вам нужно изменить форму изменений, сгенерированную Django, и отключить поле имени пользователя на основе текущего пользователя:

Давайте разберем что тут было сделано:

  • Чтобы внести коррективы в форму, нужно переопределить get_form(). Эта функция используется Django для создания формы изменения по умолчанию для модели.
  • Чтобы условно отключить поле, сначала нужно получить форму по умолчанию, созданную Django, а затем, если пользователь не является суперпользователем, отключить поле имени пользователя.

Теперь, когда не-суперпользователь пытается отредактировать пользователя, поле username будет отключено. Любая попытка изменить username через Django Admin потерпит неудачу. Когда суперпользователь пытается отредактировать пользователя, поле username будет редактируемым и будет вести себя как положено.

Запретить не суперпользователям предоставлять права суперпользователя

Суперпользователь – это очень строгое разрешение, которое не должно предоставляться легко. Однако любой пользователь с разрешением на изменение модели User может сделать любого пользователя суперпользователем, в том числе и себя. Это противоречит всей цели системы разрешений, поэтому вам нужно закрыть эту дыру.

На основании предыдущего примера, чтобы не допустить превращения не суперпользователей в суперпользователей, добавьте следующее ограничение:

В дополнение к предыдущему примеру тут сделаны следующие дополнения:

  1. Инициализирован пустой набор disabled_fields, который будет содержать поля для отключения. set – это структура данных, которая содержит уникальные значения. В этом случае имеет смысл использовать set, потому что вам нужно отключить поле только один раз. Оператор |= используется для выполнения обновления на месте OR (ИЛИ). Для получения дополнительной информации о set, почитайте это Sets in Python.
  2. Затем, если пользователь является суперпользователем, было добавлено в set два поля (username из предыдущего примера и is_superuser). Они будут препятствовать тому, чтобы не-суперпользователи становились суперпользователями.
  3. Наконец, далее перебираются все поля в set, и помечаются как отключенные.

Django User Admin Двухступенчатая форма

Когда вы создаете нового пользователя в Django admin, вы проходите двухэтапную форму. В первой форме вы вводите имя пользователя и пароль. Во второй форме вы обновляете остальные поля.

Этот двухэтапный процесс уникален для модели User. Чтобы приспособиться к этому уникальному процессу, вы должны убедиться, что поле существует, прежде чем попытаться его отключить. В противном случае вы можете получить KeyError.

Предоставление разрешений только через использования групп

Способ управления разрешениями очень специфичен для каждой команды, продукта и компании. Я обнаружил, что легче управлять разрешениями в группах. В своих собственных проектах я создаю группы поддержки, редакторов контента, аналитиков и так далее. Я обнаружил, что управление разрешениями на уровне пользователя может стать настоящей проблемой. Когда добавляются новые модели или меняются бизнес-требования, утомительно обновлять каждого отдельного пользователя.

Чтобы управлять разрешениями только с помощью групп, необходимо запретить пользователям предоставлять разрешения конкретным пользователям. и разрешить объединение пользователей в группы. Для нужно отключить поле user_permissions для всех не суперпользователей:


Тут был использован тот же метод, что и в предыдущих разделах, для реализации других бизнес-правил. В следующих разделах мы внедрим более сложные бизнес-правила для защиты вашей системы.

Запрет не суперпользователям редактировать свои собственные разрешения

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

Аргумент obj является экземпляром объекта, с которым вы сейчас работаете:

  • Когда obj имеет значение None, форма используется для создания нового пользователя.
  • Когда obj не None, форма используется для редактирования существующего пользователя.

Чтобы проверить, работает ли пользователь, выполняющий запрос, с самим собой, нужно сравнить request.user с obj. Поскольку это пользователь admin, obj является экземпляром User или None. Когда пользователь, делающий запрос, request.user, равен obj, это означает, что пользователь обновляет самого себя. В этом случае мы отключаем все конфиденциальные поля, которые можно использовать для получения разрешений.

Возможность настроить форму на основе объекта очень полезна. Это может быть использовано для реализации сложных ролей.

Переопределение разрешений

Иногда бывает полезно полностью переопределить разрешения в админке Django. Распространенный сценарий – это когда вы используете разрешения в других местах и не хотите, чтобы штатные пользователи вносили изменения в администраторе.

Django использует хуки для четырех встроенных разрешений. Внутренние, хуки используют права текущего пользователя для принятия решения. Вы можете переопределить эти хуки и принять другое решение.

Чтобы запретить сотрудникам удалять экземпляр модели, независимо от их прав доступа, вы можете сделать следующее:

Как и в случае с get_form(), obj – это экземпляр, с которым вы сейчас работаете:

  • Когда obj имеет значение None, пользователь запрашивает представление списка.
  • Когда obj не None, пользователь запрашивает представление изменения конкретного экземпляра.

Наличие экземпляра объекта в этом хуке очень полезно для реализации разрешений уровня объекта для различных типов действий. Вот другие варианты использования:

  • Предотвращение изменений в рабочее время
  • Реализация разрешений на уровне объектов

Ограничение доступа к настраиваемым действиям

Пользовательские admin действия (action) требуют особого внимания. Django не имеет полной интеграции с ними, поэтому не может ограничить доступ к ним по умолчанию. Пользовательские действия будут доступны любому администратору с любым разрешением на модель.

Чтобы проиллюстрировать это, добавьте действие администратора, которое помечает нескольких пользователей как активных:

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

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

Django admin использует внутреннюю функцию для получения действий. Чтобы скрыть activate_users() от пользователей без разрешения на изменение, переопределите get_actions():

get_actions() возвращает OrderedDict. Ключ – это имя действия, а значение – это функция действия. Чтобы скорректировать возвращаемое значение, нужно переопределить функцию, выбираете исходное значение и, в зависимости от прав пользователя, удалить настраиваемое действие activate_users из dict.

Для сотрудников, у которых нет прав на change_user(), действие activate_users не будет отображаться в раскрывающемся списке действий.

Заключение

Django admin – отличный инструмент для управления проектом Django. Многие команды полагаются на это, чтобы оставаться продуктивным в управлении повседневными операциями. Если вы используете Django admin для выполнения операций над моделями, важно знать о разрешениях. Методы, описанные в этой статье, полезны для любой модели, а не только для модели User.

В этом руководстве вы защитили свою систему, внеся следующие изменения в Django Admin:

  • Вы защитили себя от повышения разрешений, запретив пользователям редактировать свои собственные разрешения.
  • Вы сохранили чистоту и удобство обслуживания, заставляя пользователей управлять разрешениями только с помощью групп.
  • Вы предотвратили утечку разрешений через настраиваемые действия, явно применяя необходимые разрешения.

Django:Remove superuser checkbox from Django admin panel when login staff users

I need to edit the django admin panel. In my application, superuser can add users and can assign the privileges. when super user add staff user like HR manager, application should allow to add users. it works. but I need do is when staff user log to the admin panel hide the superuser status bar. how can I do this? what Django admin file should I change? and How?

3 Answers 3

In order to remove the «is superuser» checkbox from the Django Admin «Edit User» page, it’s important to understand where and how the «superuser» checkbox comes from.

Under your django installation a file called django.contrib.auth.forms calls the class class UserChangeForm(forms.ModelForm): . The model file it reads is django.contrib.auth.models for the class User(models.Model): class. Essentially the django.contrib.auth.admin file reads passes the fields found in the models as manual fieldset parameters.

The best way to remove the field is by updating a local «admin.py» file to «unregister» and «register» the User model and remove the «superuser» field from the fieldset.

By deregistering the admin class and reregistering it, you can override the fields it passes into the fieldset of the Edit User page. Hope that helps!

Django: пример создания приложения — часть 3: панель управления

Создание суперпользователя

Для начала — нам необходимо создать пользователя, который сможет входить в админпанель.

Выполните следующую команду:

Запуск сервера разработки

Админпанель Django активирована по умолчанию. Давайте запустим сервер разработки и посмотрим её:

Теперь — откройте браузер, и перейдите по адресу http://ваш_IP:8000/admin/. Вы должны увидеть окно входа в панель управления:

Теперь — войдите в панель управления, используя логин и пароль, которые вы создали в начале. Вы должны увидеть главную страницу панели управления:

Вы должны увидеть две группы содержимого, доступного для редактирования — Группы (Groups) и Пользователи (Users). Они предоставляются фреймворком авторизации django.contrib.aut h .

Добавление приложения в админпанель

Сейчас ваше приложение — Question — не отображается в панели управления.

Что бы добавить его туда — нам необходимо указать админпанели, что приложение Questions тоже имеет интерфейс администрирования. Что бы сделать это — отредактируйте файл polls/admin.py в который добавьте такой код:

Обзор функционала панели управления

Теперь, когда мы зарегистрировали Questions , обновите страницу админпанели — в ней появится новый блок:

Нажмите на «Questions» — и вы попадёте в «список изменений» (change list) для ваших вопросов.


Тут отображаются все созданные вами вопросы из базы данных, и можно выбрать какой из них редактировать. Вот вопрос «What’s up?», который создали в предыдущей части:

Нажмите на него для редактирования:

Вот на что тут стоит обратить внимание:

  • форма сгенерирована автоматически из модели Question ;
  • различные типы данных модели ( DateTimeField , CharField ) соответствуют подходящему HTML-виджету ввода данных ; каждый тип данных знает, как ему отобразить себя в панели управления Django;
  • каждый элемент DateTimeField имеет JavaScript ссылку; у дат есть ссылка Today и всплывающее окно календаря, а у поля времени — ссылка «сейчас» и всплывающее окно с наиболее используемыми временными данными.

Нижняя часть страницы предоставляет вам такие опции:

  • Save — сохранить изменения и вернуться на предыдущую страницу к списку изменений;
  • Save and continue editing — сохранить изменения, и перезагрузить страницу редактируемого объекта;
  • Save and add another — сохранить изменения, и загрузить новую пустую страницу для создания аналогичного объекта;
  • Delete — отобразит страницу подтверждения удаления.

Измените «Date published«, кликнув на Today и Now. Затем — нажмите Save and continue editing,а потом — History, справа вверху. Вы увидите страницу, на которой будут отображены все изменения, сделанные с этим объектом через панель управления Django, с указанием времени и имени пользователя, который их выполнил:

Изменение отображения форм в админпанели

Задумайтесь на минуту — написания какого количества кода вам удалось избежать. После регистрации Question с помощью admin.site.register(Question) — Django сама создаёт форму отображения. Но часто вы хотите изменить то, как админпанель будет отображать данные. Это можно сделать, указав Django опции во время регистрации объекта.

Давайте посмотрим, как это можно сделать, изменив порядок отображения полей на странице редактирования.

Измените admin.site.register(Question) в файле polls/admin.py на такой код:

Каждый раз, когда вы захотите изменить опции в админпанели для объекта — вы всегда будете следовать этому шаблону — создать объекта модели а затем передать его аргументом к вызову admin.site.register() .

В данном случае мы изменили порядок отображения — теперь Publication date будет выводиться перед Question :

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

Говоря о множестве полей — возможно, вы захотите разделить их на группы:

Первый элемент каждого кортежа в fieldsets — это заголовок группы. Вот как наша форма будет выглядеть теперь:

Вот можете так же назначать HTML классы для каждого поля. Например, Django предоставляет класс « collapse «, который отображает связанное с ним поле свёрнутым.

Это может быть полезно, когда у вас отображает множество полей на одной странице.

Добавление связанных объектов

ОК, у нас есть страничка Question в панель и управления. Но у Question — есть множественные Choices (варианты ответов), и админпанель их пока не отображает.

Есть два способа решить эту задачу. Первый — просто зарегистрировать Choice , как мы это сделали с Question — в файле polls/admin.py :

Теперь Choice доступны в панели управления:

В этой форме поле Question — выпадающий список, содержащий все вопросы в базе данных. Django знает, что ForeignKey должно представляться в админпанели как форма

Как добавить страницу в админку django

24 августа 2020 г. 16:52

Добавление своей страницы в админку django мало чем отличается от добавления страницы в публичную часть сайта и осуществляется за несколько простых шагов. Но для начала создадим новое приложение spec в нашем проекте со следующей структурой:

А затем добавим в settings.py наше приложение spec:

1. Создания представления

Пишем обычное представление в views.py , добавляя необходимую логику, к примеру:

2. Создание шаблона

Я обычно наследуюсь от базового шаблона, который поставляется приложением admin от Django (соответственно, вы можете найти этот наследуемый шаблон в приложении admin в папке django/contrib/admin/ ).

В качестве примера приведу такой шаблон admin_custom_page.html :

Обычно, я добавляю в block title название, соответствующее содержанию страницы, и само содержание в block content . При необходимости можно стилизовать страницу и изменить навигационную цепочку, расскоментировав соответствующие блоки.

3. Добавление url в url_patterns

Сначала свяжем url с нашим view в файле urls.py нашего приложения spec:

А затем подключим urls.py приложения spec в urls.py нашего проекта:

Теперь в браузере по адресу http://localhost:8000/admin-custom-page/ можно увидеть тестовую страницу.

Теперь нужно позаботиться о том, где эту ссылку разместить в админке. Я не случайно оставил в примере url-ы:

Чуть позже я покажу, как для каждого приложения admin_tools и cms обычно добавляю ссылки.

Хочу заметить, что если вам нужно просто вывести статическую страницу на сайт без какой-либо обработки информации, то можно не использовать view (то есть не выполнять шаг 1), а просто использовать TemplateView (в шаге 3) в файле spec/urls.py :

Для работоспособности примера не забудьте создать шаблон static_admin_custom_page.html , например такой:

Конечно, данная «статическая» страница может выполнять какую-либо логику с использованием тех же шаблонных фильтров или тегов.

4.1 Добавление ссылки в админку

Чтобы для перехода на страницу жёстко не вбивать ссылку в строку браузера, а переходить на неё с какой-нибудь части сайта, нужно где-нибудь её разместить. Ниже показаны 3 варианта добавления ссылки в разные админские части сайта, вы можете использовать любой из них или все вместе.

Вариант 1. Обычное добавление ссылки на главную страницу приложения админки

Попробуем добавить ссылку на главную страницу админки над блоком «Все приложения». Для этого можно поступить следующим образом: создаём ещё одно приложение custom_admin внутри приложения spec со следующей структурой:

Жирным выделены добавленные файлы и папки.

Добавим в шаблон index.html нашу ссылку:

В шаблоне видно, что мы разместили ссылку поверх всего содержимого блока content. Поизучайте шаблон admin/index.html джанговского приложения admin, чтобы понимать как ещё можно кастомизировать шаблон.

Далее добавим custom_admin в settings.py :

Теперь перейдём по ссылке http://localhost:8000/admin/ , вы должны увидеть примерно следующее:

Вариант 2. Добавление ссылки в dashboard приложения admin_tools


Сначала нужно активировать приложение admin_tools:

Далее добавим файл dashboard.py в приложение spec:

В файле dashboard.py добавим кастомный модуль CustomPagesModule в наш дэшборд админки:

Сам шаблон test_pages_dashboard.html может состоять из:

Теперь, открыв ссылку http://localhost:8000/admin/ , вы должны увидеть добавленный модуль с нашей ссылкой:

Вариант 3. Добавление ссылки в меню django-cms

Чтобы отобразить пункт меню с ссылкой на нашу тестовую страницу, нужно добавить файл cms_toolbars.py :

Примерно с таким содержанием:

Вот и всё! Теперь вы можете увидеть новый пункт django-cms меню:

Как видите, существует несколько способов отобразить свою страницу в админке. Самый лёгкий вариант оказался через django-cms.

Подключение интерфейса администратора Django

В предыдущих мануалах этой серии Django вы узнали, как запустить приложение Django, связать его с MySQL и создать модели баз данных Posts и Comments.

Читайте также:

Данный мануал научит вас подключать интерфейс администратора Django для управления блогом. Интерфейс администратора Django предварительно поставляется вместе с пользовательским интерфейсом, который предназначен для управления контентом веб-сайта.

Стоит отметить: официальная документация Django указывает, что автоматически созданный интерфейс администратора Django идеально подходит для внутреннего использования организации, однако создавать веб-приложение на его основе крайне не рекомендуется. Чтобы сделать интерфейс более ориентированным на процесс, лучше написать собственные виды для администраторской части.

1: Включение Django Admin

Чтобы включить Django Admin, нужно добавить его в список INSTALLED_APPS в файле settings.py.

Перейдите в каталог:

Теперь откройте settings.py:

Если django.contrib.admin еще нет в списке INSTALLED_APPS, добавьте в список эту строку. Список должен выглядеть так:

.
# Application definition
INSTALLED_APPS = [
‘blogsite’,
‘django.contrib.admin’,
‘django.contrib.auth’,
‘django.contrib.contenttypes’,
‘django.contrib.sessions’,
‘django.contrib.messages’,
‘django.contrib.staticfiles’,
]
.

Сохраните и закройте файл.

Затем откройте файл urls.py:

Этот файл должен выглядеть так:

.
from django.conf.urls import url
from django.contrib import admin
urlpatterns = [
url(r’^admin/’, admin.site.urls),
]

Как видите, значение r^admin/ передается аргументу url. Так Python выполняет регулярные выражения.

Регулярные выражения – это способ поиска или сопоставления строковых шаблонов. Python использует r, чтобы интерпретировать следующий текст после символа каретки (^) как необработанную строку. Другими словами, специальные символы, такие как слеш (/), будут интерпретироваться так, как они есть, что полезно в случае с urls.

Теперь, когда веб-проект Django имеет соответствующий код в файлах settings.py и urls.py, у приложения есть доступ к моделям и пользовательскому интерфейсу администратора.

2: Проверка установки Django Admin

Теперь нужно мигрировать модели в БД, чтобы она смогла обрабатывать новые модели Admin.

Откройте каталог, в котором хранится файл manage.py.

Запустите команду migrate, чтобы обновить модели (это нужно делать всякий раз, когда вы вносите какие-либо изменения в модели).

python3 manage.py migrate

Команда должна вернуть следующий вывод, потому что модель admin уже была добавлена, как вы видели при навигации по разделам INSTALLED_APPS файла settings.py.

Operations to perform:
Apply all migrations: admin, auth, blogsite, contenttypes, sessions
Running migrations:
No migrations to apply.

Теперь можно запустить сервер с помощью команды:

python3 manage.py runserver your-server-ip:8000

Затем можно открыть URL панели администратора в браузере:

На экране появится форма входа.

Если это так – вы успешно включили интерфейс администратора.

Однако пока что у вас нет аккаунта администратора. Создайте такой аккаунт, чтобы войти в интерфейс.

3: Создание учетной записи администратора

В браузере открывается страница входа в интерфейс, но пока что у вас нет учетных данных. Создать эти данные совсем не сложно.

Django предоставляет простой способ создания учетной записи суперпользователя. Для этого нужно запустить файл manage.py.

python3 manage.py createsuperuser

После этого будет запрошено имя пользователя, электронная почта и пароль. В данном руководстве используются условные данные admin_user, 8host@example.com и admin123. Укажите свои учетные данные, используйте сложный пароль.

Username (leave blank to use ‘root’): admin_user
Email address: 8host@example.com

Затем программа попросит дважды ввести пароль администратора в поле Password. При этом в поле не будут отображаться никакие символы – это делается в целях безопасности. Введя пароль, нажмите enter.

Password:
Password (again):

На данный момент у вас есть учетная запись администратора admin_user с паролем admin123.

Давайте попробуем войти в интерфейс администратора.

Откройте в браузере страницу:

Затем войдите в интерфейс, указав имя и пароль, которые вы только что создали. Вы получите доступ к странице Site administration.

Теперь нужно подключить блог к панели администратора.

4: Создание URL-шаблонов для моделей Post и Comment

Как видите, интерфейс администратора до сих пор не видит ваше приложение. Чтобы изменить это, нужно добавить и зарегистрировать блог с соответствующими моделями Post и Comment.

Создайте пустой файл urls.py в каталоге blogsite:

В этот файл можно вставить шаблон URL для блога, чтобы иметь возможность получить доступ к нему через интерфейс администратора.

Перейдите к каталогу, в котором хранится файл urls.py.

Добавьте в него такой код:

from django.conf.urls import url
from . import views
urlpatterns = [
url(r’^$’, views.posts, name=’posts’),
url(r’^$’, views.comments, name=’comments’)
]

Это выражения шаблонов URL, с помощью которых приложение может получить доступ к представлениям (views) для Posts и Comments (пока что их нет, но об этом речь пойдет в одном из мануалов данной серии).

5: Подключение блога к Django Admin

Подключив блог к интерфейсу администратора, вы сможете увидеть ссылки на Posts и Comments в панели. Как вы уже видели, на данный момент панель отображает только ссылки на Groups и Users.

Зарегистрируйте модели Posts и Comments в файле admin в каталоге blogsite.

Затем создайте файл admin.py:

Добавьте в файл следующие строки:

from django.contrib import admin
from blogsite.models import Post
from blogsite.models import Comment
admin.site.register(Post)
admin.site.register(Comment)

Сохраните и закройте файл.

Теперь модели Post и Comment зарегистрированы в панели администратора. Это позволит интерфейсу администратора выбирать эти модели и показывать их пользователю, который имеет доступ к панели.

6: Проверка настроек

Теперь, когда вы добавили соответствующий код Python, запустите сервер. Откройте страницу:

и войдите в аккаунт администратора, используя свои учетные данные.

На странице Site authorization вы увидите, что кроме моделей Authorization and authentication появится группа Blogsite, в которой будут ваши модели блога.

Заключение

Вы успешно подключили панель администратора к блогу.

Интерфейс администратора Django позволяет создавать сообщения и отслеживать комментарии в блоге.

В следующем мануале этой серии вы научитесь создавать представления для приложения.

Цукерберг рекомендует:  Вакансии NGENIX
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих