Механизмы разграничения доступа

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

В системе используется два основных механизма по разграничению доступа: Дискреционная и Ролевая безопасность.

Дискреционная безопасность

Дискреционная безопасность - это уровень доступа (Пользователь/Администратор), который задается в карточке сотрудника. Используется в следующих случаях:

• Для приложений, опубликованных как “административный”. Например, TessaAdmin, опубликованный с параметром /admin будет доступен только сотрудникам с уровнем доступа Администратор.

• Для карточек с флагом “административный”. Т.е. сотруднику с уровнем доступа Администратор будут доступны все глобальные настройки (правая панель – меню Настройки), редактирование всех типов ролей, объектов маршрутов (шаблоны этапов, группы, вторичные процессы, методы расширений).

• Администратор может редактировать любые роли, в том числе карточки сотрудников, включая настройку замещений для любого сотрудника, смену пароля и т.д.

  Note

  Пользователю также можно выдать права на редактирование карточек сотрудников и подразделений, за исключением редактирования карточек сотрудников с административным доступом. Как это настроить описано в разделе Выдача прав на создание и редактирование карточек сотрудников/подразделений.

• Администратор может закрывать сессии других сотрудников.

• Администратор может для представлений и рабочих мест менять список ролей, кому они будут доступны. А также может выполнять импорт представлений и рабочих мест.

• Администратору доступен просмотр истории действий.

• Администратор может восстанавливать удаленные карточки или удалять их окончательно (см. Работа с удаленными карточками).

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

Ролевая безопасность

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

• По вхождению в ту или иную роль пользователь видит представление со списком каких-то объектов (например, реестр документов и основную информацию по документам, отображенную в колонках).

• По роли определяется видимость задач, а видимость задач в свою очередь влияет на возможность открыть карточку и подписывать в ней файлы; эти права выдаются “мимо” правил доступа. Более подробно см. раздел Система прав доступа к карточкам, включенным в типовое решение.

Права к приложениям и web-клиенту

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

• TessaClient - приложение доступно всем сотрудникам;

• TessaAdmin - доступно Администраторам системы (т.е пользователям, в карточке сотрудника которых установлен уровень доступа - Администратор).

Настроить права доступа к приложениям можно с помощью карточек приложений в представлении Администратор → Прочее → Приложения:

В карточке добавлены файлы опубликованного приложения, а также отображается информация по данному приложению:

В поле Роли, которым доступно приложение можно указать только те роли, доступ к приложению которым мы хотим дать. Если поле пустое - приложение доступно всем пользователям (или всем Администраторам, если это административное приложение).

Флаг Только для администраторов выставляется в случае, если приложение должно быть доступно только Администраторам системы (как, например, приложение TessaAdmin).

Note

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

Доступ к web-клиенту настраивается в карточке настроек сервера (правое меню → Настройки → Настройки сервера):

В поле Роли, которым доступен web-клиент можно указать любые роли, кроме контекстных. Только сотрудники, указанные в данном поле, или входящие в указанные роли, могут заходить в web-клиент.

Note

Помимо указанных прав доступа, для запуска приложения необходимо, чтобы в TESSA была карточка сотрудника с аккаунтом текущего пользователя и при этом доступ для него должен быть не запрещён.

Права, определяемые задачей или этапом маршрута/процесса

Независимо от настроенных правил доступа в TESSA, исполнитель задания на момент исполнения задания дополнительно получает следующие права доступа, которые будут утрачены сразу после завершения задания:

• Если задание не взято в работу:

  • Права на чтение карточки,

  • Права на подписание файлов электронной подписью.

• Если задания взято в работу, помимо указанных выше:

  • Права на добавление файлов,

  • Права на редактирование своих файлов.

При этом если задание не скрыто от автора (подробней см. Тип задания), то автор также имеет права на чтение карточки и подписание файлов.

Note

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

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

Для параллельного этапа включение этих опций может стать причиной конфликта сохранения, о чем написано в информационном блоке около этих флагов.

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

Исполнитель задания Доработка (на подсистеме маршрутов или в конструкторе бизнес-процессов) получает следующие права, помимо указанных выше:

• Редактирование всех файлов,

• Удаление всех файлов.

Система прав доступа к карточкам, включенным в типовое решение

Для карточек, включенных в типовое решение, автоматически начинает работать система прав доступа. В том числе в типовое решение можно включать карточки справочников и для них настраивать права доступа.

Основные принципы работы системы прав доступа

В данном разделе тезисно указаны принципы работы системы прав доступа в TESSA.

• В системе нет запрещающих правил доступа (за исключением запретов для отдельных секций/вкладок в расширенных правилах доступа). По умолчанию в системе всё запрещено, а правилами доступа выдается доступ кому-либо к чему-либо.

• Правила доступа никак не влияют на видимость строк в представлении. Видимость строк регулируется SQL запросом представления.

• Доступ к кнопкам запуска/отзыва различных процессов настраивается в карточках вторичных процессов или в карточках шаблонов процессов.

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

• Права доступа наследуются по замещению.

• С помощью расширенных прав доступа можно:

  • настроить доступ к отдельных полям и секциям карточки или задания;

  • маскировать данные;

  • указать видимость контролов и обязательность заполнения полей;

  • гибко настроить доступ к файлам.

Общий механизм расчёта прав доступа к карточке

Доступ к карточкам документов осуществляется согласно карточкам правил доступа и заданиям процесса, которые находятся в карточке.

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

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

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

Для представления доступны сабсеты по указанным разрешениям, состояниям карточки, указанным ролям и типам карточек:

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

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

Поиск по сотруднику проверяет все указанные в карточке правил доступа не контекстные роли на предмет вхождения в них указанного в поисковом параметре сотрудника.

