Сайт администрирования Django

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

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

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

Обзор

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

Если вы не используете шаблон проекта по умолчанию, вот требования:

1. Добавьте 'django.contrib.admin' и его зависимости - django.contrib.auth, django.contrib.contenttypes, django.contrib.messages и django.contrib.sessions - в настройки INSTALLED_APPS.
2. Настройте бэкенд DjangoTemplates в настройках TEMPLATES с django.contrib.auth.context_processors.auth и django.contrib.messages.context_processors.messages в опции 'context_processors' настройки OPTIONS.
3. Если вы настраивали настройки MIDDLEWARE, django.contrib.auth.middleware.AuthenticationMiddleware и django.contrib.messages.middleware.MessageMiddleware должны быть включены.

5. Подключите URL-адреса администрирования к вашему URLconf.

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

Если вам нужно создать пользователя для входа, используйте команду createsuperuser. По умолчанию вход в администрирование требует, чтобы у пользователя был установлен атрибут is_superuser или is_staff в значение True.

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

Другие темы

• Действия администрирования
• Генератор документации Django admin
• Настройка JavaScript в администрировании

ModelAdmin объекты

class ModelAdmin [source]

Класс ModelAdmin представляет модель в интерфейсе администрирования. Обычно они хранятся в файле с именем admin.py в вашем приложении. Давайте рассмотрим очень простой пример ModelAdmin:

from django.contrib import admin
from myproject.myapp.models import Author

class AuthorAdmin(admin.ModelAdmin):
    pass
admin.site.register(Author, AuthorAdmin)

Нужен ли вам объект ModelAdmin?

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

from django.contrib import admin
from myproject.myapp.models import Author

admin.site.register(Author)

Декоратор register

register(*models, site=django.admin.sites.site) [source]

Также есть декоратор для регистрации ваших классов ModelAdmin:

from django.contrib import admin
from .models import Author

@admin.register(Author)
class AuthorAdmin(admin.ModelAdmin):
    pass

Он принимает один или несколько классов моделей для регистрации в ModelAdmin. Если вы используете кастомный AdminSite, передайте его в качестве ключевого аргумента site:

from django.contrib import admin
from .models import Author, Editor, Reader
from myproject.admin_site import custom_admin_site

@admin.register(Author, Reader, Editor, site=custom_admin_site)
class PersonAdmin(admin.ModelAdmin):
    pass

Вы не можете использовать этот декоратор, если вам нужно сослаться на ваш класс админ-модели в методе __init__() , например super(PersonAdmin, self).__init__(*args, **kwargs). Вы можете использовать super().__init__(*args, **kwargs).

Обнаружение файлов администрирования

Когда вы помещаете 'django.contrib.admin' в настройку INSTALLED_APPS, Django автоматически ищет модуль admin в каждом приложении и импортирует его.

class apps.AdminConfig

Это стандартный класс AppConfig для администрирования. Он вызывает autodiscover() при запуске Django.

class apps.SimpleAdminConfig

Этот класс работает как AdminConfig, за исключением того, что не вызывает autodiscover().

default_site

Добавлено в Django 2.1.

Путь к классу сайта администрирования по умолчанию или вызываемой функции, которая возвращает экземпляр сайта. По умолчанию 'django.contrib.admin.sites.AdminSite'. См. Замена сайта администрирования по умолчанию для использования.

autodiscover() [source]

Эта функция пытается импортировать модуль admin в каждом установленных приложении. Такие модули должны регистрировать модели в администрировании.

Обычно вам не нужно вызывать эту функцию напрямую, так как AdminConfig вызывает её при запуске Django.

Если вы используете кастомный AdminSite, обычно импортируйте все классы ModelAdmin в свой код и зарегистрируйте их в кастомном AdminSite. В этом случае, чтобы отключить автоматическое обнаружение, вы должны поместить 'django.contrib.admin.apps.SimpleAdminConfig' вместо 'django.contrib.admin' в настройки INSTALLED_APPS.

ModelAdmin опции

Класс ModelAdmin очень гибкий. Он имеет несколько вариантов для настройки интерфейса. Все опции определены в подклассе ModelAdmin:

from django.contrib import admin

class AuthorAdmin(admin.ModelAdmin):
    date_hierarchy = 'pub_date'

ModelAdmin.actions

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

ModelAdmin.actions_on_top

ModelAdmin.actions_on_bottom

Управляет тем, где на странице отображается панель действий. По умолчанию админ-панель отображает действия вверху страницы (actions_on_top = True; actions_on_bottom = False).

ModelAdmin.actions_selection_counter

Управляет отображением счётчика выделенных элементов рядом с выпадающим списком действий. По умолчанию, админская страница со списком изменений отображает его (actions_selection_counter = True).

ModelAdmin.date_hierarchy

Установите date_hierarchy имя поля DateField или DateTimeField в вашей модели, и страница списка изменений будет содержать навигацию по датам, основанную на этом поле.

Пример:

date_hierarchy = 'pub_date'

Также можно указать поле связанной модели, используя поиск __, например:

date_hierarchy = 'author__pub_date'

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

Примечание

date_hierarchy использует QuerySet.datetimes() внутри. Обратитесь к документации для некоторых ограничений, когда включена поддержка часовых поясов (USE_TZ = True).

ModelAdmin.empty_value_display

Этот атрибут переопределяет значение по умолчанию для полей записей, которые пусты (None, пустая строка и т.д.). Значение по умолчанию — - (тире). Например:

from django.contrib import admin

class AuthorAdmin(admin.ModelAdmin):
    empty_value_display = '-empty-'

Также можно переопределить empty_value_display для всех страниц админки с помощью AdminSite.empty_value_display, или для конкретных полей так:

from django.contrib import admin

class AuthorAdmin(admin.ModelAdmin):
    fields = ('name', 'title', 'view_birth_date')

    def view_birth_date(self, obj):
        return obj.birth_date

    view_birth_date.empty_value_display = '???'

ModelAdmin.exclude

Этот атрибут, если задан, должен быть списком имён полей, которые нужно исключить из формы.

Например, рассмотрим следующую модель:

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)
    title = models.CharField(max_length=3)
    birth_date = models.DateField(blank=True, null=True)

Если вам нужна форма для модели Author, которая включает только поля name и title, вы бы указали fields или exclude так:

from django.contrib import admin

class AuthorAdmin(admin.ModelAdmin):
    fields = ('name', 'title')

class AuthorAdmin(admin.ModelAdmin):
    exclude = ('birth_date',)

Поскольку модель Author имеет только три поля, name, title, и birth_date, формы, полученные по этим объявлениям, будут содержать ровно те же поля.

ModelAdmin.fields

Используйте опцию fields для внесения простых изменений в макет форм на страницах «добавить» и «изменить», таких как отображение только подмножества доступных полей, изменение их порядка или группировка в строки. Например, вы могли бы определить упрощённую версию админской формы для модели django.contrib.flatpages.models.FlatPage следующим образом:

class FlatPageAdmin(admin.ModelAdmin):
    fields = ('url', 'title', 'content')

В приведённом выше примере будут отображаться только поля url, title и content, последовательно, в форме. fields может содержать значения, определённые в ModelAdmin.readonly_fields, для отображения в качестве только для чтения.

Для более сложных потребностей макета см. опцию fieldsets.

Опция fields принимает те же типы значений, что и list_display, за исключением того, что вызываемые объекты не принимаются. Имена методов модели и админа модели будут использоваться только если они указаны в readonly_fields.

Чтобы отображать несколько полей в одной строке, оберните эти поля в свои собственные кортежи. В этом примере поля url и title будут отображаться в одной строке, а поле content будет отображаться ниже их в отдельной строке:

class FlatPageAdmin(admin.ModelAdmin):
    fields = (('url', 'title'), 'content')

Примечание

Не следует путать эту опцию fields с ключом словаря fields, который находится внутри опции fieldsets, как описано в следующем разделе.

Если ни опция fields ни fieldsets не заданы, Django по умолчанию отобразит каждое поле, которое не является AutoField и имеет editable=True, в одном наборе полей в том же порядке, в котором поля определены в модели.

ModelAdmin.fieldsets

Установите fieldsets для управления макетом страниц администрирования «добавить» и «изменить».

fieldsets — это список пар кортежей, где каждая пара кортежей представляет <fieldset> на странице админ-формы. (Набор полей — это «раздел» формы.)

Пары кортежей имеют формат (name, field_options), где name — строка, представляющая заголовок набора полей, а field_options — словарь с информацией о наборе полей, включая список полей, которые должны быть отображены в нём.

Полный пример, взятый из модели django.contrib.flatpages.models.FlatPage:

from django.contrib import admin

class FlatPageAdmin(admin.ModelAdmin):
    fieldsets = (
        (None, {
            'fields': ('url', 'title', 'content', 'sites')
        }),
        ('Advanced options', {
            'classes': ('collapse',),
            'fields': ('registration_required', 'template_name'),
        }),
    )

Это приводит к отображению страницы админки примерно так:

Если ни опция fieldsets ни fields не заданы, Django по умолчанию отобразит каждое поле, которое не является AutoField и имеет editable=True, в одном наборе полей в том же порядке, в котором поля определены в модели.

Словарь field_options может иметь следующие ключи:

• fields

  Кортеж имён полей для отображения в этом наборе полей. Этот ключ обязателен.

  Пример:

  {
  'fields': ('first_name', 'last_name', 'address', 'city', 'state'),
  }
  

  Как и с опцией fields, чтобы отобразить несколько полей в одной строке, оберните эти поля в свои собственные кортежи. В этом примере поля first_name и last_name будут отображаться в одной строке:

  {
  'fields': (('first_name', 'last_name'), 'address', 'city', 'state'),
  }
  

  fields может содержать значения, определённые в readonly_fields, для отображения в качестве только для чтения.

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

• classes

  Список или кортеж, содержащий дополнительные CSS-классы, которые нужно применить к набору полей.

  Пример:

  {
  'classes': ('wide', 'extrapretty'),
  }
  

  Два полезных класса, определённые в стиле по умолчанию админской страницы, — collapse и wide. Наборы полей со стилем collapse будут изначально свёрнуты в админке и будут заменены маленькой ссылкой «нажмите, чтобы развернуть». Наборы полей со стилем wide будут иметь дополнительный горизонтальный отступ.

• description

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

  Обратите внимание, что это значение не экранируется HTML при отображении в интерфейсе администрирования. Это позволяет включить HTML, если необходимо. В противном случае можно использовать обычный текст и django.utils.html.escape() для экранирования HTML-специальных символов.

ModelAdmin.filter_horizontal

По умолчанию, ManyToManyField отображается в админке с <select multiple>. Однако, многовыборные поля могут быть неудобными при выборе многих элементов. Добавление ManyToManyField в этот список вместо этого будет использовать удобный ненавязчивый JavaScript-интерфейс «фильтра», который позволяет искать среди вариантов. Невыбранные и выбранные варианты отображаются в двух полях рядом. См. filter_vertical для использования вертикального интерфейса.

ModelAdmin.filter_vertical

То же, что и filter_horizontal, но использует вертикальное отображение интерфейса фильтра с полем невыбранных вариантов, расположенным над полем выбранных вариантов.

ModelAdmin.form

