Разработка:Управление доступом

Управление доступом

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

Общая информация

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

• acl - список полномочий. Хранит информацию о том в каком плагине какие полномочия существуют.
• aclwarrants - Мандаты и доверенности.
• aclwarrantagents - Применение доверенностей. Определяет, каким пользователям какие доверенности выданы.

Общие правила и требования

• Сторонние плагины могут зависеть от плагинов прав доступа, а плагины прав доступа не могут зависеть от остальных плагинов, и извлекать информацию из них (за исключением события установки/обновления плагина).
• Каждый плагин, предоставляющий права доступа должен описывать права в функции acldefault()
  • Формат массива:

array(
    'view' => array('teacher', 'manager'),
    'edit' => array('manager')
);

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

• Все плагины, отвечающие за работу с полномочиями имеют префикс acl.
• Все функции в сторонних плагинах, которые управляют правами доступа должны иметь префикс acl
• В плагинах типа im и modlib следует для проверки стандартных прав доступа обращаться к плагинам storage.
• При построении прав на смену статуса объектов деканата имеет значение лишь то, в какой статус будет осуществлен перевод. Следовательно, необходимо реализовывать только права changestatus:to:СТАТУС.
  • Право changestatus:from:СТАТУС следует устанавливать только для ограничения возможности вывода из спецстатусов.
  • Право changestatus без модификаторов, дает право перевода из любого статуса в любой, кроме специальных (для которых объявлено право changestatus:from:Статус). Право changestatus:to:Статус дает право на перевод в целевой статус из любого другого, кроме специальных, для которых объявлено право changestatus:from:Статус.

Как происходит процесс установки прав

При установке, обновлении или удалении любого плагина, если он предоставляет права доступа - то в функциях upgrade(), delete(), и install() нужно вызывать функцию save_roles() плагина acl .

Правила работы с правами доступа

Полномочия (acl)

• Полномочия не имеют статусов, поэтому при удалении плагина все полномочия, принадлежащие ему также физически удаляются из таблицы
• Для хранилищ и рабочих процессов существуют стандартные полномочия
• Полномочия проверяются только тем плагином, в котором они содержатся. То есть - из im/persons можно проверять только права im/persons, из storage/persons только права storage/persons. Нельзя проверять из одного плагина права другого плагина.

Мандаты и доверенности (warrants)

• Действия при удалении мандата или доверенности
  • Основным способом удаления мандата следует считать перевод записи в статус "archive"
  • Все дочерние доверенности и мандаты также перестают действовать
  • Прекращают действия все применения полномочий ( aclwarrantagents ) которые были назначены указанным мандатом.
• При установке прав новым плагином все новые права добавляются к стандартным доверенностям
• Плагины не могут добавлять свои доверенности при установке
• Стандартные доверенности не могут быть назначены пользователям
• Если запрещается наследование для доверенности, которую раньше можно было наследовать - то старые дочерние доверенности продолжают свое действие, но новые создать нельзя

Синхронизация

Здесь описаны плагины, которые должны синхронизироваться с таблицей доверенностей.

• storage/positions

Применение полномочий (warrantagents)

• При прекращении действия доверенности, применение полномочия прекращает действовать (переводится в статус archive)
• При истечении срока действия применение полномочия переводится в статус archive

Синхронизация

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

• storages/appointments

Опасные действия и режим работы в обход стандартной логики (datamanager)

Режим datamanager позволяет админам действовать в обход стандартной логики на свой страх и риск. Такие действия могут понадобиться, например, в случае выполнения ошибочных действий сотрудниками, однако не должны быть доступны обычным пользователям во избежание потери данных или консистентности данных. Чтобы для выполнения этих действий не требовалась модификация напрямую через СУБД, реализован опасный режим.

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

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

Принципы реализации проверок для режима datamanager

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

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

• По возможности необходимо реализовать более полные и глубокие проверки, например, запрещать не любое изменение даты, а только опасное, вызывающее противоречие и могущее повлечь порчу данных (например, дата старта обучения должна быть не позже даты первого результата обучения, оценки, подписки на элемент учебного плана и т.п.). При недостатке ресурсов предпочитаем полное блокирование изменения поля и полагаемся на режим datamanager, где пользователь может выполнить изменения полностью на свой страх и риск, самостоятельно проверив непротиворечивость данных.
• Режим datamanager разрешает любое редактирование. Опасные ситуации, которые могут привести к порче данных, должны быть доступны только в этом режиме и описаны.
• datamanage - это право, предназначенное только для игнорирования некоторых (добавленных с целью сохранения консистентности) валидаций данных, она не добавляет и не убирает никаких прав, если их нет, для выполнения опасного действия помимо собственно нужно иметь право для исполнения этого действия и подтвержденное согласие работы в опасном режиме

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