В системе также есть возможность просмотра отчёта по правилам доступа. В нем в одном представлении отображены все настройки по типам карточек, состояниям, ролям и разрешениям. Данное представление имеет аналогичные сабсеты и настройки фильтрации, что и обычное представление по правилам доступа.

В данном представлении правила доступа, у которых включены расширенные настройки, в имени правила доступа есть приписка Расширенные настройки. Если в правиле доступа включен флаг Всегда проверять правило доступа, то данная строка подсвечивается желтым цветом. Если правило доступа отключено, то данная строка подсвечивается серым цветом.

Расширенные настройки правил доступа можно посмотреть через отдельное представление “Расширенные правила доступа”, которое представляет из себя master-detail представление “Правила доступа” и набора представлений для отображения расширенных настроек доступа:

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

Карточка правил доступа

Создавать и редактировать карточки правил доступа могут только сотрудники, имеющие уровень доступа “Администратор”. Создать новую карточку можно из правого меню “Создать карточку → Настройки → Правило доступа” или кнопкой создания в представлении “Администратор → Типовое решение → Правила доступа”:

Внешний вид основной вкладки карточки:

В карточке правил доступа указывается:

• Тема карточки – обязательное поле, указывается краткое название карточки.

• Описание – необязательное поле, указывается информация, раскрывающая тему карточки.

• Всегда проверять правила доступа - флаг указывает, что при расчёте прав доступа, если данное правило выполняется, то весь список разрешений, указанных в данном правиле, будет рассчитываться, а не только запрашиваемый набор прав.

  Пример

  Example

  Если в правиле доступа не выставлен флаг и при этом пользователь открывает карточку, находящуюся в состоянии, отличном от “Проект”, доступную ему по этому правилу доступа на чтение и редактирование, то карточка открывается только на чтение.

  Для перехода в режим редактирования пользователю необходимо в левом меню нажать на кнопку “Редактировать”, система выполнит расчёт прав и если есть какие-либо права, помимо чтения карточки, эти права буду предоставлены. В данном примере, после нажатия на кнопку “Редактировать”, поля карточки откроются на редактирование.

  Если в этом же правиле доступа выставить флаг, то та же карточка документа (доступная по правилу доступа на чтение и редактирование и находящаяся в состоянии, отличном от “Проект”) откроется сразу на редактирование, т.е. нет необходимости пользователю нажимать кнопку “Редактировать” в левом меню системы.

  Note

  Все расширенные настройки правил доступа к карточке также применяются без нажатия кнопки “Редактировать”, если установлен данный флаг.

  Warning

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

• Отключить правило доступа - флаг указывает, что данное правило отключено и его настройки не учитываются при расчёте прав доступа.

• Типы – обязательное поле, типы карточек, включенных в типовое решение, к которым применяется правило.

• Состояния карточек – состояния карточек, в которых будут работать определенные ниже разрешения.

• Список ролей – обязательное поле; роли, для которых выдаются указанные права для указанных типов карточек в указанных состояниях. В списке ролей можно указать, в том числе, и контекстные роли, например, “Инициатор” или “Создатель карточки”.

  Note

  Правила для контекстных ролей срабатывают только после сохранения карточки документа.

• Список условий - список дополнительных условий, которые проверяются при проверке правила. Более подробно про список условий можно посмотреть в разделе Заполнение таблицы с условиями.

• Список разрешений – разрешения, выдаваемые для указанных типов карточек в указанных состояниях для пользователей, состоящих в указанных ролях. Право на создание карточки не зависит от указанных состояний.

Внешний вид вкладки с расширенными настройками правил доступа:

Более подробно расширенные настройки прав доступа описаны в раздел Расширенные настройки прав доступа.

Права доступа к карточке

Существуют следующие права доступа к карточке:

• Создание карточки – пользователь, обладающий данным правом, может создавать карточку указанного в правиле типа. При создании карточки учитываются только настройки тех правил доступа, у которых установлен флаг Создание карточки.

  Note

  При определении доступности создания карточки указанные в правилах доступа контекстные роли игнорируются, а также не учитываются указанные состояния карточек и список условий.

  Important

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

• Создание шаблона и копирование - пользователь может создавать шаблоны карточек и копировать существующие в системе и доступные ему карточки.

• Чтение карточки – пользователь может открывать карточку и просматривать ее содержимое.

• Редактирование карточки – пользователь может редактировать поля карточки (кроме маршрута, номера документа и файлов, доступ, к редактированию которых, определяется отдельными правами). Может быть ограничен с помощью расширенных настроек правил доступа к карточке.

• Редактирование маршрута – пользователь может редактировать маршрут (кроме активных и завершенных этапов).

• Полный пересчёт маршрута - пользователь может выполнять пересчёт маршрута в карточке документа (доступна кнопка “Пересчитать” на вкладке “Маршрут”).

• Пропуск этапов - пользователь может пропускать этапы в маршруте. Данное разрешение будет работать только для тех этапов маршрута, в которых выставлен флаг “Разрешён пропуск” (подробней см. Общие настройки этапов).

• Ручное редактирование номера – пользователь может изменять номер документа.

• Подписание файлов - пользователь сможет подписывать электронной подписью приложенные файлы для указанных типов документов.

• Добавление файлов – пользователь может добавлять файлы в карточку.

• Редактирование собственных файлов - пользователь может редактировать только файлы, которые он сам добавил к карточке.

• Редактирование всех файлов – пользователь может редактировать любые файлы карточки.

• Удаление собственных файлов - пользователь может удалять только файлы, которые он сам добавил к карточке.

• Удаление всех файлов – пользователь может удалять любые файлы карточки.

• Удаление карточки – пользователь может удалить карточку.

