У доступа три уровня: существует ли операция, кто может её вызвать и какие записи она вернёт. Например, разрешение external-list открывает список, а readRule оставляет в нём только опубликованное. Клиентский фильтр не заменяет обязательное серверное правило.
Как включить нужные операции
admingen-cli --path ./docs-demo entity update Article \
--admin-list=true --admin-get=true --admin-delete=false \
--external-list anonymous --external-get anonymous \
--external-create off --external-update off --external-delete off
| Параметры entity add/update | Значения | Назначение |
|---|---|---|
--create, --read, --update, --delete |
true/false | Доступные операции модели. Read включает list/get. |
--admin-list, --admin-get, --admin-create, --admin-update, --admin-delete |
true/false | Вызовы административного API. |
--external-list, --external-get, --external-create, --external-update, --external-delete |
off/authenticated/anonymous | Внешний API: выключен, требует аутентификации, разрешён без входа. |
--list, --form |
true/false | Наличие сгенерированных экранов; это не серверная защита. |
При создании обычной сущности admin-доступ разрешён, external выключен. Update сохраняет непереданные свойства. У projection доступны только чтения. Маршруты смотрите в Generated routes или OpenAPI после Generate.
Разрешение не включает отключённую CRUD-операцию. Сначала убедитесь, что действие поддерживается самой моделью.
Как выдавать только опубликованные записи
Для readRule отдельного CLI-флага нет. Настройте условие в Entity settings → Access или добавьте его в существующую сущность в .admingen/project.yaml:
access:
external:
list: anonymous
get: anonymous
create: off
update: off
delete: off
readRule:
field: status
op: eq
value: published
Пример рассчитан на Article с enum status и вариантом published. При ручной правке сохраните остальные настройки access, особенно admin. Проверьте модель, выполните Generate и обновите backend обычным способом.
External list/get применит правило даже без фильтра в URL. Клиент не сможет запросить более широкий набор; запись, не прошедшая правило, не читается и по ID. Admin API и операции записи этим readRule не ограничиваются.
Как разделить условия блока, страницы и элементов
Допустим, источник виртуальной сущности — PageBlock, у него есть belongsTo page и выбранная коллекция items. Условия для самого блока и его страницы находятся в access.external.readRule:
readRule:
all:
- field: isVisible
op: eq
value: "true"
- field: page.status
op: eq
value: published
Правило элементов задаётся отдельно у выбранной коллекции в virtual.select. Ниже фрагмент selection; используемые поля должны существовать в вашей модели:
- relation: items
collection:
defaultLimit: 20
maxLimit: 100
orderBy:
field: position
direction: asc
readRule:
all:
- field: isVisible
op: eq
value: "true"
- field: title
op: ne
value: ""
select:
- field: id
- field: title
searchable: true
filterable: true
- field: position
sortable: true
В результате придут видимые блоки опубликованных страниц. Внутри каждого останутся видимые элементы с непустым title, отсортированные по position. Если подходящих элементов нет, блок всё равно вернётся с пустой коллекцией.
В UI те же условия находятся в отдельных блоках сущностей: так отбор родителей не смешивается с отбором вложенных записей.
Как записывать группы и значения
all объединяет условия через И, any — через ИЛИ. Группа может включать условия и другие группы: максимум 8 уровней и 64 узла. Обычное условие содержит field/op/value.
Значения задаются строками, включая числа и bool. ne с "" проверяет пустую строку, а не null. Для nullable есть isNull/isNotNull без value.
| Тип данных | Поддерживаемые сравнения |
|---|---|
| Текст | eq/ne/contains |
| Enum, UUID, bool | eq/ne |
| Числа и даты | eq/ne и дополнительно lt/lte/gt/gte |
Правило принадлежит конкретной сущности или проекции. От источника и целей связей оно не наследуется. Условия в этой версии постоянные: подставить текущего пользователя или время нельзя. searchable/filterable/sortable управляют возможностями клиентского запроса; readRule применяется независимо от них.
Как применить настройки
admingen-cli --path ./docs-demo plan
admingen-cli --path ./docs-demo generate --dry-run
admingen-cli --path ./docs-demo generate
Generate выпускает код, но не перезапускает работающий backend. После его обновления проверьте нужную выдачу. Подробности: API приложения, CLI проекций, вход и доступ.
Публичный кэш
В интерфейсе включайте его в Access → External READ access → Cache public responses. Для ручного манифеста в настройках access.external сущности:
cache:
enabled: true
ttlSeconds: 30
Это дополнение к существующим разрешениям, а не замена правил доступа. Для кэширования необходим анонимный List или Get. После Generate выпустите обновленный backend и Nginx. Полное поведение и задержка обновления контента описаны в публичном кэше.