По умолчанию для вашей модели динамически создаётся ModelForm. Она используется для создания формы, отображаемой на страницах добавления/изменения. Вы можете легко предоставить собственную ModelForm для переопределения поведения любой формы по умолчанию на страницах добавления/изменения. В качестве альтернативы, вы можете настроить форму по умолчанию, вместо того, чтобы указывать совершенно новую, используя метод ModelAdmin.get_form().

Пример см. в разделе Добавление пользовательской валидации в админ-панель.

Примечание

Если вы определяете атрибут Meta.model для ModelForm, вы также должны определить атрибут Meta.fields (или атрибут Meta.exclude). Однако, поскольку у админ-панели есть свой способ определения полей, атрибут Meta.fields будет игнорироваться.

Если атрибут ModelForm будет использоваться только для админ-панели, проще всего опустить атрибут Meta.model, так как ModelAdmin предоставит правильную модель для использования. В качестве альтернативы, вы можете установить fields = [] в классе Meta для удовлетворения валидации на ModelForm.

Примечание

Если ваши ModelForm и ModelAdmin оба определяют опцию exclude, тогда ModelAdmin имеет приоритет:

from django import forms
from django.contrib import admin
from myapp.models import Person

class PersonForm(forms.ModelForm):

    class Meta:
        model = Person
        exclude = ['name']

class PersonAdmin(admin.ModelAdmin):
    exclude = ['age']
    form = PersonForm

В приведённом выше примере поле «age» будет исключено, но поле «name» будет включено в сгенерированную форму.

ModelAdmin.formfield_overrides

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

Поскольку это немного абстрактно, давайте рассмотрим конкретный пример. Наиболее распространённое использование formfield_overrides — добавление пользовательского виджета для определённого типа поля. Представьте, что мы написали RichTextEditorWidget , который мы хотели бы использовать для полей большого текста вместо стандартного <textarea>. Вот как мы это сделаем:

from django.contrib import admin
from django.db import models

# Import our custom widget and our model from where they're defined
from myapp.models import MyModel
from myapp.widgets import RichTextEditorWidget

class MyModelAdmin(admin.ModelAdmin):
    formfield_overrides = {
        models.TextField: {'widget': RichTextEditorWidget},
    }

Обратите внимание, что ключом в словаре является фактический класс поля, а не строка. Значение — другой словарь; эти аргументы будут переданы методу __init__() поля формы. Подробности см. в API форм.

Предупреждение

Если вы хотите использовать пользовательский виджет с полем связи (т. е. ForeignKey или ManyToManyField), убедитесь, что вы не включили имя этого поля в raw_id_fields, radio_fields, или autocomplete_fields.

formfield_overrides не позволит вам изменить виджет в полях связи, у которых raw_id_fields, radio_fields, или autocomplete_fields установлены. Это потому, что raw_id_fields, radio_fields, и autocomplete_fields подразумевают собственные пользовательские виджеты.

ModelAdmin.inlines

См. объекты InlineModelAdmin ниже, а также ModelAdmin.get_formsets_with_inlines().

ModelAdmin.list_display

Установите list_display для управления полями, отображаемыми на странице списка изменений админ-панели.

Пример:

list_display = ('first_name', 'last_name')

Если вы не установите list_display, админ-сайт отобразит один столбец, который отображает __str__() каждого объекта.

Существует четыре типа значений, которые могут быть использованы в list_display:

• Имя поля модели. Например:

  class PersonAdmin(admin.ModelAdmin):
      list_display = ('first_name', 'last_name')
  

• Вызываемый объект, принимающий один аргумент — экземпляр модели. Например:

  def upper_case_name(obj):
      return ("%s %s" % (obj.first_name, obj.last_name)).upper()
  upper_case_name.short_description = 'Name'
  
  class PersonAdmin(admin.ModelAdmin):
      list_display = (upper_case_name,)
  

• Строка, представляющая метод ModelAdmin модели, принимающий один аргумент — экземпляр модели. Например:

  class PersonAdmin(admin.ModelAdmin):
      list_display = ('upper_case_name',)
  
      def upper_case_name(self, obj):
          return ("%s %s" % (obj.first_name, obj.last_name)).upper()
      upper_case_name.short_description = 'Name'
  

• Строка, представляющая атрибут или метод модели (без требуемых аргументов). Например:

  from django.contrib import admin
  from django.db import models
  
  class Person(models.Model):
      name = models.CharField(max_length=50)
      birthday = models.DateField()
  
      def decade_born_in(self):
          return self.birthday.strftime('%Y')[:3] + "0's"
      decade_born_in.short_description = 'Birth decade'
  
  class PersonAdmin(admin.ModelAdmin):
      list_display = ('name', 'decade_born_in')
  

Некоторые особые случаи относительно list_display:

• Если поле является ForeignKey, Django отобразит __str__() связанного объекта.
• ManyToManyField поля не поддерживаются, потому что это потребовало бы выполнения отдельного SQL-запроса для каждой строки в таблице. Если вам всё же нужно это сделать, предоставьте вашей модели пользовательский метод и добавьте имя этого метода в list_display. (См. ниже дополнительные сведения о пользовательских методах в list_display.)
• Если поле является BooleanField, Django отобразит привлекательный значок «вкл.» или «выкл.» вместо True или False.

• Если указанная строка является методом модели, ModelAdmin или вызываемым объектом, Django по умолчанию будет HTML-экранировать вывод. Чтобы экранировать пользовательский ввод и разрешить свои неэкранированные теги, используйте format_html().

  Вот полный пример модели:

  from django.contrib import admin
  from django.db import models
  from django.utils.html import format_html
  
  class Person(models.Model):
      first_name = models.CharField(max_length=50)
      last_name = models.CharField(max_length=50)
      color_code = models.CharField(max_length=6)
  
      def colored_name(self):
          return format_html(
              '<span style="color: #{};">{} {}</span>',
              self.color_code,
              self.first_name,
              self.last_name,
          )
  
  class PersonAdmin(admin.ModelAdmin):
      list_display = ('first_name', 'last_name', 'colored_name')
  

• Как уже показывали некоторые примеры, при использовании вызываемого объекта, метода модели или метода ModelAdmin, вы можете настроить заголовок колонки, добавив атрибут short_description к вызываемому объекту.

• Если значение поля None, пустая строка или итерируемый объект без элементов, Django отобразит - (тире). Вы можете переопределить это с помощью AdminSite.empty_value_display:

  from django.contrib import admin
  
  admin.site.empty_value_display = '(None)'
  

  Также можно использовать ModelAdmin.empty_value_display:

  class PersonAdmin(admin.ModelAdmin):
      empty_value_display = 'unknown'
  

  Или на уровне поля:

  class PersonAdmin(admin.ModelAdmin):
      list_display = ('name', 'birth_date_view')
  
      def birth_date_view(self, obj):
           return obj.birth_date
  
      birth_date_view.empty_value_display = 'unknown'
  

• Если указанная строка является методом модели, ModelAdmin или вызываемым объектом, возвращающим True или False, Django отобразит привлекательный значок «вкл.» или «выкл.», если вы зададите атрибут метода boolean со значением True.

  Вот полный пример модели:

  from django.contrib import admin
  from django.db import models
  
  class Person(models.Model):
      first_name = models.CharField(max_length=50)
      birthday = models.DateField()
  
      def born_in_fifties(self):
          return self.birthday.strftime('%Y')[:3] == '195'
      born_in_fifties.boolean = True
  
  class PersonAdmin(admin.ModelAdmin):
      list_display = ('name', 'born_in_fifties')
  

• Метод __str__() так же допустим в list_display как и любой другой метод модели, поэтому вполне допустимо сделать это:

  list_display = ('__str__', 'some_other_field')
  

• Обычно элементы list_display , которые не являются фактическими полями базы данных, не могут быть использованы в сортировке (потому что Django выполняет всю сортировку на уровне базы данных).

  Однако, если элемент list_display представляет определённое поле базы данных, вы можете указать это, установив атрибут admin_order_field элемента.

  Например:

  from django.contrib import admin
  from django.db import models
  from django.utils.html import format_html
  
  class Person(models.Model):
      first_name = models.CharField(max_length=50)
      color_code = models.CharField(max_length=6)
  
      def colored_first_name(self):
          return format_html(
              '<span style="color: #{};">{}</span>',
              self.color_code,
              self.first_name,
          )
  
      colored_first_name.admin_order_field = 'first_name'
  
  class PersonAdmin(admin.ModelAdmin):
      list_display = ('first_name', 'colored_first_name')
  

  Вышеупомянутое укажет Django на упорядочивание по полю first_name при попытке сортировки по colored_first_name в админ-панели.

  Для указания убывающего порядка с admin_order_field можно использовать префикс дефис перед именем поля. Используя приведенный выше пример, это будет выглядеть так:

  colored_first_name.admin_order_field = '-first_name'
  

  admin_order_field поддерживает запросы по поиску для сортировки по значениям в связанных моделях. Этот пример включает колонку «Имя автора» в отображении списка и позволяет сортировать её по имени:

  class Blog(models.Model):
      title = models.CharField(max_length=255)
      author = models.ForeignKey(Person, on_delete=models.CASCADE)
  
  class BlogAdmin(admin.ModelAdmin):
      list_display = ('title', 'author', 'author_first_name')
  
      def author_first_name(self, obj):
          return obj.author.first_name
  
      author_first_name.admin_order_field = 'author__first_name'
  

  Выражения запросов могут использоваться в admin_order_field. Например:

  from django.db.models import Value
  from django.db.models.functions import Concat
  
  class Person(models.Model):
      first_name = models.CharField(max_length=50)
      last_name = models.CharField(max_length=50)
  
      def full_name(self):
          return self.first_name + ' ' + self.last_name
      full_name.admin_order_field = Concat('first_name', Value(' '), 'last_name')
  

  Новое в Django 2.1:

  Добавлена поддержка выражений в admin_order_field.

• Элементы list_display также могут быть свойствами. Однако обратите внимание, что из-за того, как работают свойства в Python, установка short_description на свойстве возможна только при использовании функции property() и не с декоратором @property.

  Например:

  class Person(models.Model):
      first_name = models.CharField(max_length=50)
      last_name = models.CharField(max_length=50)
  
      def my_property(self):
          return self.first_name + ' ' + self.last_name
      my_property.short_description = "Full name of the person"
  
      full_name = property(my_property)
  
  class PersonAdmin(admin.ModelAdmin):
      list_display = ('full_name',)
  

• Имена полей в list_display также будут отображаться в качестве CSS-классов в выводе HTML, в виде column-<field_name> в каждом элементе <th>. Это можно использовать для установки ширины колонок в файле CSS, например.

• Django будет пытаться интерпретировать каждый элемент list_display в следующем порядке:

  • Поле модели.
  • Вызываемый объект.
  • Строка, представляющая атрибут ModelAdmin.
  • Строка, представляющая атрибут модели.

  Например, если у вас есть first_name как поле модели и как атрибут ModelAdmin, будет использоваться поле модели.

ModelAdmin.list_display_links

Используйте list_display_links для управления тем, какие поля в list_display должны быть связаны со страницей «изменить» для объекта.

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

• Установите его в None для отключения ссылок.

• Установите его в список или кортеж полей (в том же формате, что и list_display) для преобразования столбцов в ссылки.

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

В этом примере поля first_name и last_name будут связаны на странице списка изменений:

class PersonAdmin(admin.ModelAdmin):
    list_display = ('first_name', 'last_name', 'birthday')
    list_display_links = ('first_name', 'last_name')