• Инициация типового процесса отправки задач – пользователь может создавать задачи для этого документа, а также отправлять документ на ознакомление.

• Добавление обсуждений - пользователь может создавать новые обсуждения.

• Права супермодератора - пользователь имеет права супермеодератора. Это дает доступ ко всем обсуждениям карточки, а также позволяет добавлять в качестве участников обсуждения роли.

• Подписка на уведомления - пользователь может включать/отключать подписку на уведомления по карточке.

• Редактирование своих сообщений - пользователь может редактировать свои сообщения в обсуждениях, которые ему доступны.

• Редактирование всех сообщений - пользователь может редактировать все сообщения в обсуждениях, которые ему доступны.

  Note

  На работу флагов Редактировать мои сообщения и Редактировать все сообщения влияет поле Редактировать сообщения не старше, чем в карточке Настройки сервера, в котором можно указать период в минутах, в течении которого можно редактировать сообщения, начиная с момент отправки. При этом значение 0 означает, что редактировать разрешено без ограничения времени, а пустое значение - редактировать запрещено.

• Полнотекстовый поиск по сообщениям в обсуждениях – включает/отключает поиск по сообщениям в обсуждениях.

  Important

  Флаг Полнотекстовый поиск по сообщениям в обсуждениях может быть не доступен для редактирования, так как при установке TESSA не был установлен необходимый компонент полнотекстового поиска вашей СУБД. Для того чтобы этот флаг был доступен для редактирования, установите этот компонент.

  • Если TESSA установлена на систему Windows, в качестве СУБД MS SQL Server, то у Вас этот компонент должен быть установлен, исходя из документации MS SQL Server

  • Если вы используете PostgreSQL на любой системе, установка дополнительных компонентов не требуется.

  • Если TESSA установлена на Linux и при этом используется MS SQL Server, то по умолчанию пакеты, которые предоставляет Microsoft для различных дистрибутивов, не включает в себя этот компонент. Его необходимо установить дополнительно. Руководство по установке для дистрибутивов Linux есть на сайте с документацией для MS SQL Server

  После установки это компонента заново импортируйте схему.

• Чтение обсуждений - пользователь может читать все обсуждения.

• Чтение и отправка сообщений - пользователь может читать и отправлять сообщения во всех обсуждениях.

Расширенные настройки прав доступа

Подсистема прав доступа поддерживает расширенные настройки прав доступа.

Для включения расширенных настроек прав доступа необходимо на вкладке Расширенные настройки прав доступа установить флаг Использовать расширенные права доступа. После установки флага, в карточке станут доступны элементы управления расширенными настройками.

Note

Если флаг снять, то все элементы управления расширенными настройками исчезнут, при этом сами настройки не будут удалены, но они не будут учитываться при расчёте прав доступа.

Вкладка содержит следующие поля и таблицы:

• Приоритет - определяет приоритетность расширенных настроек правила доступа. Чем больше число, тем больше приоритет. Актуально для настроек прав доступа карточки, заданий и видимости.

• Расширенные настройки прав доступа карточки - таблица с настройками доступа к секциям и полям карточки, для которой производится расчёт прав доступа. В данной таблице можно запретить редактировать поле или секцию карточки, а также выдать доступ на редактирование конкретных полей или секций карточки даже при отсутствии права доступа Редактирование карточки. Также через данные настройки можно скрыть контрол по полю/секции карточки.

• Расширенные настройки прав доступа заданий - таблица с настройками доступа к секциям и полям заданий карточки, для которой производится расчёт прав доступа. Аналогично настройкам для карточки, только применяется к заданиям карточки.

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

• Расширенные настройки видимости - таблица с настройками видимости контролов карточки. Управление контролами идет по их Alias. Данные настройки позволяют скрыть вкладки, блоки или контролы по имени, а также показать скрытые контролы.

• Расширенные настройки доступа к файлам - таблица с настройками доступа к файлам карточки, для которой производится расчёт прав доступа. Через данную таблицу можно ограничить доступ к файлам карточки по категории файла и его расширению.

При настройке тех или иных расширенных прав доступа к контролам, подробно описанным ниже, указываются или алиасы контролов (при настройке видимости), или секции и поля, где хранятся значения контролов. Чтобы узнать названия этих сущностей, необходимо запустить TessaAdmin и в разделе Карточки найти тип карточки/тип задания и в разделе “Вкладки” найти нужный блок с полем.

Например, нас интересует поле “Подразделение” в карточке Приказа. Для определения названия типа карточки можно на основной вкладке карточки правила доступа открыть представление со списком типов и посмотреть алиас:

Теперь в TessaAdmin в разделе “Карточки”, зная название типа карточки, можно найти, на какой вкладке в каком блоке располагается искомый контрол и посмотреть его параметры:

В поле Алиас указан алиас контрола, который можно использовать при настройке видимости, а в поле Поля карточки можно узнать Секция: Поле, которые указываются при остальных настройках расширенных правил доступа.

Алиасы есть не только у контролов, но и у блоков и вкладок. Данными сущностями также можно управлять с помощью настроек видимости:

Расширенные настройки прав доступа карточки

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

Проверка правил идет по приоритетам. Настройки правил с более высоким приоритетом могут перекрывать настройки правил с более низким. Это значит, что если у правила доступа с более низким приоритетом запрещено редактирование какого-либо поля или секции целиком, а в правиле доступа с более высоким приоритетом это поле или секция разрешены для редактирования, то в итоге данное поле или секция будут доступны для редактирования.

Для правил доступа с одинаковым приоритетом действует следующее правило определения приоритета. Запрет доступа приоритетнее, чем разрешение доступа, однако настройки для конкретных полей приоритетнее, чем настройки для секции целиком. Таким образом можно запретить редактирование всей секции, но выдать доступ на редактирование определенных полей данной секции.

