Задача [0202]: Двухуровневая модель разграничения привилегий для объектов конфигурации

Формулировка проблемы: необходимо реализовать возможность доступа пользователям определеннных групп на изменение конфигурации только определенных объектов, например, группа "локальные методологи" может править только собственные реестры и просматривать все остальные, аналогично для других объектов конфигурации.

Решение:

Перед разработкой основной задачи необходимо реализовать следующие ее подзадачи:

Вложенные группы

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

  • Группа 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 - количество всех пользователей, входящих в данную группу.