В этом примере на странице списка изменений не будет ссылок:

class AuditEntryAdmin(admin.ModelAdmin):
    list_display = ('timestamp', 'message')
    list_display_links = None

ModelAdmin.list_editable

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

Примечание

list_editable взаимодействует с некоторыми другими параметрами определённым способом; вы должны учесть следующие правила:

• Любое поле в list_editable также должно быть в list_display. Вы не можете редактировать поле, которое не отображается!
• Одно и то же поле не может быть указано как в list_editable, так и в list_display_links — поле не может быть одновременно элементом формы и ссылкой.

Вы получите ошибку валидации, если какое-либо из этих правил будет нарушено.

ModelAdmin.list_filter

Установите list_filter для активации фильтров в правой боковой панели страницы списка изменений администратора, как показано на следующем снимке экрана:

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

• имя поля, где указанное поле должно быть либо BooleanField, CharField, DateField, DateTimeField, IntegerField, ForeignKey или ManyToManyField, например:

  class PersonAdmin(admin.ModelAdmin):
      list_filter = ('is_staff', 'company')
  

  Имена полей в list_filter также могут охватывать отношения с использованием __ поиска, например:

  class PersonAdmin(admin.UserAdmin):
      list_filter = ('company__name',)
  

• класс, наследующий от django.contrib.admin.SimpleListFilter, для которого необходимо задать title и parameter_name атрибуты и переопределить lookups и queryset методы, например:

  from datetime import date
  
  from django.contrib import admin
  from django.utils.translation import gettext_lazy as _
  
  class DecadeBornListFilter(admin.SimpleListFilter):
      # Human-readable title which will be displayed in the
      # right admin sidebar just above the filter options.
      title = _('decade born')
  
      # Parameter for the filter that will be used in the URL query.
      parameter_name = 'decade'
  
      def lookups(self, request, model_admin):
          """
          Returns a list of tuples. The first element in each
          tuple is the coded value for the option that will
          appear in the URL query. The second element is the
          human-readable name for the option that will appear
          in the right sidebar.
          """
          return (
              ('80s', _('in the eighties')),
              ('90s', _('in the nineties')),
          )
  
      def queryset(self, request, queryset):
          """
          Returns the filtered queryset based on the value
          provided in the query string and retrievable via
          `self.value()`.
          """
          # Compare the requested value (either '80s' or '90s')
          # to decide how to filter the queryset.
          if self.value() == '80s':
              return queryset.filter(birthday__gte=date(1980, 1, 1),
                                      birthday__lte=date(1989, 12, 31))
          if self.value() == '90s':
              return queryset.filter(birthday__gte=date(1990, 1, 1),
                                      birthday__lte=date(1999, 12, 31))
  
  class PersonAdmin(admin.ModelAdmin):
      list_filter = (DecadeBornListFilter,)
  

  Примечание

  Для удобства объект HttpRequest передаётся в lookups и queryset методы, например:

  class AuthDecadeBornListFilter(DecadeBornListFilter):
  
      def lookups(self, request, model_admin):
          if request.user.is_superuser:
              return super().lookups(request, model_admin)
  
      def queryset(self, request, queryset):
          if request.user.is_superuser:
              return super().queryset(request, queryset)
  

  Также для удобства объект ModelAdmin передаётся в lookups метод, например, если вы хотите основывать поиск на доступных данных:

  class AdvancedDecadeBornListFilter(DecadeBornListFilter):
  
      def lookups(self, request, model_admin):
          """
          Only show the lookups if there actually is
          anyone born in the corresponding decades.
          """
          qs = model_admin.get_queryset(request)
          if qs.filter(birthday__gte=date(1980, 1, 1),
                        birthday__lte=date(1989, 12, 31)).exists():
              yield ('80s', _('in the eighties'))
          if qs.filter(birthday__gte=date(1990, 1, 1),
                        birthday__lte=date(1999, 12, 31)).exists():
              yield ('90s', _('in the nineties'))
  

• кортеж, где первый элемент — имя поля, а второй — класс, наследующий от django.contrib.admin.FieldListFilter, например:

  class PersonAdmin(admin.ModelAdmin):
      list_filter = (
          ('is_staff', admin.BooleanFieldListFilter),
      )
  

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

  class BookAdmin(admin.ModelAdmin):
      list_filter = (
          ('author', admin.RelatedOnlyFieldListFilter),
      )
  

  Предполагая, что author является ForeignKey модели User, это ограничит выбор list_filter вариантами пользователей, которые написали книгу вместо перечисления всех пользователей.

  Примечание

  API FieldListFilter считается внутренним и может быть изменён.

Фильтры списка обычно отображаются только если фильтр имеет более одного варианта. Метод has_output() фильтра управляет отображением или скрытием.

Можно указать пользовательский шаблон для рендеринга фильтра списка:

class FilterWithCustomTemplate(admin.SimpleListFilter):
    template = "custom_template.html"

См. стандартный шаблон, предоставленный Django (admin/filter.html) для конкретного примера.

ModelAdmin.list_max_show_all

Установите list_max_show_all для управления количеством элементов, которые могут отображаться на странице списка администрирования «Показать все». Администратор отобразит ссылку «Показать все» на странице списка изменений только если общее количество результатов меньше или равно этому значению. По умолчанию это значение 200.

ModelAdmin.list_per_page

Установите list_per_page для управления количеством элементов на каждой постраничной странице списка изменений администратора. По умолчанию это значение 100.

ModelAdmin.list_select_related

Установите list_select_related для указания Django использовать select_related() при получении списка объектов на странице списка изменений администратора. Это может сэкономить вам множество баз данных.

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

Когда значение True, select_related() всегда вызывается. Когда значение установлено в False, Django обратится к list_display и вызовет select_related() если присутствует ForeignKey.

Если вам нужен более тонкий контроль, используйте кортеж (или список) в качестве значения для list_select_related. Пустой кортеж предотвратит вызов select_related Django. Любой другой кортеж будет передан напрямую в select_related в качестве параметров. Например:

class ArticleAdmin(admin.ModelAdmin):
    list_select_related = ('author', 'category')

вызовет select_related('author', 'category').

Если вам нужно указать динамическое значение, основанное на запросе, вы можете реализовать метод get_list_select_related().

Примечание

ModelAdmin игнорирует этот атрибут, когда select_related() уже был вызван на QuerySet списка изменений.

ModelAdmin.ordering

Установите ordering для указания порядка сортировки списков объектов в представлениях Django администратора. Это должен быть список или кортеж в том же формате, что и параметр ordering модели.

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

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

Учёт производительности при сортировке

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

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

ModelAdmin.paginator

Класс пагинатора, который будет использоваться для пагинации. По умолчанию используется django.core.paginator.Paginator. Если у настраиваемого класса пагинатора нет того же интерфейса конструктора, что и у django.core.paginator.Paginator, вам также потребуется реализовать ModelAdmin.get_paginator().

ModelAdmin.prepopulated_fields

Установите prepopulated_fields в словарь, сопоставляющий имена полей с полями, которые следует заполнить:

class ArticleAdmin(admin.ModelAdmin):
    prepopulated_fields = {"slug": ("title",)}

При установке указанные поля будут использовать немного JavaScript для заполнения из назначенных полей. Основное использование этой функциональности — автоматическое создание значения для SlugField полей из одного или нескольких других полей. Сгенерированное значение получается путём конкатенации значений исходных полей, а затем преобразования этого результата в допустимый слаг (например, замена пробелов на дефисы; приведение ASCII букв к нижнему регистру; удаление различных английских стоп-слов, таких как «a», «an», «as» и аналогичных).

Поля, заполненные заранее, не изменяются JavaScript после сохранения значения. Обычно нежелательно, чтобы слоги изменялись (что приведёт к изменению URL объекта, если слаг используется в нём).

prepopulated_fields не принимает DateTimeField, ForeignKey, OneToOneField, и ManyToManyField поля.

ModelAdmin.preserve_filters

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

ModelAdmin.radio_fields

По умолчанию, админка Django использует интерфейс выпадающего списка (<select>) для полей, которые ForeignKey или имеют choices установленным. Если поле присутствует в radio_fields, Django будет использовать интерфейс с радиокнопками вместо этого. Предполагая, что group это ForeignKey на модели Person:

class PersonAdmin(admin.ModelAdmin):
    radio_fields = {"group": admin.VERTICAL}

У вас есть выбор использовать HORIZONTAL или VERTICAL из модуля django.contrib.admin.

Не включайте поле в radio_fields, если это не ForeignKey или не имеет choices установленным.

ModelAdmin.autocomplete_fields

autocomplete_fields - это список полей ForeignKey и/или ManyToManyField, которые вы хотите изменить на автодополняемые поля Select2.

По умолчанию, админка использует интерфейс выпадающего списка (<select>) для этих полей. Иногда вам не нужно загружать все связанные объекты для отображения в выпадающем списке.

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

Вы должны определить search_fields на связанном объекте ModelAdmin, так как автодополнение использует его для поиска.

Чтобы избежать несанкционированного раскрытия данных, пользователи должны иметь разрешение view или change на связанный объект для использования автодополнения.

Сортировка и постраничная навигация результатов контролируются методами связанной модели ModelAdmin, get_ordering() и get_paginator().

В следующем примере поле ChoiceAdmin имеет автодополняемое поле для связи с ForeignKey до Question. Результаты фильтруются по полю question_text и сортируются по полю date_created.

class QuestionAdmin(admin.ModelAdmin):
    ordering = ['date_created']
    search_fields = ['question_text']

class ChoiceAdmin(admin.ModelAdmin):
    autocomplete_fields = ['question']

Учёт производительности при работе с большими наборами данных

Сортировка с использованием ModelAdmin.ordering может вызвать проблемы с производительностью, так как сортировка большого набора результатов будет медленной.

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

В таких случаях рекомендуется написать собственную реализацию ModelAdmin.get_search_results() с использованием полнотекстового индексированного поиска.

Вы также можете изменить Paginator на очень больших таблицах, так как по умолчанию постраничный вывод выполняет запрос count(). Например, вы можете переопределить стандартную реализацию свойства Paginator.count.

ModelAdmin.raw_id_fields

По умолчанию, админка Django использует интерфейс выпадающего списка (<select>) для полей, которые ForeignKey. Иногда вам не нужно загружать все связанные объекты для отображения в выпадающем списке.

raw_id_fields - это список полей, которые вы хотите изменить на виджет Input для ForeignKey или ManyToManyField.

class ArticleAdmin(admin.ModelAdmin):
    raw_id_fields = ("newspaper",)

Виджет raw_id_fields Input должен содержать первичный ключ, если поле является ForeignKey, или список значений, разделенных запятыми, если поле является ManyToManyField. Виджет raw_id_fields отображает кнопку поиска рядом с полем, которая позволяет пользователям искать и выбирать значение.

ModelAdmin.readonly_fields

По умолчанию, админка отображает все поля как редактируемые. Любые поля в этом списке (которые должны быть list или tuple) будут отображать данные как есть и не будут редактируемыми; они также исключаются из ModelForm при создании и редактировании. Обратите внимание, что при указании ModelAdmin.fields или ModelAdmin.fieldsets поля для чтения должны присутствовать для отображения (в противном случае они игнорируются).

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