Каждое правило содержит следующие настройки:

• Секция - секция карточки, к которой применяется данное правило. Обязательное для заполнения поле. Если карточка не использует данную секцию (секция не добавлена в типе карточки), то данное правило применяться не будет.

• Поля - набор полей из секции, для которых применяется данное правило. Если не заполнено, то правило применяется ко всей секции.

• Настройка доступа - определяет настройку доступа для секции/полей данного правила. Если не заполнено, то настройка доступа не применяется (но все еще может быть применена настройка скрытия контрола, настроенного на данную секцию/поле карточки).

  Может иметь одно из следующих значений:

  • Разрешить редактирование - доступ на редактирование секции/полей карточки разрешен, даже если в правиле не установлен флаг доступа “Редактирование карточки”.

  • Запретить редактирование - доступ на редактирование секции/полей карточки запрещен, даже если в правиле установлен флаг доступа “Редактирование карточки”. Для коллекционных секций также запрещает добавление и удаление строк.

  • Запретить редактирование строк (только для коллекционных секций) - доступ на редактирование строк секции запрещен, однако все еще есть возможность добавления и удаления существующих строк секции.

  • Запретить добавление строк (только для коллекционных секций) - доступ на добавление строк секции запрещен, однако все еще есть возможность редактирования и удаления существующих строк секции.

  • Запретить удаление строк (только для коллекционных секций) - доступ на удаление строк секции запрещен, однако все еще есть возможность редактирования и добавления новых строк секции.

    Note

    Важно отметить, что для запрета на редактирование контрола типа “Список” правильно будет использовать запрет редактирования всей секции целиком, т.к. там редактирование идет через Добавление/Удаление строк.

  • Замаскировать данные - доступ на редактирование секции/полей карточки запрещен, даже если в правиле установлен флаг доступа “Редактирование карточки”, а сами данные физически не передаются пользователю в пакете карточки. Строковые данные могут быть заменены на некое значение - маску, отображаемую на клиенте вместо оригинального значения. Однако, стоит учитывать, что пользователь с уровнем доступа “Администратор” будет способен увидеть замаскированные данные (например, при создании копии карточки или в процессе восстановления удаленной карточки).

• Заменить данные на - значение, на которое заменяются замаскированные данные. Поле доступно только при установке в качестве Настройки доступа значения Замаскировать данные.

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

Расширенные настройки прав доступа заданий

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

Проверка правил идет по приоритетам. Настройки правил с более высоким приоритетом могут перекрывать настройки правил с более низким. Это значит, что если у правила доступа с более низким приоритетом запрещено редактирование какого либо поля или секции целиком, а в правиле доступа с более высоким приоритетом это поле или секция разрешены для редактирования, то в итоге данное поле или секция будут доступны для редактирования.

Для правил доступа с одинаковым приоритетом действует следующее правило определения приоритета. Запрет доступа приоритетнее, чем разрешение доступа, однако настройки для конкретных полей приоритетнее, чем настройки для секции целиком. Таким образом можно запретить редактирование всей секции, но выдать доступ на редактирование определенных полей данной секции.

Каждое правило содержит следующие настройки:

• Типы заданий - список типов заданий, для которых применяется данное правило.

• Секция - секция задания, к которой применяется данное правило. Обязательное для заполнения поле. Если задание не использует данную секцию (секция не добавлена в типе задания), то данное правило применяться не будет.

• Поля - набор полей из секции, для которых применяется данное правило. Если не заполнено, то правило применяется ко всей секции.

• Настройка доступа - определяет настройку доступа для секции/полей данного правила. Если не заполнено, то настройка доступа не применяется (но все еще может быть применена настройка скрытия контрола, настроенного на данную секцию/поле карточки).

  Может иметь одно из следующих значений:

  • Разрешить редактирование - доступ на редактирование секции/полей карточки разрешен, даже если в правиле не установлен флаг доступа “Редактирование карточки”.

  • Запретить редактирование - доступ на редактирование секции/полей карточки запрещен, даже если в правиле установлен флаг доступа “Редактирование карточки”. Для коллекционных секций также запрещает добавление и удаление строк.

  • Запретить редактирование строк (только для коллекционных секций) - доступ на редактирование строк секции запрещен, однако все еще есть возможность добавления и удаления существующих строк секции.

  • Запретить добавление строк (только для коллекционных секций) - доступ на добавление строк секции запрещен, однако все еще есть возможность редактирования и удаления существующих строк секции.

  • Запретить удаление строк (только для коллекционных секций) - доступ на удаление строк секции запрещен, однако все еще есть возможность редактирования и добавления новых строк секции.

• Скрыть контрол - флаг определяет, что контролы для данной секции/полей должны быть скрыты при просмотре задания. Физически данные передаются в пакете задания.

Расширенные настройки обязательности полей

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

Каждое правило содержит следующие настройки:

• Секция - секция карточки или задания, к которой применяется данное правило. Обязательное для заполнения поле. Для коллекционной секции, если не заданы Поля, то проверяется наличие строк в данной секции.

• Поля - набор полей из секции, для которых применяется данное правило. Обязательно для заполнения для строковой секции. Для коллекционной секции, если не задано, то проверяется наличие строк в секции.

• Тип проверки обязательности - определяет настройку проверки обязательности секции/полей данного правила. Обязательно для заполнения.

  Может иметь одно из следующих значений:

  • Всегда - проверка обязательности выполняется всегда, когда сохраняется карточки.

  • Когда заполнено одно из полей - проверка обязательности выполняется при сохранении карточки в ситуации, когда хотя бы одно из полей, заданных в правиле, заполнено.

  • При завершении задания - проверка обязательности выполняется, когда завершается задания с заданным вариантом завершения.

