Разные права для разных расписаний¶
- Table of contents
- Разные права для разных расписаний
Задача¶
Минимальными средствами реализовать разные права для разных расписаний.
Реализация¶
В таблицу RIGHTS добавляется:
- ResourceId - текстовое обнуляемое поле , в случае расписания - имя каталога расписания.
- Permission - значение разрешения, по умолчанию - 1 = можно.
При проверке права в функцию проверки передается дополнительный ID расписания, при проверке сначала ищется право с совпадающим ресурсом, если оно есть, то действие разрешается, в противном случае ищется запись со значением ресурса NULL, если находится, то действие разрешается, в противном случае - нет.
Т.е. при ResourceId = NULL это действие по умолчанию.
Ситуация, когда Right = NULL, а ResourceId не пустой рассматривается как право на сам доступ к ресурсу в целом. Запрет данного доступа блокирует все права для данного ресурса.
При настройке¶
Текущие права разбиты на группы. Добавляем возможность указания для группы прав множества объектов с их идентификаторами. При наличии у группы прав объектов - при открытии редактора прав добавляется еще один уровень вложенности, с узлами: "По умолчанию", "Имя ресурса 1", "Имя ресурса 2" и т.д.
При этом все ветки содержат одинаковый набор правил - все правила группы. Ветка "По умолчанию" сохраняется в БД с идентификаторами ресурсов = NULL, остальные ветки - с реальными ИД. В БД запись вносится только если право разрешено.
Имена ресурсов в БД не хранятся, а берутся из объекта - ресурса, добавленного к группе прав извне. Соответственно, если открыть окно настройки на рабочем месте, где нет (почему?) расписаний - то они в настройке не появятся. Думаю, на это можно пойти.
Проверка прав¶
На входе право:ресурс
- NULL:NULL - ошибка, результат отрицательный
- NULL:RES - проверка доступа к ресурсу в целом
- Нет запрета - разрешено
- Запрещено
- RIGHT:NULL - проверка безресурсного правила
- Есть разрешающая запись - можно
- Нельзя
- RIGHT:RES - проверка доступа к конкретному ресурсу
- Сначала NULL:RES - если запрет, то запрет
- Потом проверим разрешение RIGHT:RES и, если оно есть, то вернем результат
- вернем RIGHT:NULL
При проверке доступа к папке расписаний возникают следующие логические изменения:
* в текущей системе настройки шаблоны и сетки отсутствуют как самостоятельные объекты - это дочерние объекты папки расписаний
* соответственно, права работы с ними должны предоставляться как и другие права для работы с конкретной Папкой расписаний
* поэтому, отдельная группа прав Шаблоны перестает существовать, все права оттуда переезжают в группу Расписание. При этом естественным образом сохраняется текущая настройка, т.к. разбиение прав на группы не хранится в БД. Все сделанные у заказчика настройки сохраняются, при этом, так-ка у них не указаны ИД ресурсов, то эти настройки становятся "настройками по умолчанию" для все существующих ресурсов. Т.к. прав для конкретных ресурсов у заказчика быть не может, то администрирование полностью сохраняет свои настройки.
* для Сеток необходимо ввести аналогичные шаблонам права, но в более простом виде
* можно смотреть сетки
* можно редактировать сетки
* нюансы проверки
* все права доступа к содержимому расписания проверяются одним методом, который вызывается глубоко из расписания, которое не знает, шаблон оно, сетка или расписание. Оно знает только свой путь хранения. Причем, у сеток он пустой.
* При проверке в метод проверки добавляем передачу пути расписания.
* Получаем систему, нормально работающую для шаблонов и расписаний, но при редактировании сеток будет проблема
* проблема:администрирование не будет работать, т.к. будет проверять дефолтные права на работу с любым расписанием, а должна проверять работу с сеткой для данного расписания.
* решение:
* для объекта расписания вводится метод P_LIST::GetAccResourceId который возвращает идентификатор ресурса для данного расписания. В случае сеток он должен возвращать Ид расписания, к которому относится сетка.
* Тип расписания при редактировании сетки должен быть - PTYPE_PATTERN, т.е. шаблон.
* Тогда все действия будут проверяться для сетки как как для шаблона данного расписания. Т.к. шаблоны и сетки имеют идентичное назначение, то это допустимое ограничение.
* Дополнительное право на редактирование сеток влияет на возможность создания новых сеток в редакторе сеток и возможность сохранить изменения в редакторе сеток и клоков.
Вопросы
h3. Доступ к расписанию "вообще"
Хочется вообще лишить пользователя самого факта доступа к ресурсу. Например, к расписанию. Чтоб он его даже увидеть не мог. Т.е. данный ресурс для пользователя не доступен вообще. Его для пользователя просто не существует.
Как это сделать?
Предлагается использовать некое "псевдо право", единое для всех ресурсов, ну, например с ид –1, и проверять его для ид ресурса. Если оно не разрешено, то для этого ресурса запрещено вообще все. Визуально это может быть галочка на узле ресурса (что конфликтует с текущей логикой редактирования)
Необходимо для замены права Выбирать расписание конкретным доступам к конкретным расписаниям.
Невозможность запрета работы с одним ресурсом при разрешенных настройках "по умолчанию"¶
Т.к. сейчас хранится только факт "разрешения" (а его отсутствие - это факт запрета) то при иерархической проверке нельзя запретить что-то в дочернем узле при разрешенном родительском.
Иначе говоря, если я хочу запретить право А для одного расписания, то я обязан снять разрешение А в узле "По умолчанию" и не устанавливать разрешение на требуемом расписании.
Текущая система индикации состояния прав доступа при настройке не отображает данную ситуацию.
При правильном поведении чекбоксы на правах расписаний должны отображать состояние доступности прав, унаследованное от раздела "По умолчанию".
И при редактировании я могу переопределить данное поведение, установив явное разрешение или явный запрет.
Но это невозможно, т.к. в БД хранятся только разрешения.
Зависимости прав.¶
На примере. Есть два права - *читать *и изменять.
Изменять автоматически включает читать, иначе нет смысла. Но модуль чтения должен проверять только право читать.
Сейчас или админ обязан включить *читать *и изменять, или модуль проверять все возможные права.
В настоящее время второе - это совсем беда. Так что первое.
Предлагается: реализовать систему зависимости прав: при регистрации указываются права,
- включающиеся при включении этого
- выключающиеся при выключении этого
Соответственно, включении в админке права *Изменять *право *Читать *должно включаться автоматически без возможности выключения.
Право *Читать *при проверке должно отвечать "Да"
Не сохраненное содержимое и Logoff¶
Имеем редактор некоторого содержимого (добра), отображающий не сохраненное содержимое. (Из наших - редактор сюжетов, склеек, сеток).
- Залогинен пользователь А, имеющий право редактирования добра.
- Открыто окно редактора добра.
- Пользователь заходит в настройки и говорит - Логин.
- Открывается окно логина
- Приходит пользователь В, не имеющий права редактирования добра
- Логинится и видит перед собой открытый редактор добра с не сохраненным содержимым.
В зависимости от того, как обработаны права, он, на выбор
- Сможет сохранить то, на что нет прав (превышены полномочия)
- Не сможет сохранить нечто и кто-то потеряет результаты работы (потерян смысл).
Предложение:Ввести событие Logoff, происходящее при открытии окна Логин.
При этом должны выполнятся действия, аналогичные выполняемым перед завершением работы: "Вы хотите сохранить изменения…". С возможностью нажать Cancel и прервать Logoff.
После успешного завершения события Logoff в системе отсутмвует залогиненный пользователь. В текущей версии - сохраняется последний залогиненный.