Поле для чтения может отображать не только данные из поля модели, но и результат метода модели или метода самого класса ModelAdmin. Это очень похоже на поведение ModelAdmin.list_display. Это предоставляет простой способ использования админки для предоставления отзывов о состоянии редактируемых объектов, например:

from django.contrib import admin
from django.utils.html import format_html_join
from django.utils.safestring import mark_safe

class PersonAdmin(admin.ModelAdmin):
    readonly_fields = ('address_report',)

    def address_report(self, instance):
        # assuming get_full_address() returns a list of strings
        # for each line of the address and you want to separate each
        # line by a linebreak
        return format_html_join(
            mark_safe('<br>'),
            '{}',
            ((line,) for line in instance.get_full_address()),
        ) or mark_safe("<span class='errors'>I can't determine this address.</span>")

    # short_description functions like a model field's verbose_name
    address_report.short_description = "Address"

ModelAdmin.save_as

Установите save_as для активации функции «сохранить как новый» в формах изменения админки.

Обычно у объектов есть три варианта сохранения: «Сохранить», «Сохранить и продолжить редактирование» и «Сохранить и добавить другой». Если save_as имеет значение True, «Сохранить и добавить другой» будет заменён кнопкой «Сохранить как новый», которая создаст новый объект (с новым идентификатором) вместо обновления существующего.

По умолчанию, save_as установлено в False.

ModelAdmin.save_as_continue

Когда save_as=True, по умолчанию после сохранения нового объекта происходит переадресация на страницу изменения этого объекта. Если вы установите save_as_continue=False, переадресация будет на страницу списка изменений.

По умолчанию, save_as_continue установлено в True.

ModelAdmin.save_on_top

Установите save_on_top для добавления кнопок сохранения в верхней части форм изменения админки.

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

По умолчанию, save_on_top установлено в False.

ModelAdmin.search_fields

Установите search_fields для включения поля поиска на странице списка изменений админки. Это должно быть списком имён полей, которые будут проиндексированы при каждом запросе в поле поиска.

Эти поля должны быть текстовыми полями, например CharField или TextField. Вы также можете выполнить связанный поиск по ForeignKey или ManyToManyField с помощью синтаксиса поиска “follow”:

search_fields = ['foreign_key__related_fieldname']

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

search_fields = ['user__email']

Когда пользователь выполняет поиск в поле поиска админки, Django разбивает запрос на слова и возвращает все объекты, содержащие каждое из слов, без учёта регистра (используя поиск icontains), при этом каждое слово должно присутствовать хотя бы в одном из search_fields. Например, если search_fields установлено в ['first_name', 'last_name'] и пользователь ищет john lennon, Django выполнит запрос, эквивалентный следующему SQL-операторку WHERE:

WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')
AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')

Если вы не хотите использовать icontains в качестве поиска, вы можете использовать любой поиск, добавив его к полю. Например, вы можете использовать exact, установив search_fields в ['first_name__exact'].

Обратите внимание, что из-за того, что поисковые термины разбиваются и объединяются по принципу И, как описано выше, поиск с помощью exact работает только со одним поисковым словом, так как два или более слова не могут все быть точным совпадением, если все слова не одинаковы.

Новое в Django 2.1:

Добавлена возможность указать поиск по полю.

Также доступны некоторые (более старые) сокращения для указания поиска по полю. Вы можете добавить префикс к полю в search_fields с помощью следующих символов, что эквивалентно добавлению __<lookup> к полю:

Префикс	Поиск
^	startswith
=	iexact
@	search
None	icontains

Если вам нужно настроить поиск, вы можете использовать ModelAdmin.get_search_results() для обеспечения дополнительного или альтернативного поведения поиска.

ModelAdmin.show_full_result_count

Установите show_full_result_count для управления отображением полного количества объектов на отфильтрованной странице админки (например, 99 results (103 total)). Если этот параметр установлен в False, вместо этого отображается текст, подобный 99 results (Show all).

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

ModelAdmin.sortable_by

Новое в Django 2.1.

По умолчанию страница списка изменений позволяет сортировать по всем полям модели (и вызовам, которые имеют свойство admin_order_field) указанным в list_display.

Если вы хотите отключить сортировку для некоторых столбцов, установите sortable_by в коллекцию (например, list, tuple, или set ), подмножество list_display, которое вы хотите сделать сортируемым. Пустая коллекция отключает сортировку для всех столбцов.

Если вам нужно динамически указать этот список, реализуйте метод get_sortable_by() вместо этого.

ModelAdmin.view_on_site

Установите view_on_site для управления отображением ссылки «Просмотр на сайте». Эта ссылка должна перенаправлять вас на URL, где вы можете отобразить сохранённый объект.

Это значение может быть либо флагом булевого типа, либо вызываемым объектом. Если True (по умолчанию), будет использоваться метод объекта get_absolute_url() для генерации URL.

Если у вашей модели есть метод get_absolute_url(), но вы не хотите, чтобы кнопка «Просмотр на сайте» отображалась, вам нужно установить view_on_site в False:

from django.contrib import admin

class PersonAdmin(admin.ModelAdmin):
    view_on_site = False

Если это вызываемый объект, он принимает экземпляр модели в качестве параметра. Например:

from django.contrib import admin
from django.urls import reverse

class PersonAdmin(admin.ModelAdmin):
    def view_on_site(self, obj):
        url = reverse('person-detail', kwargs={'slug': obj.slug})
        return 'https://example.com' + url

Настраиваемые параметры шаблона

Раздел Замена шаблонов админки описывает, как переопределить или расширить стандартные шаблоны админки. Используйте следующие параметры для переопределения стандартных шаблонов, используемых представлениями ModelAdmin:

ModelAdmin.add_form_template

Путь к настраиваемому шаблону, используемому add_view().

ModelAdmin.change_form_template

Путь к настраиваемому шаблону, используемому change_view().

ModelAdmin.change_list_template

Путь к настраиваемому шаблону, используемому changelist_view().

ModelAdmin.delete_confirmation_template

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

ModelAdmin.delete_selected_confirmation_template

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

ModelAdmin.object_history_template

Путь к настраиваемому шаблону, используемому history_view().

ModelAdmin.popup_response_template

Путь к настраиваемому шаблону, используемому response_add(), response_change() и response_delete().

ModelAdmin методы

ModelAdmin.save_model(request, obj, form, change) [source]

Метод save_model получает HttpRequest, экземпляр модели, экземпляр ModelForm и булевое значение, основанное на том, добавляется или изменяется объект. Переопределение этого метода позволяет выполнять операции до или после сохранения. Вызовите super().save_model() для сохранения объекта с помощью Model.save().

Например, чтобы добавить request.user к объекту перед сохранением:

from django.contrib import admin

class ArticleAdmin(admin.ModelAdmin):
    def save_model(self, request, obj, form, change):
        obj.user = request.user
        super().save_model(request, obj, form, change)

ModelAdmin.delete_model(request, obj) [source]

Метод delete_model получает HttpRequest и экземпляр модели. Переопределение этого метода позволяет выполнять операции до или после удаления. Вызовите super().delete_model() для удаления объекта с помощью Model.delete().

ModelAdmin.delete_queryset(request, queryset) [source]

Новое в Django 2.1.

Метод delete_queryset() получает HttpRequest и QuerySet объектов, которые будут удалены. Переопределите этот метод, чтобы настроить процесс удаления для действия «Удалить выбранные объекты» действие.

ModelAdmin.save_formset(request, form, formset, change) [source]

Метод save_formset получает HttpRequest, родительский ModelForm экземпляр и булево значение, определяющее, добавляется или изменяется ли родительский объект.

Например, чтобы прикрепить request.user к каждому изменённому экземпляру модели formset:

class ArticleAdmin(admin.ModelAdmin):
    def save_formset(self, request, form, formset, change):
        instances = formset.save(commit=False)
        for obj in formset.deleted_objects:
            obj.delete()
        for instance in instances:
            instance.user = request.user
            instance.save()
        formset.save_m2m()

См. также Сохранение объектов в formset.

ModelAdmin.get_ordering(request)

Метод get_ordering принимает request в качестве параметра и ожидается, что вернёт list или tuple для сортировки, аналогично атрибуту ordering. Например:

class PersonAdmin(admin.ModelAdmin):

    def get_ordering(self, request):
        if request.user.is_superuser:
            return ['name', 'rank']
        else:
            return ['name']

ModelAdmin.get_search_results(request, queryset, search_term) [source]

Метод get_search_results изменяет список отображаемых объектов на те, которые соответствуют предоставленному поисковому запросу. Он принимает запрос, набор запросов, применяющий текущие фильтры, и введенный пользователем поисковый запрос. Возвращает кортеж, содержащий набор запросов, изменённый для реализации поиска, и булево значение, указывающее, могут ли результаты содержать дубликаты.

По умолчанию выполняется поиск по полям, указанным в ModelAdmin.search_fields.

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

Например, для поиска по name и age, можно использовать:

class PersonAdmin(admin.ModelAdmin):
    list_display = ('name', 'age')
    search_fields = ('name',)

    def get_search_results(self, request, queryset, search_term):
        queryset, use_distinct = super().get_search_results(request, queryset, search_term)
        try:
            search_term_as_int = int(search_term)
        except ValueError:
            pass
        else:
            queryset |= self.model.objects.filter(age=search_term_as_int)
        return queryset, use_distinct

Эта реализация более эффективна, чем search_fields = ('name', '=age'), что приводит к сравнению строк для числового поля, например ... OR UPPER("polls_choice"."votes"::text) = UPPER('4') в PostgreSQL.

ModelAdmin.save_related(request, form, formsets, change) [source]

Метод save_related получает HttpRequest, родительский ModelForm экземпляр, список inline formset и булево значение, основанное на том, добавляется или изменяется ли родитель. Здесь вы можете выполнить любые операции до или после сохранения для объектов, связанных с родителем. Обратите внимание, что на этом этапе родительский объект и его форма уже сохранены.

ModelAdmin.get_autocomplete_fields(request)

Метод get_autocomplete_fields() получает HttpRequest и ожидается, что вернёт list или tuple имён полей, которые будут отображаться с виджетом автодополнения, как описано выше в разделе ModelAdmin.autocomplete_fields.

ModelAdmin.get_readonly_fields(request, obj=None)

Метод get_readonly_fields получает HttpRequest и obj редактируемый объект (или None в форме добавления) и ожидается, что вернёт list или tuple имён полей, которые будут отображаться как только для чтения, как описано выше в разделе ModelAdmin.readonly_fields.

ModelAdmin.get_prepopulated_fields(request, obj=None)

Метод get_prepopulated_fields получает HttpRequest и obj редактируемый объект (или None в форме добавления) и ожидается, что вернёт dictionary, как описано выше в разделе ModelAdmin.prepopulated_fields.

ModelAdmin.get_list_display(request) [source]

Метод get_list_display получает HttpRequest и ожидается, что вернёт list или tuple имён полей, которые будут отображаться на представлении списка, как описано выше в разделе ModelAdmin.list_display.

ModelAdmin.get_list_display_links(request, list_display) [source]

Метод get_list_display_links получает HttpRequest и list или tuple возвращаемые методом ModelAdmin.get_list_display(). Ожидается, что он вернёт либо None, либо list или tuple имён полей на представлении списка, которые будут связаны с представлением изменения, как описано в разделе ModelAdmin.list_display_links.

ModelAdmin.get_exclude(request, obj=None)