• Типы заданий - список типов заданий для которых должна выполняться проверка обязательности при завершении задания. Доступно и обязательно для заполнения при указании типа проверки обязательности При завершении задания.

• Варианты завершения - список вариантов завершения для которых при завершении задания с одним из заданных вариантов должна выполняться проверка обязательности при завершении задания. Если не заполнено, то проверка выполняется при завершении задания с любым вариантом завершения.

• Текст сообщения об ошибке - текст ошибки, который выводится пользователю, когда проверка обязательности не выполнена.

Расширенные настройки видимости

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

Если несколько правил пытаются воздействовать на один и тот же контрол/блок/вкладку, то правило с более высоким приоритетом могут скрыть/показать контролы, блоки или вкладки, которые показывает/скрывает правило с более низким приоритетом.

Для правил с одинаковым приоритетом при воздействии на один и тот же элемент управления поведение не определено.

Каждое правило содержит следующие настройки:

• Тип контрола - определяет тип элемента управления, для которого применяется правило (контрол, блок, вкладка).

• Имя контрола - определят имя элемента управления (алиас), для которого применяется правило. Данное поле поддерживает символ подстановки “*” в начале и в конце. Например, строка “Button**” скрывает/показывает все элементы управления, имя которых содержит слово “Button”.

• Скрыть контрол (если флаг снят, то контрол будет показан) - флаг определяет, должно ли данное правило скрыть элемент управления или показать, если он был скрыт через настройки типа карточки.

Расширенные настройки доступа к файлам

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

Каждое правило содержит следующие настройки:

• Категории файла - список категорий файлов, для которых будет применено данное правило. Если не задано, то данное правило применяется для файлов любой категории.

• Расширение файла - список расширений файлов, записанные через пробел, для которых будет применено данное правило. Если не заполнено, то правило применяется для файлов с любым расширением.

  Tip

  Пример заполнения поля - “txt pdf docx” (без кавычек). Правило будет применено к файлам с расширением txt, pdf и docx.

• Проверять доступ к собственным файлам - если флаг установлен, то доступ будет проверяться ко всем не виртуальным файлам карточки, а если не установлен - то ко всем файлам, создателем которых не является сотрудник, для которого проверяется правило доступа.

• Настройка доступа к файлу - определяет доступ к файлу, для которого применимо данное правило.

  Может иметь одно из следующих значений:

  • Доступна только последняя версий файла - пользователь видит только последнюю версию файла.

  • Доступны только свои версии и последняя версия файла - пользователь видит только те версии, которые добавил он, и последнюю версию файла.

  • Содержимое файла недоступно - пользователь не может просмотреть файл, однако видит атрибуты файла (размер, название, кем создан, категорию). Просмотр истории версий недоступен.

  • Файл недоступен и скрыт - пользователь не видит данный файл в карточке. Информация о файле даже физически не передается пользователю в пакете карточки.

Определение прав доступа при создании карточки

Пользователь, не имеющий прав на создание карточки определенного типа (на момент запуска TessaClient) не увидит элемента панели создания карточки этого типа. Тем не менее, при попытке создания карточки происходит проверка возможности действия – если есть правила доступа, в которых указан пользователь (или роль, в которую он входит) и отмечено право создания карточки типа создаваемой карточки, то пользователь успешно создаст карточку. Если пользователь после запуска клиента успел утратить права на создание карточки такого типа, будет отображено соответствующее сообщение об ошибке:

При расчёте правил доступа к карточке при ее создании фильтрация правил доступа не производится по состояниям и по таблице “Условия”, указанным в настройках правила. Вместо этого выполняются только те правила, в которых установлен флаг “Создание карточки”.

После создания карточки пользователь будет иметь доступ к карточке в соответствии с настройками правил доступа, без учета состояний. Т.е. если есть только одно правило доступа, где стоит только флаг “Создание карточки”, то при создании карточки пользователем - она будет без возможности редактировать поля (и скорее всего без возможности сохранить карточку, т.к. пользователь не сможет заполнить обязательные поля). Поэтому в правиле доступа на создание карточек обычно ставятся еще дополнительные флаги доступа: на редактирование, добавление файлов и т.д.

Note

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

Как было указано выше, при создании карточки не учитываются состояния и условия из правил доступа, однако, не запрещается создавать правила доступа, где стоит флаг “Создание карточки” и при этом указаны состояния и условия. Такое правило можно сделать и оно будет работать - до сохранения карточки без учета состояний и условий, после сохранения - с их учетом. Такие правила доступа настраиваются, как правило, когда нет необходимости разделять уровень прав для создаваемой и сохраненной карточки. Но такое правило доступа категорически не подойдет, например, при таком кейсе: документ могут создавать все пользователи, а редактировать могут только свои карточки - тут понадобится создавать два правила доступа.

После сохранения карточки, права доступа к ней определяются обычным образом, с учетом состояния документа.

Определение прав доступа при чтении карточки

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

1. Если в карточке есть любое задание, доступное пользователю (как исполнителю, автору и т.д.), пользователь может читать карточку, а также имеет права на подписание (с помощью ЭП) приложенных к карточке файлов.

2. Если в карточке есть задание на доработку и текущий пользователь - исполнитель:

   • Если задание не в работе – пользователь может читать карточку.

   • Если задание в работе – пользователь может читать и редактировать карточку, редактировать и добавлять файлы, редактировать маршрут.

3. Если в карточке есть задание согласования или подписания и текущий пользователь – исполнитель:

   • Если задание не в работе – пользователь может читать карточку.

   • Если задание в работе – пользователь может читать карточку и добавлять файлы (и редактировать ранее добавленные им файлы). Также, этапом согласования/подписания могут быть даны права на редактирование карточки и редактирование файлов.

