Как сделать суперюзера джанго

Обновлено: 04.07.2024

Django предоставляет из коробки систему аутентификации и авторизации(permission) пользователей. Эта система позволяет проверять учетные данные пользователей и определять права доступа для пользователей. Ввод логина и пароля - это аутентификация пользователей , а права доступа на редактирование записей , создание новых и удаление - это уже авторизация. Поэтому,с помощью permissions мы указываем какие действия могут выполнять пользователи на сайте , а к каким запрещен доступ.

После создания нового проекта на Django , то в файле settings.py вы можете увидеть , что система аутентификации django.contrib.auth уже включена . Также по умолчанию включена система типов контента Django django.contrib.contenttypes, которая позволяет связывать разрешения(permissons) с создаваемыми вами моделями.

С этими настройками после выполнения команды python manage.py migrate в базе данных создаются необходимые таблицы для моделей связанных с аутентификацией и с разрешениями(permissions)

Таким образом , Django имеет встроенную систему разрешений(permissions). Эта система позволяет назначать разрешения конкретным пользователям и группам пользователей.

Эту систему использует Django admin

Django по умолчанию для модели создает 4 разрешения. Давайте посмотрим это на примере и потом подробно обсудим все 4 разрешения предоставляемых для модели по умолчанию

Создадим в нашем проекте новое приложение(application)

В файле models.py создадим модель Post

После выполнения миграции в базе данных создается таблица blog_post. Также в таблицу auth_permission добавляются четыре разрешения(permissions) ассоциированных с моделью Post.

Django для нашей модели Post после выполнения миграций создала четыре разрешения

Разрешение add(в нашем случае add_post) позволяет пользователям добавлять экземпляры модели.
Разрешение change(в нашем случае change_post) позволяет пользователям редактировать экземпляры модели
Разрешение delete(в нашем случае delete_post) позволяет пользователям удалять экземпляры модели
Разрешение view(в нашем случае view_post) позволяет пользователям просматривать экземпляры данной модели. Это разрешение появилось в Django 2.1

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

В нашем случае для модели Post разрешения будут выглядеть следующим образом:

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

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

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

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

В приложении blog для модели Blog создадим вьюху для добавления поста. Добавлять пост может только пользователь у которого будет разрешение add_post

Здесь мы используем миксин PermissionRequiredMixin , потому что мы используем CreateView для создания нового объекта модели поста. У миксина PermissionRequiredMixin в поле permission_required мы задаем разрещение : blog.add_post.Если пользователь аутентифицирован , но при этом у него нет разрешения добавлять посты , то ему будет отказано в доступе к этой вьюхе и будет возвращен код 403(Доступ воспрещен). А если у него будет разрещение blog.add_post , то он сможет создать новый пост

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

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

Для неаутентифицированного пользователя AnonymousUser метод has_perm всегда будет возвращать false.

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Django Admin и модель Permissions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Причем, по умолчанию, фреймворк использует английский язык. Чтобы переключиться на русскую локализацию, нужно в пакете конфигурации в файле settings.py изменить константу LANGUAGE_CODE, установив ее в значение:

И при обновлении страницы увидим русскоязычный вариант админ-панели.

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

python manage.py createsuperuser

Однако, здесь нет нашего приложения women. Почему? Дело в том, что его нужно зарегистрировать, то есть, указать, что мы хотим его видеть в админ-панели. Для этого откроем файл women/admin.py, который отвечает за взаимосвязь приложения с админкой, где мы будем регистрировать наши модели. Вначале импортируем их:

и зарегистрируем модель Women:

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

Так стало гораздо лучше. Добавим сортировку записей по дате их создания и по заголовку с помощью еще одного атрибута ordering:

Как происходит упорядочение по нескольким полям? Сначала идет сортировка по первому полю (в данном случае дате создания), но если даты оказываются равными, то учитывается следующее поле (заголовок) и так далее. Перейдем в админ-панель и видим, что особо ничего не поменялось, записи и так шали в порядке возрастания времени создания. Изменим сортировку по первому полю на противоположную (ставим знак минус):

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

Здесь тоже обратите внимание, что все это работает благодаря подключению приложения в пакете конфигурации (файл settings.py) через этот класс:

Следующим шагом добавим в списке записей дополнительные поля: id, title, время создания, изображение, флаг публикации. Для этого нужно открыть файл women/admin.py и объявить класс, унаследованный от ModelAdmin:

Здесь в атрибуте list_display указываем список отображаемых полей, в атрибуте list_display_links – список полей в виде ссылки для перехода к конкретной записи, а атрибут search_fields определяет поля, по которым можно будет производить поиск записей. (В этом классе есть и другие атрибуты, вы можете изучить их самостоятельно).

Зарегистрируем этот класс в функции register:

причем, WomenAdmin должен обязательно идти после класса модели Women. Возвращаемся в админку и видим все эти поля. Но они имеют английское написание, а нам бы хотелось иметь русские названия. Поправим. Перейдем в класс определения модели Women (women/models.py) и у каждого поля в конструкторе соответствующих классов добавим именованный параметр verbose_name:

Теперь имена полей отображаются с нашими значениями.

По аналогии зарегистрируем вторую модель Category. В файле women/admin.py пропишем:

И вызовем функцию register:

Переходим в админку и видим, что появилось второе приложение с набором указанных полей. Также скорректируем все названия. Перейдем в файл women/views.py и в класс Category добавим вложенный класс Meta:

Кроме того, у поля name добавим параметр verbose_name:

Все, теперь мы можем полноценно работать и с рубриками в нашей админ-панели.

Однако, измененное метаописание полей модели (параметр verbose_name) желательно внести и в таблицы БД. Создадим еще один файл миграции командой:

python manage.py makemigrations

и, затем, применим все миграции:

python manage.py migrate

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

Мы здесь вначале проверяем: имеется ли вообще какой-либо путь к изображению (так как не у всех наших записей он присутствует), а затем, используем встроенный атрибут url, который возвращает корректный URL-адрес к текущему изображению. Я загружу все изображения для каждой статьи и получим уже более полноценное отображение постов.

Давайте еще немного улучшим нашу админку и сделаем так, чтобы поле is_published можно было редактировать прямо в списке статей. Выполняется это очень просто. В классе WomenAdmin (файл women/admin.py) добавим еще один атрибут:

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

Далее, добавим поля, по которым сможем фильтровать наш список статей. Опять же в классе WomenAdmin прописываем атрибут:

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

Вот так в базовом варианте можно выполнять настройку админ-панели и работать через нее с записями таблиц БД.

Видео по теме

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

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