Метод get_exclude получает HttpRequest и obj редактируемый объект (или None в форме добавления) и ожидается, что вернёт список полей, как описано в ModelAdmin.exclude.

ModelAdmin.get_fields(request, obj=None)

Метод get_fields получает HttpRequest и obj редактируемый объект (или None в форме добавления) и ожидается, что вернёт список полей, как описано выше в разделе ModelAdmin.fields.

ModelAdmin.get_fieldsets(request, obj=None)

Метод get_fieldsets получает HttpRequest и obj редактируемый объект (или None в форме добавления) и ожидается, что вернёт список пар кортежей, где каждая пара кортежей представляет собой <fieldset> на странице формы администрирования, как описано выше в разделе ModelAdmin.fieldsets.

ModelAdmin.get_list_filter(request) [source]

Метод get_list_filter получает HttpRequest и ожидается, что вернёт тот же тип последовательности, что и для атрибута list_filter.

ModelAdmin.get_list_select_related(request) [source]

Метод get_list_select_related получает HttpRequest и должен вернуть булево значение или список, как и ModelAdmin.list_select_related.

ModelAdmin.get_search_fields(request) [source]

Метод get_search_fields получает HttpRequest и должен вернуть последовательность того же типа, что и для атрибута search_fields.

ModelAdmin.get_sortable_by(request)

Новое в Django 2.1.

Метод get_sortable_by() получает HttpRequest и должен вернуть набор (например, list, tuple, или set) имён полей, которые будут сортируемыми на странице списка изменений.

Его реализация по умолчанию возвращает sortable_by, если оно задано, в противном случае делегирует к get_list_display().

Например, чтобы предотвратить сортировку одного или нескольких столбцов:

class PersonAdmin(admin.ModelAdmin):

    def get_sortable_by(self, request):
        return {*self.get_list_display(request)} - {'rank'}

ModelAdmin.get_inline_instances(request, obj=None) [source]

Метод get_inline_instances получает HttpRequest и obj редактируемый объект (или None на форме добавления) и должен вернуть список или кортеж объектов InlineModelAdmin, как описано ниже в разделе InlineModelAdmin. Например, следующее вернёт строки без фильтрации по умолчанию в зависимости от разрешений на добавление, изменение, удаление и просмотр:

class MyModelAdmin(admin.ModelAdmin):
    inlines = (MyInline,)

    def get_inline_instances(self, request, obj=None):
        return [inline(self.model, self.admin_site) for inline in self.inlines]

Если вы переопределяете этот метод, убедитесь, что возвращаемые строки являются экземплярами классов, определённых в inlines, иначе при добавлении связанных объектов может возникнуть ошибка «Ошибка запроса».

ModelAdmin.get_urls() [source]

Метод get_urls на ModelAdmin возвращает URL-адреса, которые будут использоваться для данного ModelAdmin, так же, как и URLconf. Поэтому вы можете расширить их, как описано в Диспечере URL:

from django.contrib import admin
from django.template.response import TemplateResponse
from django.urls import path

class MyModelAdmin(admin.ModelAdmin):
    def get_urls(self):
        urls = super().get_urls()
        my_urls = [
            path('my_view/', self.my_view),
        ]
        return my_urls + urls

    def my_view(self, request):
        # ...
        context = dict(
           # Include common variables for rendering the admin template.
           self.admin_site.each_context(request),
           # Anything else you want in the context...
           key=value,
        )
        return TemplateResponse(request, "sometemplate.html", context)

Если вы хотите использовать макет админки, расширьте от admin/base_site.html:

{% extends "admin/base_site.html" %}
{% block content %}
...
{% endblock %}

Примечание

Обратите внимание, что пользовательские шаблоны включаются перед стандартными URL-адресами админки: шаблоны URL админки очень универсальны и будут соответствовать практически всему, поэтому обычно вы захотите поместить свои пользовательские URL-адреса перед встроенными.

В этом примере, my_view будет доступен по адресу /admin/myapp/mymodel/my_view/ (предполагая, что URL-адреса админки включены в /admin/.)

Однако, функция self.my_view зарегистрированная выше, имеет две проблемы:

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

Поскольку это обычно не то, что вам нужно, Django предоставляет удобную обёртку для проверки разрешений и маркировки представления как некэшируемого. Эта обёртка — AdminSite.admin_view() (т. е. self.admin_site.admin_view внутри экземпляра ModelAdmin); используйте её так:

class MyModelAdmin(admin.ModelAdmin):
    def get_urls(self):
        urls = super().get_urls()
        my_urls = [
            path('my_view/', self.admin_site.admin_view(self.my_view))
        ]
        return my_urls + urls

Обратите внимание на обернутое представление в пятой строке выше:

path('my_view/', self.admin_site.admin_view(self.my_view))

Это обертывание защитит self.my_view от несанкционированного доступа и применит декоратор django.views.decorators.cache.never_cache(), чтобы убедиться, что он не кэшируется, если активен кэш-мидлварь.

Если страница кэшируется, но вы всё ещё хотите, чтобы проверка разрешений выполнялась, вы можете передать cacheable=True аргумент в AdminSite.admin_view():

path('my_view/', self.admin_site.admin_view(self.my_view, cacheable=True))

ModelAdmin представления имеют атрибут model_admin. Другие AdminSite представления имеют атрибут admin_site.

ModelAdmin.get_form(request, obj=None, **kwargs) [source]

Возвращает класс ModelForm для использования в админских представлениях добавления и изменения, см. add_view() и change_view().

Базовая реализация использует modelform_factory() для создания подкласса form, модифицированного атрибутами, такими как fields и exclude. Например, если вы хотели предложить дополнительные поля для суперпользователей, вы могли бы заменить базовый вид формы следующим образом:

class MyModelAdmin(admin.ModelAdmin):
    def get_form(self, request, obj=None, **kwargs):
        if request.user.is_superuser:
            kwargs['form'] = MySuperuserForm
        return super().get_form(request, obj, **kwargs)

Вы также можете просто вернуть пользовательский класс ModelForm напрямую.

ModelAdmin.get_formsets_with_inlines(request, obj=None) [source]

Возвращает пары (FormSet, InlineModelAdmin) для использования в админских представлениях добавления и изменения.

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

class MyModelAdmin(admin.ModelAdmin):
    inlines = [MyInline, SomeOtherInline]

    def get_formsets_with_inlines(self, request, obj=None):
        for inline in self.get_inline_instances(request, obj):
            # hide MyInline in the add view
            if not isinstance(inline, MyInline) or obj is not None:
                yield inline.get_formset(request, obj), inline

ModelAdmin.formfield_for_foreignkey(db_field, request, **kwargs)

Метод formfield_for_foreignkey на ModelAdmin позволяет вам переопределить поле формы по умолчанию для внешнего ключа. Например, чтобы вернуть подмножество объектов для этого поля внешнего ключа, основываясь на пользователе:

class MyModelAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "car":
            kwargs["queryset"] = Car.objects.filter(owner=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

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

ModelAdmin.formfield_for_manytomany(db_field, request, **kwargs)

Подобно методу formfield_for_foreignkey, метод formfield_for_manytomany можно переопределить, чтобы изменить поле формы по умолчанию для поля «многие ко многим». Например, если владелец может владеть множеством автомобилей, и автомобили могут принадлежать многим владельцам – отношения «многие ко многим» – вы можете отфильтровать поле внешнего ключа Car для отображения только автомобилей, принадлежащих User:

class MyModelAdmin(admin.ModelAdmin):
    def formfield_for_manytomany(self, db_field, request, **kwargs):
        if db_field.name == "cars":
            kwargs["queryset"] = Car.objects.filter(owner=request.user)
        return super().formfield_for_manytomany(db_field, request, **kwargs)

ModelAdmin.formfield_for_choice_field(db_field, request, **kwargs)

Подобно методам formfield_for_foreignkey и formfield_for_manytomany, метод formfield_for_choice_field можно переопределить, чтобы изменить поле формы по умолчанию для поля с объявленными вариантами. Например, если доступные варианты для суперпользователя должны отличаться от вариантов для обычного персонала, можно поступить следующим образом:

class MyModelAdmin(admin.ModelAdmin):
    def formfield_for_choice_field(self, db_field, request, **kwargs):
        if db_field.name == "status":
            kwargs['choices'] = (
                ('accepted', 'Accepted'),
                ('denied', 'Denied'),
            )
            if request.user.is_superuser:
                kwargs['choices'] += (('ready', 'Ready for deployment'),)
        return super().formfield_for_choice_field(db_field, request, **kwargs)

Примечание

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

ModelAdmin.get_changelist(request, **kwargs) [source]

Возвращает класс Changelist для использования в списке. По умолчанию используется django.contrib.admin.views.main.ChangeList. Наследуя этот класс, вы можете изменить поведение отображения.

ModelAdmin.get_changelist_form(request, **kwargs) [source]

Возвращает класс ModelForm для использования на странице списка изменений. Для использования пользовательской формы, например:

from django import forms

class MyForm(forms.ModelForm):
    pass

class MyModelAdmin(admin.ModelAdmin):
    def get_changelist_form(self, request, **kwargs):
        return MyForm

Примечание

Если вы определяете атрибут Meta.model в классе ModelForm, вы также должны определить атрибут Meta.fields (или атрибут Meta.exclude). Однако, ModelAdmin игнорирует это значение, переопределяя его атрибутом ModelAdmin.list_editable. Самый простой способ — опустить атрибут Meta.model, так как ModelAdmin предоставит правильную модель для использования.

ModelAdmin.get_changelist_formset(request, **kwargs) [source]

Возвращает класс ModelFormSet для использования на странице списка изменений, если используется list_editable. Для использования пользовательского набора форм, например:

from django.forms import BaseModelFormSet

class MyAdminFormSet(BaseModelFormSet):
    pass

class MyModelAdmin(admin.ModelAdmin):
    def get_changelist_formset(self, request, **kwargs):
        kwargs['formset'] = MyAdminFormSet
        return super().get_changelist_formset(request, **kwargs)

ModelAdmin.lookup_allowed(lookup, value)

Объекты на странице списка изменений можно отфильтровать с помощью запросов из строки запроса URL. Так, например, работает list_filter. Эти запросы аналогичны тем, что используются в QuerySet.filter() (например, user__email=user@example.com). Поскольку запросы в строке запроса могут быть изменены пользователем, их необходимо очистить, чтобы предотвратить несанкционированный доступ к данным.

Метод lookup_allowed() получает путь запроса из строки запроса (например, 'user__email') и соответствующее значение (например, 'user@example.com') и возвращает булево значение, указывающее, разрешено ли фильтровать список изменений QuerySet с помощью указанных параметров. Если lookup_allowed() возвращает False, генерируется исключение DisallowedModelAdminLookup (подкласс SuspiciousOperation).

По умолчанию lookup_allowed() разрешает доступ к локальным полям модели, путям полей, используемым в list_filter (но не путям из get_list_filter()), и запросы, необходимые для limit_choices_to для правильной работы в raw_id_fields.

Переопределите этот метод, чтобы настроить разрешенные запросы для вашего подкласса ModelAdmin.

ModelAdmin.has_view_permission(request, obj=None)

Новое в Django 2.1.

Должен вернуть True если просмотр obj разрешен, False в противном случае. Если obj равен None, должен вернуть True или False, чтобы указать, разрешен ли просмотр объектов данного типа в целом (например, False будет интерпретироваться как то, что текущий пользователь не имеет права просматривать какой-либо объект данного типа).

По умолчанию возвращает True, если пользователь имеет право «изменять» или «просматривать».

ModelAdmin.has_add_permission(request)

Должен вернуть True если добавление объекта разрешено, False в противном случае.

ModelAdmin.has_change_permission(request, obj=None)

Должен вернуть True если редактирование obj разрешено, False в противном случае. Если obj равно None, должен вернуть True или False, чтобы указать, разрешено ли редактирование объектов данного типа в целом (например, False будет интерпретироваться как то, что текущий пользователь не имеет права редактировать какой-либо объект данного типа).

ModelAdmin.has_delete_permission(request, obj=None)

Должен вернуть True если удаление obj разрешено, False в противном случае. Если obj равно None, должен вернуть True или False, чтобы указать, разрешено ли удаление объектов данного типа в целом (например, False будет интерпретироваться как то, что текущий пользователь не имеет права удалить какой-либо объект данного типа).

ModelAdmin.has_module_permission(request)

Должен вернуть True если отображение модуля на странице индекса админки и доступ к странице индекса модуля разрешены, False в противном случае. По умолчанию использует User.has_module_perms(). Переопределение не ограничивает доступ к просмотру, добавлению, изменению или удалению представлений, has_view_permission(), has_add_permission(), has_change_permission() и has_delete_permission() для этого.

ModelAdmin.get_queryset(request)

Метод get_queryset в ModelAdmin возвращает QuerySet всех экземпляров модели, которые могут быть отредактированы в админском интерфейсе. Одним из применений переопределения этого метода является показ объектов, принадлежащих вошедшему в систему пользователю:

class MyModelAdmin(admin.ModelAdmin):
    def get_queryset(self, request):
        qs = super().get_queryset(request)
        if request.user.is_superuser:
            return qs
        return qs.filter(author=request.user)

ModelAdmin.message_user(request, message, level=messages.INFO, extra_tags='', fail_silently=False) [source]

Отправляет сообщение пользователю с помощью бэкенда django.contrib.messages. См. пример кастомного ModelAdmin.

Использование ключевых аргументов позволяет изменить уровень сообщения, добавить дополнительные теги CSS или безмолвно провалиться, если фреймворк contrib.messages не установлен. Эти ключевые аргументы соответствуют аргументам функции django.contrib.messages.add_message(), см. документацию этой функции для получения дополнительной информации. Отличие заключается в том, что уровень может быть передан как метка строки, а не как целое число/константа.

ModelAdmin.get_paginator(request, queryset, per_page, orphans=0, allow_empty_first_page=True) [source]

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

ModelAdmin.response_add(request, obj, post_url_continue=None) [source]

Определяет HttpResponse для стадии add_view().

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

ModelAdmin.response_change(request, obj) [source]

Определяет HttpResponse для стадии change_view().

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

ModelAdmin.response_delete(request, obj_display, obj_id) [source]

Определяет HttpResponse для стадии delete_view().

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

obj_display — это строка с именем удалённого объекта.

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

ModelAdmin.get_changeform_initial_data(request) [source]

Метод для инициализации данных при редактировании объектов в админке. По умолчанию поля получают начальные значения из параметров GET. Например, ?name=initial_value установит начальное значение поля name в initial_value.

Метод должен возвращать словарь в формате {'fieldname': 'fieldval'}:

def get_changeform_initial_data(self, request):
    return {'name': 'custom_initial_value'}

ModelAdmin.get_deleted_objects(objs, request) [source]

Добавлено в Django 2.1.

Метод для настройки процесса удаления объектов в delete_view() и при удалении выбранных действий.

Аргумент objs — это однородный итерируемый объект (кортеж или список экземпляров модели) объектов, подлежащих удалению, а request — HttpRequest.

Метод должен возвращать 4-кортеж (deleted_objects, model_count, perms_needed, protected).

deleted_objects — список строк, представляющих все объекты, которые будут удалены. Если есть какие-либо связанные объекты, подлежащие удалению, список вложен и включает эти связанные объекты. Список отформатирован в шаблоне с использованием фильтра unordered_list.

model_count — словарь, сопоставляющий verbose_name_plural каждой модели с количеством объектов, которые будут удалены.

perms_needed — множество verbose_name моделей, которые у пользователя нет разрешения удалять.

protected — список строк, представляющих все защищённые связанные объекты, которые не могут быть удалены. Список отображается в шаблоне.

Другие методы

ModelAdmin.add_view(request, form_url='', extra_context=None) [source]

Django-представление страницы добавления экземпляра модели. См. примечание ниже.

ModelAdmin.change_view(request, object_id, form_url='', extra_context=None) [source]

Django-представление страницы редактирования экземпляра модели. См. примечание ниже.

ModelAdmin.changelist_view(request, extra_context=None) [source]

Django-представление страницы списка/действий экземпляров модели. См. примечание ниже.

ModelAdmin.delete_view(request, object_id, extra_context=None) [source]

Django-представление страницы подтверждения удаления экземпляра(ов) модели. См. примечание ниже.

ModelAdmin.history_view(request, object_id, extra_context=None) [source]

Django-представление страницы истории изменений для данного экземпляра модели.

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

Одна из распространённых причин переопределения этих методов — расширение данных контекста, предоставляемых шаблону, который отображает представление. В следующем примере представление change view переопределяется таким образом, чтобы предоставленный шаблону контекст содержал дополнительную информацию, которая в противном случае была бы недоступна:

class MyModelAdmin(admin.ModelAdmin):

    # A template for a very customized change view:
    change_form_template = 'admin/myapp/extras/openstreetmap_change_form.html'

    def get_osm_info(self):
        # ...
        pass

    def change_view(self, request, object_id, form_url='', extra_context=None):
        extra_context = extra_context or {}
        extra_context['osm_data'] = self.get_osm_info()
        return super().change_view(
            request, object_id, form_url, extra_context=extra_context,
        )

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

ModelAdmin определения активов

Иногда необходимо добавить CSS и/или JavaScript в представления add/change. Это можно сделать, используя внутренний класс Media в вашем ModelAdmin:

class ArticleAdmin(admin.ModelAdmin):
    class Media:
        css = {
            "all": ("my_styles.css",)
        }
        js = ("my_code.js",)

Приложение staticfiles добавляет STATIC_URL (или MEDIA_URL, если STATIC_URL — None) в начало всех путей к активам. Применяются те же правила, что и для обычных определений активов в формах.

jQuery

Django admin JavaScript использует библиотеку jQuery.

Чтобы избежать конфликтов с пользовательскими скриптами или библиотеками, Django's jQuery (версия 3.3.1) имеет пространство имён django.jQuery. Если вы хотите использовать jQuery в собственном admin JavaScript без включения второй копии, вы можете использовать объект django.jQuery в представлениях changelist и add/edit.

Класс ModelAdmin по умолчанию требует jQuery, поэтому нет необходимости добавлять jQuery в список ресурсов media вашего ModelAdmin, если нет необходимости. Например, если вам нужен jQuery в глобальном пространстве имен (например, при использовании сторонних плагинов jQuery) или если вам нужна более новая версия jQuery, вам нужно будет добавить собственную копию.

Django предоставляет как нескомпрессированные, так и «минифицированные» версии jQuery как jquery.js и jquery.min.js соответственно.

ModelAdmin и InlineModelAdmin имеют свойство media, возвращающее список объектов Media, которые хранят пути к JavaScript-файлам для форм и/или формсетов. Если DEBUG равно True, оно вернёт нескомпрессированные версии различных JavaScript-файлов, включая jquery.js; в противном случае — «минифицированные» версии.

Добавление пользовательской валидации в админку

Добавление пользовательской валидации данных в админку очень просто. Автоматический интерфейс админки использует django.forms, а класс ModelAdmin даёт возможность определить собственную форму:

class ArticleAdmin(admin.ModelAdmin):
    form = MyArticleAdminForm

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

class MyArticleAdminForm(forms.ModelForm):
    def clean_name(self):
        # do something that validates your data
        return self.cleaned_data["name"]

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

InlineModelAdmin объекты

class InlineModelAdmin

class TabularInline [source]

class StackedInline [source]

Интерфейс администратора имеет возможность редактировать модели на той же странице, что и родительская модель. Это называются вложенными элементами. Предположим, у вас есть эти две модели:

from django.db import models

class Author(models.Model):
   name = models.CharField(max_length=100)

class Book(models.Model):
   author = models.ForeignKey(Author, on_delete=models.CASCADE)
   title = models.CharField(max_length=100)

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

from django.contrib import admin

class BookInline(admin.TabularInline):
    model = Book

class AuthorAdmin(admin.ModelAdmin):
    inlines = [
        BookInline,
    ]

Django предоставляет два подкласса InlineModelAdmin и они таковы:

• TabularInline
• StackedInline

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

InlineModelAdmin параметры

InlineModelAdmin разделяет многие из тех же функций, что и ModelAdmin, и добавляет некоторые свои собственные (общие функции фактически определены в суперклассе BaseModelAdmin). Общие функции:

• form
• fieldsets
• fields
• formfield_overrides
• exclude
• filter_horizontal
• filter_vertical
• ordering
• prepopulated_fields
• get_fieldsets()
• get_queryset()
• radio_fields
• readonly_fields
• raw_id_fields
• formfield_for_choice_field()
• formfield_for_foreignkey()
• formfield_for_manytomany()
• has_module_permission()

Класс InlineModelAdmin добавляет или настраивает:

InlineModelAdmin.model

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

InlineModelAdmin.fk_name

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

InlineModelAdmin.formset

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

InlineModelAdmin.form

Значение для form по умолчанию ModelForm. Это то, что передаётся в inlineformset_factory() при создании набора форм для этого вложенного элемента.

InlineModelAdmin.classes

Список или кортеж, содержащий дополнительные CSS-классы, которые необходимо применить к набору элементов, отображаемых для вложенных элементов. По умолчанию None. Как и с классами, настроенными в fieldsets, вложенные элементы с классом collapse будут изначально скрыты, а их заголовок будет содержать небольшую ссылку «показать».

InlineModelAdmin.extra

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

Для пользователей с браузерами, поддерживающими JavaScript, предоставляется ссылка «Добавить ещё», которая позволяет добавлять любое количество дополнительных вложенных элементов в дополнение к тем, которые были предоставлены в результате аргумента extra.

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

InlineModelAdmin.get_extra() также позволяет настроить количество дополнительных форм.

InlineModelAdmin.max_num

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

InlineModelAdmin.get_max_num() также позволяет настроить максимальное количество дополнительных форм.

InlineModelAdmin.min_num

Это контролирует минимальное количество форм, которые будут отображаться во вложенном элементе. Дополнительную информацию см. в modelformset_factory().

InlineModelAdmin.get_min_num() также позволяет настроить минимальное количество отображаемых форм.

InlineModelAdmin.raw_id_fields

По умолчанию Django админ использует интерфейс выпадающего списка (<select>) для полей, которые являются ForeignKey. Иногда вы не хотите нести издержки, связанные с выбором всех связанных экземпляров для отображения во всплывающем списке.

raw_id_fields — это список полей, которые вы хотите изменить на виджет Input для ForeignKey или ManyToManyField:

class BookInline(admin.TabularInline):
    model = Book
    raw_id_fields = ("pages",)

InlineModelAdmin.template

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

InlineModelAdmin.verbose_name

Переопределение свойства verbose_name, найденного в внутреннем классе модели Meta.

InlineModelAdmin.verbose_name_plural

Переопределение свойства verbose_name_plural, найденного в внутреннем классе модели Meta.

InlineModelAdmin.can_delete

Указывает, можно ли удалять объекты вложенных моделей. По умолчанию установлено значение True.

InlineModelAdmin.show_change_link

Указывает, отображать ли ссылку на форму изменения для вложенных объектов, которые могут быть изменены в админке. По умолчанию установлено значение False.

InlineModelAdmin.get_formset(request, obj=None, **kwargs)

Возвращает класс BaseInlineFormSet для использования в админских представлениях добавления/изменения. obj — редактируемый родительский объект или None при добавлении нового родительского объекта. Смотрите пример для ModelAdmin.get_formsets_with_inlines.

InlineModelAdmin.get_extra(request, obj=None, **kwargs)

Возвращает количество дополнительных форм вложенных моделей. По умолчанию возвращает атрибут InlineModelAdmin.extra.

Переопределите этот метод для программированного определения количества дополнительных форм вложенных моделей. Например, это может быть основано на экземпляре модели (переданном в качестве ключевого аргумента obj) :

class BinaryTreeAdmin(admin.TabularInline):
    model = BinaryTree

    def get_extra(self, request, obj=None, **kwargs):
        extra = 2
        if obj:
            return extra - obj.binarytree_set.count()
        return extra

InlineModelAdmin.get_max_num(request, obj=None, **kwargs)

Возвращает максимальное количество дополнительных форм вложенных моделей. По умолчанию возвращает атрибут InlineModelAdmin.max_num.

Переопределите этот метод для программированного определения максимального количества вложенных форм. Например, это может быть основано на экземпляре модели (переданном в качестве ключевого аргумента obj) :

class BinaryTreeAdmin(admin.TabularInline):
    model = BinaryTree

    def get_max_num(self, request, obj=None, **kwargs):
        max_num = 10
        if obj and obj.parent:
            return max_num - 5
        return max_num

InlineModelAdmin.get_min_num(request, obj=None, **kwargs)

Возвращает минимальное количество форм вложенных моделей. По умолчанию возвращает атрибут InlineModelAdmin.min_num.

Переопределите этот метод для программированного определения минимального количества вложенных форм. Например, это может быть основано на экземпляре модели (переданном в качестве ключевого аргумента obj) .

InlineModelAdmin.has_add_permission(request, obj)

Должен вернуть True, если добавление вложенного объекта разрешено, False, в противном случае. obj — редактируемый родительский объект или None при добавлении нового родительского объекта.

Изменено в Django 2.1:

Добавлен аргумент obj. В период устаревания он также может быть None, если сторонние вызовы к has_add_permission() не предоставляют его.

InlineModelAdmin.has_change_permission(request, obj=None)

Должен вернуть True, если редактирование вложенного объекта разрешено, False, в противном случае. obj — редактируемый родительский объект.

InlineModelAdmin.has_delete_permission(request, obj=None)

Должен вернуть True, если удаление вложенного объекта разрешено, False, в противном случае. obj — редактируемый родительский объект.

Работа с моделью с двумя или более внешними ключами к одной и той же родительской модели

Иногда возможно иметь более одного внешнего ключа к одной и той же модели. Рассмотрим эту модель:

from django.db import models

class Friendship(models.Model):
    to_person = models.ForeignKey(Person, on_delete=models.CASCADE, related_name="friends")
    from_person = models.ForeignKey(Person, on_delete=models.CASCADE, related_name="from_friends")

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

from django.contrib import admin
from myapp.models import Friendship

class FriendshipInline(admin.TabularInline):
    model = Friendship
    fk_name = "to_person"

class PersonAdmin(admin.ModelAdmin):
    inlines = [
        FriendshipInline,
    ]

Работа с моделями "многие ко многим"

По умолчанию виджеты администрирования для отношений "многие ко многим" будут отображаться в той модели, которая содержит фактическую ссылку на ManyToManyField. В зависимости от вашего определения ModelAdmin, каждое поле "многие ко многим" в вашей модели будет представлено стандартным HTML <select multiple>, горизонтальным или вертикальным фильтром, или виджетом raw_id_admin. Однако, также возможно заменить эти виджеты вложенными моделями.

Предположим, у нас есть следующие модели:

from django.db import models

class Person(models.Model):
    name = models.CharField(max_length=128)

class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person, related_name='groups')