4. Если в карточке есть задание комментирования и текущий пользователь исполнитель – пользователь может читать карточку и добавлять файлы (и редактировать ранее добавленные им файлы).

5. Если карточка находится в состоянии “Проект” - пользователь открывает карточку сразу со всеми правами, которыми он обладает согласно определенным правилам.

6. Если пользователю карточка направлена на ознакомление - пользователь может читать карточку.

7. Если в правиле доступа установлен флаг “Всегда проверять правило доступа”, то все настройки данного правила доступа будут применены при расчёте прав.

8. Во всех иных случаях при чтении карточки проверяется только наличие прав на чтение, и карточка открывается только для чтения.

В случае если карточка открыта не со всеми правами, которые требуются пользователю, пользователь может нажать на кнопку “Редактировать” в левом меню системы:

При нажатии на кнопку “Редактировать” карточка будет открыта со всеми правами, определенными для пользователя. Выход из режима редактирования осуществляется путем обновления карточки с помощью соответствующей кнопки в левом меню системы или нажатием клавиши [F5]. Если при расчёте прав не было получено право на редактирование непосредственно карточки, пользователь увидит информационное сообщение со списком полученных прав:

Если на момент нажатия на кнопку “Редактировать” карточка содержала несохраненные изменения, система предложит на выбор предварительно сохранить изменения, отказаться от изменений или не переходить в режим редактирования (опции “Да”, “Нет”, “Отмена” соответственно):

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

Определение прав доступа при удалении карточки, возврате карточки на доработку, отзыве и отмене процесса

При попытке удаления карточки, возврата карточки на доработку или отзыва/отмены процесса происходит проверка допустимости действия для данного пользователя, если действие допустимо – оно происходит, если нет – пользователь видит ошибку, сообщающую о недостаточных правах для действия.

Права на удаление карточек определяются правилами доступа. Права на возврат карточки на доработку, отзыв и отмену процесса настраиваются в соответствующих вторичных процессах (вкладка Администратор → Маршруты → Вторичные процессы).

Права на просмотр отчетов

В типовом решении предустановлено два вида отчетов (вкладка Пользователь, папка Отчеты): Текущие задания, Завершенные задания.

В зависимости от роли, пользователям доступна следующая информация в отчетах:

• Администратор - отчет по заданиям всех сотрудников и департаментов в системе;

• Руководитель департамента - доступен отчет по заданиям всех сотрудников департамента данного руководителя;

• Сотрудник - доступен отчет только по своим заданиям в системе.

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

Добавить права на просмотр отчётов можно перейдя на рабочее место Администратор, в представление Типовое решение → Права на текущие отчёты:

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

• Тема - описание карточки доступа на отчеты;

• Кто может смотреть - список сотрудников, департаментов или ролей, кто сможет просматривать указанные отчеты;

• Кого можно смотреть - список департаментов или сотрудников, чьи отчеты по заданиям будут доступны указанным сотрудникам/ролям:

Таким образом можно создать нужное количество карточек с правами на просмотр отчетов.

Права к шаблонам карточек

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

На рабочем месте “Пользователь” в представлении “Шаблоны карточек” администраторы видят все шаблоны карточек, независимо от указанных в шаблонах правах. Пользователи видят только те шаблоны, которые им доступны.

Изменить права на шаблон можно выделив нужный шаблон и нажав в левом меню кнопку “Открыть шаблон”:

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

Редактировать шаблонную карточку (по кнопке “Редактировать” на панели инструментов) могут только администраторы системы и сотрудники, указанные в поле “Роли, которые могут редактировать шаблон”.

Права к шаблонам файлов и виртуальным файлам

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

Виртуальный файл - это файл, который формируется по шаблону файла и отображается в карточке документа, однако в карточке не хранится контент данного файла, контент формируется только в момент обращения к файлу.

Шаблоны файлов и виртуальные файлы настраиваются с помощью соответствующих карточек, которые можно найти в представлении “Администратор → Прочее → Шаблоны файлов” или “Администратор → Типовое решение → Виртуальные файлы”. Открыв карточку можно настроить доступ (видимость) данной функции:

• Для шаблона файла указывается каким ролям и для каких типов документов/представлений будет доступно формирование файла по данному шаблону.

  

• Для виртуальных файлов указываются следующие настройки видимости:

  

  • Типы - типы документов, в которых будет отображаться данный виртуальный файл,

  • Состояния карточек - состояния документов, в которых будет отображаться данный виртуальный файл,

  • Роли - сотрудникам, входящим в указанные роли при открытии документа указанного типа в указанном состоянии будет отображаться данный виртуальный файл,

  • Список условий - дополнительный список условий видимости виртуального файла. Например, можно указать видимость в зависимости от контрагента, таким образом настроив разный формат виртуального файла в зависимости от контрагента. Помимо списка доступных типов условий, можно создавать свои условия. Подробней об условиях см. в разделе Типы условий.

    Note

    Для виртуального файла “Лист согласования” по умолчанию выставлено условие “Видимость листа согласования”, которое проверяет, есть ли в истории заданий карточки какие-либо записи, которые необходимо отобразить в листе согласования.

Права на запуск маршрутов

Запуск маршрутов, настроенных на подсистеме маршрутов выполняется с помощью кнопок вторичных процессов. Такие операции, как запуск основного процесса, отзыв, регистрация документов и т.д., выполняемые нажатием кнопки в левом меню карточки документа, реализованы с помощью кнопок вторичных процессов подсистемы маршрутов. Список всех вторичных процессов, входящих в типовую поставку TESSA можно найти в разделе Карточки маршрутов, входящие в типовую конфигурацию. Также с помощью вторичных процессов могут быть реализованы любые процессы, которые будут манипулировать данными текущей карточки (например, менять состояние карточки), запускать новые процессы, отправлять задания и так далее.

