Действия администратора ¶

Написание функций действий ¶

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

• Электрический ток ModelAdmin
• HttpRequest, Представляющий текущий запрос,
• Объект, QuerySetсодержащий набор объектов, выбранных пользователем.

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

def make_published(modeladmin, request, queryset):
    queryset.update(status='p')

for obj in queryset:
    do_something_with(obj)

На самом деле это все, что нужно для написания экшена! Однако мы сделаем еще один необязательный, но полезный шаг и дадим действию «приятный» заголовок в админке. По умолчанию это действие отображается в списке действий как «Сделать опубликованным» - имя функции с заменой подчеркиваний на пробелы. Это нормально, но мы можем предоставить лучшее, более понятное для человека имя, используя action()декоратор make_published функции:

from django.contrib import admin

...

@admin.action(description='Mark selected stories as published')
def make_published(modeladmin, request, queryset):
    queryset.update(status='p')

Добавление действий в ¶ModelAdmin

Далее нам нужно сообщить нам ModelAdminо действии. Это работает так же, как и любой другой вариант конфигурации. Итак, комплект admin.pyс действием и его оформлением будет выглядеть так:

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

@admin.action(description='Mark selected stories as published')
def make_published(modeladmin, request, queryset):
    queryset.update(status='p')

class ArticleAdmin(admin.ModelAdmin):
    list_display = ['title', 'status']
    ordering = ['title']
    actions = [make_published]

admin.site.register(Article, ArticleAdmin)

Этот код даст нам список изменений администратора, который выглядит примерно так:

Вот и все! Если вам не терпится написать свои собственные действия, теперь вы знаете достаточно, чтобы начать. Остальная часть этого документа посвящена более продвинутым методам.

Обработка ошибок в действиях ¶

Если во время выполнения вашего действия могут возникнуть предсказуемые ошибки, вы должны аккуратно проинформировать пользователя о проблеме. Это означает обработку исключений и использование django.contrib.admin.ModelAdmin.message_user()для отображения удобного для пользователя описания проблемы в ответе.

Действия как ModelAdminметоды ¶

В приведенном выше примере показано make_publishedдействие, определенное как функция. Это прекрасно, но не идеально с точки зрения дизайна кода: поскольку действие тесно связано с Articleобъектом, имеет смысл привязать действие к ArticleAdminсамому объекту.

Сделать это можно так:

class ArticleAdmin(admin.ModelAdmin):
    ...

    actions = ['make_published']

    @admin.action(description='Mark selected stories as published')
    def make_published(self, request, queryset):
        queryset.update(status='p')

Обратите внимание , что первыми мы перешли make_publishedв метод и переименован в modeladminпараметре self, а второй , который мы сейчас ставим строку 'make_published'в actionsвместо прямой ссылки на функцию. Это говорит, что ModelAdminнужно искать действие как метод.

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

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

from django.contrib import messages
from django.utils.translation import ngettext

class ArticleAdmin(admin.ModelAdmin):
    ...

    def make_published(self, request, queryset):
        updated = queryset.update(status='p')
        self.message_user(request, ngettext(
            '%d story was successfully marked as published.',
            '%d stories were successfully marked as published.',
            updated,
        ) % updated, messages.SUCCESS)

Это заставит действие соответствовать тому, что делает сам администратор после успешного выполнения действия:

Действия, которые предоставляют промежуточные страницы ¶

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

Чтобы предоставить промежуточную страницу, верните HttpResponse (или подкласс) из вашего действия. Например, вы можете написать функцию экспорта, которая использует функции сериализации Django для вывода некоторых выбранных объектов в виде JSON:

from django.core import serializers
from django.http import HttpResponse

def export_as_json(modeladmin, request, queryset):
    response = HttpResponse(content_type="application/json")
    serializers.serialize("json", queryset, stream=response)
    return response

Как правило, что-то подобное не считается хорошей идеей. В большинстве случаев наилучшей практикой будет возвращение HttpResponseRedirectи перенаправление пользователя к написанному вами представлению, передавая список выбранных объектов в строке запроса GET. Это позволяет обеспечить сложную логику взаимодействия на промежуточных страницах. Например, если вы хотите предоставить более полную функцию экспорта, вы хотите, чтобы пользователь мог выбирать формат и, возможно, список полей для включения в экспорт. Лучше всего было бы написать небольшое действие, которое перенаправляет на ваше настраиваемое представление экспорта:

from django.contrib.contenttypes.models import ContentType
from django.http import HttpResponseRedirect

def export_selected_objects(modeladmin, request, queryset):
    selected = queryset.values_list('pk', flat=True)
    ct = ContentType.objects.get_for_model(queryset.model)
    return HttpResponseRedirect('/export/?ct=%s&ids=%s' % (
        ct.pk,
        ','.join(str(pk) for pk in selected),
    ))

Как видите, действие довольно короткое; вся сложная логика будет принадлежать вашему экспортному представлению. При этом потребуется иметь дело с объектами любого типа, следовательно, дело с ContentType.

Написание этой точки зрения оставлено читателю в качестве упражнения.

Делаем действия доступными для всего сайта ¶

AdminSite.add_action( действие , имя = Нет ) ¶

Некоторые действия лучше, если они доступны для любого объекта на сайте администратора - действие экспорта, определенное выше, было бы хорошим кандидатом. Вы можете сделать действие глобально доступным, используя AdminSite.add_action(). Например:

from django.contrib import admin

admin.site.add_action(export_selected_objects)

Это делает export_selected_objectsдействие глобально доступным как действие с именем «export_selected_objects». Вы можете явно дать действию имя - хорошо, если позже вы захотите программно удалить действие, - передав второй аргумент в AdminSite.add_action():

admin.site.add_action(export_selected_objects, 'export_selected')

Отключение действий ¶

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

class MyModelAdmin(admin.ModelAdmin):
    actions = None

Настройка разрешений для действий ¶

Действия могут ограничить их доступность для пользователей с определенными разрешениями, заключив функцию действия в action() декоратор и передав permissionsаргумент:

@admin.action(permissions=['change'])
def make_published(modeladmin, request, queryset):
    queryset.update(status='p')

make_published()Действия будут доступны пользователям , которые проходят только ModelAdmin.has_change_permission()проверку.

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

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

• 'add': ModelAdmin.has_add_permission()
• 'change': ModelAdmin.has_change_permission()
• 'delete': ModelAdmin.has_delete_permission()
• 'view': ModelAdmin.has_view_permission()

Вы можете указать любое другое значение, если вы реализуете соответствующий метод в .has_<value>_permission(self, request)ModelAdmin

Например:

from django.contrib import admin
from django.contrib.auth import get_permission_codename

class ArticleAdmin(admin.ModelAdmin):
    actions = ['make_published']

    @admin.action(permissions=['publish'])
    def make_published(self, request, queryset):
        queryset.update(status='p')

    def has_publish_permission(self, request):
        """Does the user have the publish permission?"""
        opts = self.opts
        codename = get_permission_codename('publish', opts)
        return request.user.has_perm('%s.%s' % (opts.app_label, codename))