Если вы хотите отобразить отношения "многие ко многим" с помощью вложенной модели, вы можете сделать это, определив объект InlineModelAdmin для отношения:

from django.contrib import admin

class MembershipInline(admin.TabularInline):
    model = Group.members.through

class PersonAdmin(admin.ModelAdmin):
    inlines = [
        MembershipInline,
    ]

class GroupAdmin(admin.ModelAdmin):
    inlines = [
        MembershipInline,
    ]
    exclude = ('members',)

В этом примере стоит отметить две особенности.

Во-первых, класс MembershipInline ссылается на Group.members.through. Атрибут through — ссылка на модель, которая управляет отношением "многие ко многим". Эта модель автоматически создается Django при определении поля "многие ко многим".

Во-вторых, класс GroupAdmin должен вручную исключить поле members. Django отображает виджет администрирования для поля "многие ко многим" в модели, которая определяет отношение (в данном случае, Group). Если вы хотите использовать вложенную модель для представления отношения "многие ко многим", вы должны указать Django, что этот виджет не должен отображаться — в противном случае у вас на странице администрирования будут два виджета для управления отношением.

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

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

Работа с моделями-посредниками "многие ко многим"

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

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

from django.db import models

class Person(models.Model):
    name = models.CharField(max_length=128)

class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person, through='Membership')

class Membership(models.Model):
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    group = models.ForeignKey(Group, on_delete=models.CASCADE)
    date_joined = models.DateField()
    invite_reason = models.CharField(max_length=64)

Первым шагом в отображении этой модели-посредника в админке является определение класса вложенной модели для модели Membership:

class MembershipInline(admin.TabularInline):
    model = Membership
    extra = 1

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

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

class PersonAdmin(admin.ModelAdmin):
    inlines = (MembershipInline,)

class GroupAdmin(admin.ModelAdmin):
    inlines = (MembershipInline,)

Наконец, зарегистрируйте ваши модели Person и Group в сайте администрирования:

admin.site.register(Person, PersonAdmin)
admin.site.register(Group, GroupAdmin)

Теперь ваш сайт администрирования настроен для редактирования объектов Membership встроеных моделях, как с страниц добавления/изменения Person, так и со страниц подробностей Group.

Использование обобщённых отношений как вложенной модели

Можно использовать вложенную модель с обобщёнными связанными объектами. Предположим, у вас есть следующие модели:

from django.contrib.contenttypes.fields import GenericForeignKey
from django.db import models

class Image(models.Model):
    image = models.ImageField(upload_to="images")
    content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
    object_id = models.PositiveIntegerField()
    content_object = GenericForeignKey("content_type", "object_id")

class Product(models.Model):
    name = models.CharField(max_length=100)

Если вы хотите разрешить редактирование и создание экземпляра Image на страницах добавления/изменения Product, используйте GenericTabularInline или GenericStackedInline (оба являются подклассами GenericInlineModelAdmin), предоставляемыми модулем admin. Они реализуют табличную и стопочную визуальные макеты для форм, представляющих вложенные объекты, соответственно, так же, как и их необобщённые аналоги. Они ведут себя как любая другая вложенная модель. В вашей admin.py для приложения в этом примере:

from django.contrib import admin
from django.contrib.contenttypes.admin import GenericTabularInline

from myproject.myapp.models import Image, Product

class ImageInline(GenericTabularInline):
    model = Image

class ProductAdmin(admin.ModelAdmin):
    inlines = [
        ImageInline,
    ]

admin.site.register(Product, ProductAdmin)

См. документацию по contenttypes для более подробной информации.

Переопределение шаблонов администрирования

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

Настройка директорий шаблонов админки проекта

Файлы шаблонов админки расположены в каталоге contrib/admin/templates/admin.

Для того, чтобы переопределить один или несколько из них, сначала создайте каталог admin в каталоге вашего проекта templates. Это может быть любой из каталогов, указанных в опции DIRS бэкэнда DjangoTemplates в настройке TEMPLATES. Если вы настраивали опцию 'loaders', убедитесь, что 'django.template.loaders.filesystem.Loader' указан до 'django.template.loaders.app_directories.Loader', чтобы система загрузки шаблонов находила ваши пользовательские шаблоны до тех, что включены с django.contrib.admin.

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

Для переопределения шаблона админки для конкретного приложения скопируйте и отредактируйте шаблон из каталога django/contrib/admin/templates/admin и сохраните его в одном из только что созданных каталогов.

Например, если мы хотим добавить инструмент в представление списка изменений для всех моделей в приложении под названием my_app, мы скопируем contrib/admin/templates/admin/change_list.html в каталог templates/admin/my_app/ нашего проекта и внесем необходимые изменения.

Если мы хотим добавить инструмент в представление списка изменений только для конкретной модели под названием «Page», мы скопируем тот же файл в каталог templates/admin/my_app/page нашего проекта.

Переопределение против замены шаблона админки

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

Продолжая пример выше, мы хотим добавить новую ссылку рядом с инструментом History для модели Page. После ознакомления с change_form.html мы определяем, что нам нужно только переопределить блок object-tools-items. Поэтому наш новый шаблон выглядит следующим образом:

{% extends "admin/change_form.html" %}
{% load i18n admin_urls %}
{% block object-tools-items %}
    <li>
        <a href="{% url opts|admin_urlname:'history' original.pk|admin_urlquote %}" class="historylink">{% trans "History" %}</a>
    </li>
    <li>
        <a href="mylink/" class="historylink">My Link</a>
    </li>
    {% if has_absolute_url %}
        <li>
            <a href="{% url 'admin:view_on_site' content_type_id original.pk %}" class="viewsitelink">{% trans "View on site" %}</a>
        </li>
    {% endif %}
{% endblock %}

И это все! Если мы поместили этот файл в каталог templates/admin/my_app, наша ссылка появится в форме изменения для всех моделей внутри my_app.

Шаблоны, которые можно переопределить по приложению или модели

Не каждый шаблон в contrib/admin/templates/admin можно переопределить по приложению или модели. Следующие можно:

• actions.html
• app_index.html
• change_form.html
• change_form_object_tools.html
• change_list.html
• change_list_object_tools.html
• change_list_results.html
• date_hierarchy.html
• delete_confirmation.html
• object_history.html
• pagination.html
• popup_response.html
• prepopulated_fields_js.html
• search_form.html
• submit_line.html

Для тех шаблонов, которые нельзя переопределить таким образом, вы все равно можете переопределить их для всего вашего проекта. Просто поместите новую версию в каталог templates/admin. Это особенно полезно для создания пользовательских страниц 404 и 500.

Шаблоны корня и входа

Если вы хотите изменить шаблоны индекса, входа или выхода, вам лучше создать свою собственную инстанцию AdminSite (см. ниже) и изменить свойства AdminSite.index_template, AdminSite.login_template или AdminSite.logout_template.

Объекты AdminSite

class AdminSite(name='admin') [source]