Карточки вторичных процессов можно найти в представлении “Администратор → Маршруты → Вторичные процессы”. Открыв карточку нужного процесса, можно указать следующие права:

• Сообщение при недоступности выполнения - текст сообщения, которое будет выводиться пользователю в случае, если кнопка вторичного процесса пользователю в карточке видна, но по каким-то условиям не должна быть доступна для нажатия.

• Типы - типы документов, в которых будет доступна кнопка для запуска вторичного процесса. Если поле не заполнено - доступно будет во всех типах документов (с учетом остальных ограничений).

  Note

  Если в карточке выставлен флаг “Глобальный” (т.е. кнопка будет отображаться не в левом меню карточки, а в правом меню системы), то поле “Типы” не учитывается.

• Роли - роли, кому кнопка данного вторичного процесса будет видна. Доступны все типы ролей, кроме контекстных. Если поле не заполнено, то кнопку будут видеть все пользователи.

• Состояния карточек - состояния карточек, в которых кнопка будет доступна для указанных типов документов и ролей.

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

• Дополнительные настройки видимости - дополнительные условия, реализованные путем написания C# скриптов, которые ограничивают видимость кнопки.

Права на редактирование маршрутов

Права на редактирование маршрутов, настроенных на подсистеме маршрутов, настраиваются в следующих местах (в каждом из описанных ниже пунктов должны выполняться все подпункты):

• Для предоставления возможности пользователю добавления в маршрут новых этапов необходимо:

  • Настроить список доступных групп этапов и типов этапов: правое меню → Настройки → Типовое решение → вкладка “Дополнительно” → таблица “Настройки этапов маршрута”:

    

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

    Note

    Не надо в данной таблице указывать служебные типы этапов, такие как Сценарий, Управление процессом и т.д. Обычно пользователям (в зависимости от требований проектного решения) дают права на добавление этапов Согласование, Подписание, Задача, Ознакомление, Уведомление. Иногда дают пользователям права также на добавление этапа Регистрация.

  • С помощью правил доступа выдать права на редактирование маршрута.

• Для возможности редактирования или перемещения этапов, автоматически добавленных в маршрут необходимо:

  • В соответствующих шаблонах этапов выставить необходимые настройки флагов “Этапы нередактируемые”, “Можно перемещать”.

  • Убедиться, что в группе этапов не выставлен флаг “Все этапы нередактируемые”.

  • С помощью правил доступа выдать права на редактирование маршрута.

• Для возможности удаления (пропуска) этапов, автоматически добавленных в маршрут:

  • В соответствующем этапе выставить флаг “Разрешён пропуск”.

  • С помощью правил доступа выдать права на пропуск этапов.

• Для возможности пересчёта маршрута:

  • С помощью правил доступа выдать права на пересчёт маршрута.

Права на запуск процессов (конструктор бизнес-процессов)

Запуск процессов, разработанных с помощью конструктора бизнес-процессов выполняется с помощью кнопок, настроенных в карточке шаблона бизнес-процесса. Список карточек шаблонов бизнес-процессов можно посмотреть в представлении Администратор → Процессы → Шаблоны процессов:

Открыв нужную карточку можно настроить доступ для запуска бизнес-процесса:

• Типы карточек - типы карточек, из которых будет доступен запуск процесса (при этом должен быть выставлен флаг “Запуск из карточки”).

• Расширения проверки доступа для кнопок (плиток) - можно подключить дополнительные расширения проверки доступа:

  • Проверка состояния - включить проверку видимости кнопок бизнес-процесса в зависимости от состояния карточки (в настройках кнопок бизнес-процесса появится соответствующее поле);

  • Проверка ролей на выполнение - включить проверку ролей при нажатии кнопок бизнес-процесса (в настройках кнопок бизнес-процесса появится соответствующее поле).

• Кнопки бизнес-процесса:

  

  • Роли (проверяются при нажатии) - список ролей, кому доступно нажатие кнопки;

  • Доступно ролям - список ролей, которым будет видна данная кнопка;

  • Состояния - список состояний карточки, в которых будет видна данная кнопка;

  • Дополнительное условие - C# скрипт с дополнительными проверками видимости кнопки.

Список доступных авторов задач

В TESSA есть возможность отправки типовых задач от имени другого пользователя.

Что такое типовые задачи и как они работают, описано в Руководстве пользователя.

В зависимости от того, используются ли для типа карточки типы документов, открыв карточку настроек типового решения (правое меню → Настройки → Типовое решение) или карточку типа документа (вкладка Администратор → Типовое решение → Типы документов) можно включить возможность использовать типовой процесс отправки задач:

Список доступных авторов, от имени которых пользователь может отправлять типовые задачи, управляется представлением WfResolutionAuthors. Представление выводит список доступных авторов, согласно настройкам, которые указаны в карточке настроек типового решения (правое меню → Настройки → Настройки типового решения) на вкладке “Дополнительно”:

Из примера (см. изображение) видно, что задачи от имени “Васильева В.В.” могут отправлять сотрудники “Петров П.П.” и “Соколов С.И.”. Так же подобные настройки справедливы не только для персональных ролей, но и для подразделений, а так же любых других ролей, кроме контекстных. Подобная настройка указана во второй строке, которая позволяет любому сотруднику, входящему в подразделение “Бухгалтерия”, отправлять задания от имени пользователей “Бодров М.” и “Тихонов Т.Т.”.

