К данным

Доступ к данным разделяется на два отдельных механизма. Первый, это ограничение на получение данных, то есть на все “get” (SELECT) запросы, в том числе и внутренние, а второй ограничения на все прочие методы, как базовые, так и кастомные.

Ограничения на получение данных (метод “get”)

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

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

Важной, и не совсем очевидной особенностью данного механизма, является как раз ограничения доступа к данным для внутренних запросов, то есть таких, когда изначальный запрос проходит проверку доступа (не важно ограниченного списком или нет), а дальше внутри этого метода выполняются подзапросы других данных, и если для этих данных есть настройка доступа по списку, то она будет применена. Рассмотрим на примере вымышленного метода Product.getAvailable, который должен вернуть доступные для приобретения товары. Допустим, что такой метод сперва получает активные Категории, а еще, допустим, что определенным категориям клиентов, мы ограничиваем набор Категорий товаров, выдавая как раз доступ по списку (список корректируется автоматически в ходе отдельных бизнес-процессов). Тогда в ходе метода, при получении Категорий, сработает механизм доступа по списку и метод получит ограниченный набор Категорий, для которых уже будут собраны доступные Продукты. В приведенном примере, должен быть настроен доступ к методу “get” класса “Product_category” с признаком “Access_by_list”.

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

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

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

Не только получение данных может быть ограничено списком, но и прочие методы, как базовые (modify/remove/…), так и кастомные (например описанный выше getAvailable).

Это позволяет гибко настраивать возможности пользователя по взаимодействию с данными, например, просматривать можешь все Заявки своей организации, а обрабатывать (Принимать, Отклонять, Выполнять), только те, которые соответствуют твоей специальности (следовательно к которым выдан доступ для соответствующих операций, например setAccepted).

Механизм применим к операциям работающим по определенному id или ids и не может быть применен к операциям с неопределенным набором данных, например метод (вымышленный) applyAll. В этом операция пропускается. Однако внутри методов с неопределенным набором данных, как правило внутри есть запросы на получение уже определенных наборов, которые фильтруются по списку, при наличии такой настройки для роли пользователя для запрашиваемого класса.

Для операций работающих по ids (исключая операцию “get”) имеется два режима ограничения, в случае если хотя бы один id не проходит проверку. В первом случае (по умолчанию) идет отказ доступа для операции, во втором, не найденные id исключаются из параметров. Настройка называется access_by_list_filter_only. Ее имеет смысл включать (сделать так чтобы отказа не было, а просто фильтровался входной список) для кастомных операций типа “get”.

Часто проще всего (если это соответствует бизнес-логике) настроить доступ таким образом, чтобы доступ к операции, например “modify”, допускался для того же списка, что и операция получения данных (“get”). Это можно сделать установив для указанной операции, (например “modify”) галочки is_access_by_list и Is_access_by_list_like_get.

Также можно сделать чтобы список наследовался от списка для “get”, но вдобавок применялся собственный список, для этого установите is_access_by_list_like_get_plus_self.

Иерархическое распространение доступа из списка

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

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

На примере, мы можем предоставить пользователю доступ к определенному Проекту и указать, что доступ будет распространяться на все его дочерние Подпроекты, а также на Изображения_проекта (каждого, к кому наследуется доступ), Характеристикам_проекта и прочим дочерним сущностям (опционально). В свою очередь можно также отнаследовать доступ к Авторам_изображений_проекта, например, и так далее.

Настройки доступа к операциям с признаком “Доступ по списку” и структура наследования доступа регулируется на уровне Роли, которая в дальнейшем выдается пользователю.

Автоматическое управление списком

Чтобы выдать доступ к конкретной записи, необходимо добавить запись в таблицу связи. Правильнее всего это делать автоматически, например переопределив и дополнив метод добавления записи к сущности определяющий отношение пользователей к определенной сущности. На примере Проектов, эта сущность может быть Участники_проекта или, например, Администраторы проекта. То есть по изменению состава Участников, может вызываться метод синхронизации (его нужно написать, но это довольно просто) пользователей в этом списке и Списка_доступа к нужным операциям. Для Администраторов, например будут добавляться записи для операций get/add/modify/remove в список доступа для этих пользователей, а для Участников_проекта, только для операций get/modify. При этом разумеется у Администраторам должна выдаваться роль “Администратор проекта”, для которой будет настроен доступ к этим операциям с галочкой “доступ по списку”, и соответственно Участникам, своя роль, со своими настройками. Таким образом, метод синхронизации Корректирует для пользователя набор ролей, и список доступа.

Подключение Участников или Администраторов или еще какой-либо связи реализуется через интерфейс системы, например с помощью TwoColumnEditor.