Сайт Django админки представлен экземпляром django.contrib.admin.sites.AdminSite; по умолчанию создается экземпляр этого класса как django.contrib.admin.site, и вы можете зарегистрировать ваши модели и экземпляры ModelAdmin с ним.

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

При создании экземпляра AdminSite, вы можете указать уникальное имя экземпляра, используя аргумент name в конструкторе. Это имя экземпляра используется для идентификации экземпляра, особенно при обращении к URL-адресам админки. Если имя экземпляра не указано, используется имя по умолчанию admin. См. Настройка класса AdminSite для примера настройки класса AdminSite.

Атрибуты AdminSite

Шаблоны могут переопределять или расширять базовые шаблоны админки, как описано в Переопределении шаблонов админки.

AdminSite.site_header

Текст, отображаемый в верхней части каждой страницы админки, как <h1> (строка). По умолчанию это «Django administration».

AdminSite.site_title

Текст, отображаемый в нижней части каждой страницы админки, как <title> (строка). По умолчанию это «Django site admin».

AdminSite.site_url

URL для ссылки «Просмотр сайта» в верхней части каждой страницы админки. По умолчанию site_url равен /. Установите его в None для удаления ссылки.

Для сайтов, работающих на подпути, метод each_context() проверяет, установлен ли для текущего запроса параметр request.META['SCRIPT_NAME'], и использует это значение, если site_url не установлено на значение, отличное от /.

AdminSite.index_title

Текст, отображаемый в верхней части главной страницы админки (строка). По умолчанию это «Site administration».

AdminSite.index_template

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

AdminSite.app_index_template

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

AdminSite.empty_value_display

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

AdminSite.login_template

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

AdminSite.login_form

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

AdminSite.logout_template

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

AdminSite.password_change_template

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

AdminSite.password_change_done_template

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

Методы AdminSite

AdminSite.each_context(request) [source]

Возвращает словарь переменных для контекста шаблона каждой страницы административной панели.

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

• site_header: AdminSite.site_header
• site_title: AdminSite.site_title
• site_url: AdminSite.site_url
• has_permission: AdminSite.has_permission()

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

  • app_label: имя приложения
  • app_url: URL страницы индекса приложения в админке
  • has_module_perms: логическое значение, указывающее, разрешено ли отображение и доступ к странице индекса модуля для текущего пользователя
  • models: список моделей, доступных в приложении

  Каждая модель — словарь со следующими ключами:

  • object_name: имя класса модели
  • name: множественное число имени модели
  • perms: отслеживающие разрешения на dict, add, change, и delete, и view
  • admin_url: URL списка изменений модели в админке
  • add_url: URL добавления новой записи модели в админке

AdminSite.has_permission(request) [source]

Возвращает True, если у пользователя с заданными HttpRequest есть разрешение на просмотр хотя бы одной страницы в административной панели. По умолчанию требует, чтобы оба User.is_active и User.is_staff были True.

AdminSite.register(model_or_iterable, admin_class=None, **options) [source]

Регистрирует заданный класс модели (или итерируемый список классов) с заданным admin_class. По умолчанию используется ModelAdmin (стандартные параметры админки). Если заданы ключевые аргументы — например, list_display — они будут применены в качестве опций к классу админки.

Вызывает исключение ImproperlyConfigured, если модель абстрактная, и django.contrib.admin.sites.AlreadyRegistered если модель уже зарегистрирована.

Подключение экземпляров AdminSite к вашему URLconf

Последний шаг настройки Django admin — подключение экземпляра AdminSite к вашему URLconf. Сделайте это, указав заданный URL на метод AdminSite.urls. Не обязательно использовать include().

В этом примере мы регистрируем экземпляр AdminSite django.contrib.admin.site по адресу /admin/

# urls.py
from django.contrib import admin
from django.urls import path

urlpatterns = [
    path('admin/', admin.site.urls),
]

Настройка класса AdminSite

Если вы хотите создать свой административный сайт с пользовательским поведением, вы можете создать подкласс AdminSite и переопределить или добавить что-либо. Затем просто создайте экземпляр вашего подкласса AdminSite (как и любой другой класс Python) и зарегистрируйте ваши модели и подклассы ModelAdmin с ним вместо стандартного сайта. Наконец, обновите myproject/urls.py для ссылки на ваш подкласс AdminSite.

from django.contrib.admin import AdminSite

from .models import MyModel

class MyAdminSite(AdminSite):
    site_header = 'Monty Python administration'

admin_site = MyAdminSite(name='myadmin')
admin_site.register(MyModel)

from django.urls import path

from myapp.admin import admin_site

urlpatterns = [
    path('myadmin/', admin_site.urls),
]

Обратите внимание, что вы, возможно, не захотите автоматического обнаружения admin модулей при использовании собственного экземпляра AdminSite , так как вы, скорее всего, импортируете все admin модули приложения в свой myproject.admin модуль. Это означает, что вам нужно указать 'django.contrib.admin.apps.SimpleAdminConfig' вместо 'django.contrib.admin' в настройке INSTALLED_APPS.

Переопределение стандартного административного сайта

Вы можете переопределить стандартный django.contrib.admin.site , установив атрибут default_site настраиваемого AppConfig на импортируемый путь либо подкласса AdminSite , либо вызываемого объекта, возвращающего экземпляр сайта.

from django.contrib import admin

class MyAdminSite(admin.AdminSite):
    ...

from django.contrib.admin.apps import AdminConfig

class MyAdminConfig(AdminConfig):
    default_site = 'myproject.admin.MyAdminSite'

INSTALLED_APPS = [
    ...
    'myproject.apps.MyAdminConfig',  # replaces 'django.contrib.admin'
    ...
]

Несколько административных сайтов в одном URLconf

Создать несколько экземпляров административного сайта на одном веб-сайте, использующем Django, легко. Просто создайте несколько экземпляров AdminSite и расположите каждый по разному URL.

В этом примере URL /basic-admin/ и /advanced-admin/ содержат отдельные версии административного сайта — используя экземпляры AdminSite myproject.admin.basic_site и myproject.admin.advanced_site, соответственно:

# urls.py
from django.urls import path
from myproject.admin import advanced_site, basic_site

urlpatterns = [
    path('basic-admin/', basic_site.urls),
    path('advanced-admin/', advanced_site.urls),
]

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

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

Так же, как ModelAdmin, AdminSite предоставляет метод get_urls(), который может быть переопределен для определения дополнительных представлений для сайта. Чтобы добавить новое представление к вашему административному сайту, расширьте метод get_urls() , чтобы он включал шаблон для вашего нового представления.

Добавление функции сброса пароля

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

from django.contrib.auth import views as auth_views

path(
    'admin/password_reset/',
    auth_views.PasswordResetView.as_view(),
    name='admin_password_reset',
),
path(
    'admin/password_reset/done/',
    auth_views.PasswordResetDoneView.as_view(),
    name='password_reset_done',
),
path(
    'reset/<uidb64>/<token>/',
    auth_views.PasswordResetConfirmView.as_view(),
    name='password_reset_confirm',
),
path(
    'reset/done/',
    auth_views.PasswordResetCompleteView.as_view(),
    name='password_reset_complete',
),

(Это предполагает, что вы добавили админку по адресу admin/ и требует, чтобы URL, начинающиеся с ^admin/ , располагались перед строкой, включающей сам админский модуль).

Наличие admin_password_reset именованного URL приведет к появлению ссылки «Забыли пароль?» на стандартной странице входа в админку под полем пароля.

LogEntry объекты

class models.LogEntry

Класс LogEntry отслеживает добавления, изменения и удаления объектов, выполненные через интерфейс админки.

LogEntry атрибуты

LogEntry.action_time

Дата и время действия.

LogEntry.user

Пользователь (объект AUTH_USER_MODEL) который выполнил действие.

LogEntry.content_type

Тип ContentType изменённого объекта.

LogEntry.object_id

Текстовое представление первичного ключа изменённого объекта.

LogEntry.object_repr

Представление объекта repr() после изменения.

LogEntry.action_flag

Тип выполненного действия: ADDITION, CHANGE, DELETION.

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

from django.contrib.admin.models import ADDITION, LogEntry

LogEntry.objects.filter(action_flag=ADDITION)

LogEntry.change_message

Подробное описание изменения. В случае редактирования, например, сообщение содержит список изменённых полей. Админ-панель Django форматирует это содержимое как JSON-структуру, для того чтобы get_change_message() смог составить сообщение, переведённое на язык текущего пользователя. Однако, пользовательский код может установить это как обычную строку. Рекомендуется использовать метод get_change_message() для получения этого значения вместо прямого доступа.

LogEntry методы

LogEntry.get_edited_object()

Сокращение, которое возвращает сохранённый объект.

LogEntry.get_change_message()

Форматирует и переводит change_message на язык текущего пользователя. Сообщения, созданные до Django 1.10, всегда будут отображаться на языке, на котором они были записаны.

Обращение к URL-адресам админки

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

Админ AdminSite предоставляет следующие именованные URL-образцы:

Каждый экземпляр ModelAdmin предоставляет дополнительный набор именованных URL-адресов:

Админка предоставляет именованный URL:

Эти именованные URL зарегистрированы в пространстве имён приложения admin, и в пространстве имён экземпляра, соответствующем имени экземпляра сайта.

Итак, если вам нужно получить ссылку на представление Изменить для конкретного объекта Choice (из приложения polls) в стандартной админке, вы бы вызвали:

>>> from django.urls import reverse
>>> c = Choice.objects.get(...)
>>> change_url = reverse('admin:polls_choice_change', args=(c.id,))

Это найдет первый зарегистрированный экземпляр админ-приложения (каким бы ни было имя экземпляра) и перенаправит к представлению для изменения экземпляров poll.Choice в этом экземпляре.

Если вам нужна ссылка на URL в конкретном экземпляре админки, укажите имя этого экземпляра как подсказку current_app для обратного вызова. Например, если вам нужен админ-просмотр из экземпляра админки с именем custom, вам нужно вызвать:

>>> change_url = reverse('admin:polls_choice_change', args=(c.id,), current_app='custom')

Более подробную информацию см. в документации по перенаправлению именованных URL.

Для упрощения перенаправления URL админки в шаблонах Django предоставляет фильтр admin_urlname, принимающий действие в качестве аргумента:

{% load admin_urls %}
<a href="{% url opts|admin_urlname:'add' %}">Add user</a>
<a href="{% url opts|admin_urlname:'delete' user.pk %}">Delete this user</a>

Действие в примерах выше соответствует последней части имён URL для экземпляров ModelAdmin, описанных выше. Переменная opts может быть любым объектом, имеющим атрибуты app_label и model_name, и обычно предоставляется админ-представлениями для текущей модели.

Декоратор staff_member_required

staff_member_required(redirect_field_name='next', login_url='admin:login') [source]

Этот декоратор используется для админ-представлений, требующих авторизации. Представление, декорированное этой функцией, будет работать следующим образом:

• Если пользователь авторизован, является сотрудником (User.is_staff=True) и активен (User.is_active=True), представление будет выполнено нормально.
• В противном случае, запрос будет перенаправлен на URL, указанный в параметре login_url, с первоначально запрошенным путём в переменной строки запроса, указанной в redirect_field_name. Например: /admin/login/?next=/admin/polls/question/3/.

Пример использования:

from django.contrib.admin.views.decorators import staff_member_required

@staff_member_required
def my_view(request):
    ...