На изображении ниже приведён пример того, как пользователь “Петров П.П.”, при отправке от имени, может выбрать только пользователя “Васильев В.В.”. Это продиктовано настройками, указанными в примере выше.

Права на редактирование замещений других сотрудников

Любой пользователь TESSA может настраивать сам себе замещения или выдать права другим сотрудникам на редактирование своих замещений. Администраторы системы могут выполнять аналогичные операции для любых сотрудников.

Для предоставления прав сотруднику на редактирование замещений другого сотрудника, необходимо найти и открыть карточку сотрудника, права на настройку чьих замещений мы хотим выдать. Далее перейти на вкладку “Мои замещения” и в соответствующем поле указать, кто может редактировать замещения:

На рисунке выше Петрову П.П. предоставлены права на редактирование замещений Иванова И.И.

Сотрудник, кому выдали права на редактирование замещений, в представлении “Замещения”, расположенном на рабочем месте “Пользователь”, сможет открыть и отредактировать замещения доступного сотрудника:

Как добавить заместителей описано в разделе Замещения текущего руководства, а также в Руководстве пользователя.

Права к рабочим местам и представлениям

Настроить доступ к рабочим местам и представлениям можно двумя способами:

• В TessaClient: Администратор → Прочее → Рабочие места/Представления:

  

  Открыв карточку нужного представления или рабочего места, можно указать роли, кому будет доступно представление/рабочее место, для выбора доступны все типы ролей, кроме контекстных:

  

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

• В TessaAdmin в разделе Рабочие места/Представления, на вкладке “Роли”.

  Note

  Приложение TessaAdmin доступно только тем администраторам, которые входят в указанные в карточке приложения (TessaClient → Администратор → Прочее → Приложения → TessaAdmin) роли, или всем администраторам, если доступ к приложению никак не ограничен (подробней см. раздел Права к приложениям и web-клиенту).

  

  Для добавления прав необходимо выбрать нужное рабочее место, указать роль и нажать на кнопку “Добавить”:

  

  Далее необходимо сохранить изменения:

  

  Для удаления ненужной роли необходимо просто щелкнуть левой кнопкой мыши на иконку роли:

  

  И далее не забыть сохранить внесённые изменения.

При настройке прав к узлам рабочего места стоит учитывать, что данные настройки выполняются в разделе “Представления”, а не в разделе “Рабочие места”. Например, необходимо выдать Иванову И.И. права на реестр входящих документов, расположенный на рабочем месте “Пользователь”:

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

Для выдачи прав доступа только на конкретный узел необходимо посмотреть, какое представление отображает данный узел:

Далее перейти в раздел “Представления”, найти нужное нам, перейти во вкладку “Роли” и настроить необходимые права:

И далее сохранить внесенные изменения, нажав на кнопку “Сохранить всё” на панели инструментов.

Note

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

Примеры

Примеры расчёта прав доступа на карточку

Пример 1 – чтение карточки

Карточка типа “Документ” создана и находится в состоянии “Проект”.

В карточке правил доступа “Правило 1” в типах указан “Документ”, в состояниях указан “Проект” и др., в ролях указан “Пользователь 1”, отмечено право на чтение карточки.

В карточке правил доступа “Правило 2” в типах указан “Документ”, в ролях указана роль “Отдел 1”, в которую входит пользователь, отмечено право на редактирование карточки.

В карточке правил доступа “Правило 3” в типах указан “Документ”, в ролях указана роль “Сотрудник отдела создателя карточки”, отмечено право на редактирование маршрута.

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

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

Далее будут выбраны контекстные роли для типа “Документ” и состояния “Проект” и соответствующие им наборы разрешений. Если “Пользователь 1” входит в роль “Сотрудник отдела создателя карточки”, то он получит право на редактирование маршрута.

Пример 2 – создание карточки

Пользователь “Пользователь 1” пытается создать карточку типа “Договор”

Определено правило доступа “Правило 1” для типа “Договор”, роли “Отдел 1” и “Отдел 2”, отмечено право на создание и редактирование карточки.

При попытке создания карточки “Договор” будет проверено наличие правил, в которых указан тип “Договор”, отмечено право на создание карточки и указаны роли, в которые входит пользователь. Т.к. карточка еще не создана – у нее нет состояния, поэтому правила будут выбираться без фильтрации по состоянию. Также будут игнорироваться контекстные роли, т.к. для несуществующей карточки невозможно определить содержание контекстной роли. Если такие правила существуют – пользователь сможет создать карточку. Таким образом, если пользователь входит в роль “Отдел 1” или в “Отдел 2”, он успешно создаст карточку и получит доступ к ней в соответствии с настройками правил доступа, а после первого сохранения доступ к карточке будет определяться стандартным для открытия карточки образом.

Пример 3 – чтение карточки, отмена согласования, удаление карточки

Пользователь “Пользователь 1” открывает карточку типа “Входящий” в состоянии “На согласовании”, которая была им создана ранее.

Определено правило доступа “Правило 1” для типа “Входящий”, состояния “Отмена”, для контекстной роли “Создатель карточки” и отмечено право удаления карточки.

В карточке вторичного процесса “Отменить процесс” не указаны типы (т.е. кнопка будет доступна для всех типов карточек), указана роль “Отдел 1”, в которую входит пользователь, состояние - “На согласовании”.

Карточка содержит не взятое в работу задание комментирования для роли “Все сотрудники”, в которую входит “Пользователь 1”.

Система дает пользователю “Пользователь 1” доступ на чтение карточки, т.к. есть задание комментирование для “Все сотрудники” и “Пользователь 1” является исполнителем задания, хотя оно еще не взято в работу.

“Пользователь 1” может отменить процесс согласования, и отмена пройдет успешно согласно настройкам карточки вторичного процесса, который отвечает за отмену процесса.

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