Формулировка проблемы: необходимо реализовать возможность доступа пользователям определеннных групп на изменение конфигурации только определенных объектов, например, группа "локальные методологи" может править только собственные реестры и просматривать все остальные, аналогично для других объектов конфигурации.
Решение:
Перед разработкой основной задачи необходимо реализовать следующие ее подзадачи:
Полное логирование всех действий в Конфигураторе и Административном приложении
Вложенные группы
Служебные группы по оргструктуре
Необходимо реализовать поддержку вложенных групп, т.е. структур вида:
Группа 1
Группа 1.1
Группа 1.2
Группа 1.2.1
Группа 1.3
Группа 2
и так далее. Имеющиеся на момент реализации в системе группы становятся группами первого уровня иерархии, внутри которых можно будет создавать другие группы, а также добавлять пользователей.
Следует разделить понятия пользователь принадлежит к группе и пользователь входит в группу. В первом случае подразумевается, что пользователь был непосредственно добавлен в группу, а во втором - пользователь может как принадлежать к группе, так и относиться к ней по принципу наследования из дочерних групп. Пример:
Группа 1 - Пользователь 1
Группа 1.1 - Пользователь 2
Группа 3
Здесь Пользователь 2 принадлежит к Группе 1.1, и, кроме того, входит в Группу 1.
При редактировании групп в Конфигураторе и Административном приложении внутри группы отображаются только принадлежащие ей пользователи, а при отображении групп в основном приложении ARTA Synergy и при манипуляциях с группой как с атомарным объектом - например, назначении прав - используются входящие в нее пользователи (без дублей).
Для удобства назначения прав, а также для того, чтобы избежать создания вручную групп, полностью идентичных подразделениям организационной структуры, необходимо реализовать поддержку служебных групп на основании подразделений оргструктуры.
Требования к группам по подразделениям (далее просто группы):
Группы должны быть вложенными, т.е. если группа соответствует подразделению, входящему в другое подразделение, то она находится внутри группы родительского подразделения, и так далее.
Название группы (на всех поддерживаемых системой языках) должно быть таким же, как у соответствующего подразделения, и изменяться вместе с ним
Группу нельзя изменять либо удалять таким же образом, как обычную группу (через интерфейс управления группами либо системное API).
Состав группы также нельзя изменять напрямую, т.е. - добавлять пользователей либо другие группы явным образом - только манипулируя организационной структурой.
Если группа является подразделением, то к ней принадлежит руководитель этого подразделения, его И.О. и заместители, а также все пользователи всех должностей, непосредственным родительским подразделением которых является данное подразделение
В группу входят все пользователи, принадлежащие ей и вложенным группам (как следует из предыдущей подзадачи)
Примечание
Ввиду невозможности редактирования служебных групп, таким группам возможно назначение прав только на чтение и назначение прав.
Реализуемая функциональность по ограничению доступа относится только к действиям изменения объектов конфигурации, производимым через интерфейс Конфигуратора, Административного приложения, а также соответствующего API. Она не относится к правам пользователей на действия, производимые в рамках обычной работы с этими сущностями.
Пример
Объект конфигурации - реестр. Новая функциональность касается только настройки конкретного реестра или реестров, т.е. изменения его названия, маршрута, сопоставлений и т.д., но не касается прав на создание, просмотра, редактирования, изменения и удаления записей в самом реестре - за это отвечает уже имеющаяся система прав на реестры.
Двухуровневость разграничения привилегий заключается в том, что существующие администраторы системы и методологи имеют возможность изменять все объекты конфигурации, которые были доступны им и ранее, и, кроме этого, назначать другим пользователям, входящим в определенные группы, часть собственных привилегий.
Назначение привилегий осуществляется созданием троек вида:
(ОБЪЕКТ, ГРУППА, НАБОР РАЗРЕШЕНИЙ)
где
ОБЪЕКТы на момент реализации данной задачи ограничены следующими объектами конфигурации:
Формы
Реестры
Группы
Оргструктура (подразделения, должности)
Папки в Хранилище файлов
ГРУППы - как уже имеющиеся в системе группы, так и реализуемые служебные группы (см. предыдущую задачу)
НАБОР РАЗРЕШЕНИЙ включает в себя следующие базовые разрешения на действия с объектом:
Чтение (включает в себя использование объекта в других объектах конфигурации)
Изменение
Назначение прав
а также специфические для каждого объекта разрешения.
Примечание
Глобальный методолог (суперметодолог) при наличии, по умолчанию, полных прав на все объекты конфигурации, не должен иметь доступа к административному приложению без явного наличия прав на объекты "группы" или "оргструктура". Данное ограничение не касается системного API.
Манипуляция привилегиями осуществляется теми пользователями, которые имеют соответствующие права:
Глобальные методологи и администраторы
Пользователи, входящие в группы, для которых имеется разрешение на назначение прав к каким-либо объектам
Если какие-либо объекты имеют иерархическую структуру, т.е. могут иметь родительские и дочерние элементы, набор разрешений конкретного объекта получается путем суммирования его собственных разрешений и разрешений, полученных от всех элементов выше его по иерархии.
В таблице прав объекта при этом перечисляется только ненаследуемые права.
При отсутствии прав на корневой элемент объекта конфигурации, но наличии прав на какой-либо его дочерний элемент, локальный методолог / администратор будет видеть этот корневой элемент.
Пример:
Имеется такая структура групп:
Группа_О_1
Группа_O_1.1.
Группа_O_1.2.
Группе
Группа_Г_1даны права на чтение группыГруппа_О_1, а также на изменение группыГруппа_О_1.1. Итоговый набор разрешений у группыГруппа_О_1.1будет составлять: чтение и запись.
Примечание:
Набор разрешений, заданных в объемлющем элементе для таких объектов, как формы и реестры, также наследуется по этому же принципу, т.е. если для группы имеется разрешение на изменение в узле "Формы", то пользователи этой группы могут менять все формы, и т.д.
В экране редактирования группы, ввиду возможности наличия вложенных групп, необходимо:
во-первых, в названии экрана отображать путь до текущей отображаемой группы, например:
Группа 1 / Группа 2 / Группа 3
во-вторых, к кнопке добавления пользователя в группу необходимо добавить кнопку добавления вложенной группы.
Возврат "Назад" должен возвращать методолога на предыдущую группу / вложенную группу.
Кроме того, в списке групп цифру, обозначающую количество пользователей в ней, необходимо расширить до значения "N/M", где N - количество пользователей, принадлежащих конкретно данной группе, а M - количество всех пользователей, входящих в данную группу.