Важное отличие приложений СЭД от других привычных пользователю приложений (например, ERP-систем) в том, что документ СЭД – это объект с очень сложным и длительным жизненным циклом. Например, документ вида Договор — разрабатывается, согласовывается, утверждается, передается контрагентам, по нему ведется активная работа, к нему накапливаются приложения, создаются дополнительные артефакты, он архивируется, списывается и пр. Естественно, логика его обработки и права доступа к данным документа зависят от этапа его обработки. Но это еще не самое сложное.
Дело в том, что правила обработки документа на конкретном этапе жизненного цикла конкретным пользователем зависят от самых разных параметров: например, от положения пользователя в штатном расписании, наличия тех или иных данных в самом документе (или связанных с ним), и даже информации, хранящейся во внешних по отношению к СЭД системах.
Вот пример такого сложного правила, определяющего право вносить изменение в содержимое договора:
Все бы ничего, но при создании приложения в СЭД, как правило, не удается описать задачу в общем, и при каждом конкретном внедрении необходимо учитывать правила работы и регламенты конкретного бизнес-процесса в конкретной организации. Все это приводит к необходимости использования кодирования и низкоуровневой разработки почти в каждом проекте внедрения СЭД. А любые программные доработки — это не только удорожание проекта, но и увеличение рисков и потенциальных проблем при осуществлении перехода на новые версии платформы СЭД.
Для устранения этих проблем при внедрении приложений СЭД в Docsvision реализована уникальная контекстно-ролевая модель, которая позволяет параметрически настраивать интерфейс, логику обработки и безопасность документа для конкретного сценария использования без использования программирования. Для этого используется конструктор ролей Docsvision.
Нужно сказать, что традиционное понятие «роли» — например, роль в операционной системе и роль в контекстно-ролевой модели — отличается. Если традиционная роль (например, администратор системы) – это по сути статическая группа, членам которой предоставлены определенные специфические полномочия в системе (возможность выполнять функции администрирования), то в Docsvision роль определяется динамически, в частности, по отношению к конкретному экземпляру документа, и не только, определяются права доступа к объекту, интерфейс для обработки объекта и доступные бизнес-функции для его обработки.
Таким образом, механизм контекстно-ролевой модели Docsvision позволяет решать одну из важнейших проблем современной СЭД – оптимизацию и облегчение интерфейса пользователя при выполнении тех или иных действий.
Настройка ролевой модели включает в себя три шага:
• Настройка ролей (или контекстов обработки) для конкретного типа и вида документа,
• Определение операций обработки документа и данных доступных для данной роли,
• Связывание того или иного интерфейсного представления, настроенного в конструкторе карточек с конкретной ролью и состоянием документа.
(О конструкторе карточек и состояний Docsvision смотри тут habrahabr.ru/company/docsvision/blog/263263).
Настройка ролей для вида документа производится в интерфейсе «конструктора ролей»
Рисунок 1. Конструктор ролей позволяет параметрически описывать контексты использования тех или иных объектов приложения на базе платформы Docsvision.
Конструктор ролей позволяет описать множество ролей (контекстов использования) для того или иного вида документа.
Каждая роль – это набор условий, объединённых в комбинации по и/или.
Каждое условие — это логическое выражение (параметр–операция–значение), которое проверяется на истинность, при обращении к конкретному экземпляру документа.
Производится проверка актуальности всех ролей для текущего контекста (пользователь — экземпляр документа), настроенного для данного вида документа. В случае если все (И) или одно (ИЛИ) выражение истинно, данная роль актуализируется в текущем контексте. Далее, в зависимости от настроек конструктора карточек, определяется, какой интерфейс необходимо показать пользователю в текущем контексте, а также какие данные и операции документа доступны пользователю в текущем контексте.
В таблице представлен список параметров, определяющих текущий контекст использования.
По сути дела, сегодня в системе существуют 3 типа параметров:
• Параметры, которые определяют контекст текущего пользователя. Самый простой пример – я = значение поля документа, текущий пользователь указан в каком-то поле документа. Существуют и более сложные условия, например, текущий пользователь – временный заместитель пользователя, указанного в поле карточки. Можно также в качестве значения выбирать не поле текущего документа, а поле документа (или другого объекта), связанного с текущим. Например, можно проверить условие: я являюсь временным заместителем пользователя, указанного в поле исполнитель задания, назначенного на данный документ.
• Параметры, связанные со временем. Условия можно связывать с текущей датой и с текущим временем, например, проверить, рабочее ли сейчас время, и запретить доступ к документу вне рабочего времени, или ограничить доступность документа календарным годом.
• Параметры, связанные с данными текущего документа. При открытии документа можно проверить, соответствует ли значение поля документа или связанного с ним объекта определенным условиям. Например, в зависимости от суммы договора можно дать права на его редактирование только пользователям определенной группы.
Как и при создании любого визуального конструктора, мы столкнулись с тем, что всех ситуаций из реальной жизни предусмотреть не получается. Поэтому дали возможность создать произвольное условие, подключив в качестве условия низкоуровневый код. Использовать этот механизм мы рекомендуем только опытным разработчикам, так как выполнение операций расчета ролевой модели может очень существенно повлиять на скорость работы решения. Особенно это касается расчета прав доступа к документам при выводе табличных представлений с большим количеством документов, например, журнала входящих документов за текущий год.
Второй этап настройки контекстно-ролевой модели заключается в определении доступности тех или иных данных или операций для настроенных ролей.
Рисунок 2. Конструктор ролей позволяет предоставить права выполнения тех или иных операций и редактирования данных для различных ролей.
При этом одна роль может иметь различные права на выполнение операций с документом в различных его состояниях. Так, например, в примере на рис. 2. операция «Вернуть на подготовку» для входящего документа доступна регистратору в состоянии «Зарегистрирован» и недоступна в состоянии «Подготовка» и «В архиве».
Настройки безопасности ролевой модели работают на базе сервера приложений Docsvision. Если операция или данные закрыты в настройках контекстно-ролевой модели, то они недоступны не только из интерфейса приложений, но и на низком уровне, при доступе через API.
Последний этап настроек заключается в связывании конкретного интерфейса документа, настроенного в конструкторе карточек, с ролью для определенного состояния обработки документа. Делается это в дереве дизайнов конструктора карточек.
Рисунок 3. Конструктор карточек позволяет связать тот или иной интерфейс документа с состоянием и ролью с помощью «дерева дизайнов».
Описанный механизм ролевой модели позволил нам решить проблему простой настройки разрабатываемых на базе Docsvision приложений к условиям конкретной организации без существенных программных доработок.
В следующем эпизоде этой серии статей я напишу о разработке справочников в СЭД, а затем о разработке бизнес-процессов, подсистеме навигации и поиска, подсистеме представлений и отчётов.
Дело в том, что правила обработки документа на конкретном этапе жизненного цикла конкретным пользователем зависят от самых разных параметров: например, от положения пользователя в штатном расписании, наличия тех или иных данных в самом документе (или связанных с ним), и даже информации, хранящейся во внешних по отношению к СЭД системах.
Вот пример такого сложного правила, определяющего право вносить изменение в содержимое договора:
«договор доступен для редактирования руководителю отдела и его заместителям, а также всем сотрудникам, которые перечислены в списке согласующих лиц в карточке договора, в том случае если задание на согласование документа находится в состоянии «в работе», «документ не утвержден», и в учетной системе нет записи о регистрации соответствующего договора».Для операций работы с документом может быть описано большое количество подобных правил. Это приводит к тому, что при создании приложения приходится программировать логику обработки документа, учитывая все эти факторы – этап обработки, состояние документа, роль пользователя, атрибуты документа и связанных с ним, внешние факторы и пр., которые определяют правила обработки документов, доступность тех или иных элементов интерфейса, возможность чтения и модификации данных.
Все бы ничего, но при создании приложения в СЭД, как правило, не удается описать задачу в общем, и при каждом конкретном внедрении необходимо учитывать правила работы и регламенты конкретного бизнес-процесса в конкретной организации. Все это приводит к необходимости использования кодирования и низкоуровневой разработки почти в каждом проекте внедрения СЭД. А любые программные доработки — это не только удорожание проекта, но и увеличение рисков и потенциальных проблем при осуществлении перехода на новые версии платформы СЭД.
Для устранения этих проблем при внедрении приложений СЭД в Docsvision реализована уникальная контекстно-ролевая модель, которая позволяет параметрически настраивать интерфейс, логику обработки и безопасность документа для конкретного сценария использования без использования программирования. Для этого используется конструктор ролей Docsvision.
Нужно сказать, что традиционное понятие «роли» — например, роль в операционной системе и роль в контекстно-ролевой модели — отличается. Если традиционная роль (например, администратор системы) – это по сути статическая группа, членам которой предоставлены определенные специфические полномочия в системе (возможность выполнять функции администрирования), то в Docsvision роль определяется динамически, в частности, по отношению к конкретному экземпляру документа, и не только, определяются права доступа к объекту, интерфейс для обработки объекта и доступные бизнес-функции для его обработки.
Таким образом, механизм контекстно-ролевой модели Docsvision позволяет решать одну из важнейших проблем современной СЭД – оптимизацию и облегчение интерфейса пользователя при выполнении тех или иных действий.
Настройка ролевой модели включает в себя три шага:
• Настройка ролей (или контекстов обработки) для конкретного типа и вида документа,
• Определение операций обработки документа и данных доступных для данной роли,
• Связывание того или иного интерфейсного представления, настроенного в конструкторе карточек с конкретной ролью и состоянием документа.
(О конструкторе карточек и состояний Docsvision смотри тут habrahabr.ru/company/docsvision/blog/263263).
Настройка ролей для вида документа производится в интерфейсе «конструктора ролей»
Рисунок 1. Конструктор ролей позволяет параметрически описывать контексты использования тех или иных объектов приложения на базе платформы Docsvision.
Настройка ролей (или контекстов обработки) для конкретного типа и вида документа
Конструктор ролей позволяет описать множество ролей (контекстов использования) для того или иного вида документа.
Каждая роль – это набор условий, объединённых в комбинации по и/или.
Каждое условие — это логическое выражение (параметр–операция–значение), которое проверяется на истинность, при обращении к конкретному экземпляру документа.
Производится проверка актуальности всех ролей для текущего контекста (пользователь — экземпляр документа), настроенного для данного вида документа. В случае если все (И) или одно (ИЛИ) выражение истинно, данная роль актуализируется в текущем контексте. Далее, в зависимости от настроек конструктора карточек, определяется, какой интерфейс необходимо показать пользователю в текущем контексте, а также какие данные и операции документа доступны пользователю в текущем контексте.
В таблице представлен список параметров, определяющих текущий контекст использования.
| Параметр | Описание |
| Все | Условие задается относительно всех пользователей |
| Я | Условие задается относительно текущего пользователя |
| Руководитель | Условие задается относительно руководителя текущего пользователя |
| Подчиненные | Условие задается относительно подчиненных первого уровня текущего пользователя |
| Все подчиненные | Условие задается относительно всех подчиненных текущего пользователя |
| Все подчиненные временно замещаемого | Условие задается относительно заместителя временно замещаемого руководителя текущего пользователя |
| Все подчиненные постоянно замещаемого | Условие задается относительно заместителя постоянно замещаемого руководителя текущего пользователя |
| Заместитель | Условие задается относительно заместителя текущего пользователя |
| Замещаемый | Условие задается относительно лица, заместителем которого является текущий пользователь |
| Я — первый активный заместитель | Условие задается относительно первого активного заместителя текущего пользователя. Первым заместителем считается сотрудник, который первым указан в списке заместителей в Справочнике сотрудников. У данного сотрудника должно быть состояние «Активен» |
| Я — первый активный постоянный заместитель | Условие задается относительно первого активного заместителя текущего пользователя. Данный заместитель считается постоянным на основании установленного параметра Постоянный заместитель в Справочнике сотрудников. У данного сотрудника должно быть состояние «Активен» |
| Я — первый активный временный заместитель | Условие задается относительно первого активного заместителя текущего пользователя. Данный заместитель считается временным на основании того, что для него не установлен параметр Постоянный заместитель в Справочнике сотрудников. У данного сотрудника должно быть состояние «Активен» |
| Я — первый активный заместитель исполнения | Условие задается относительно первого активного заместителя текущего пользователя. Данный статус настраивается в Справочнике сотрудников. |
| Я — первый активный заместитель ответственного исполнения | Условие задается относительно первого активного заместителя исполнителя текущего пользователя, причём для заместителя установлена настройка «Ответственное исполнение». Данный статус настраивается в Справочнике сотрудников. |
| Я — первый активный заместитель подписи | Условие задается относительно первого активного заместителя текущего пользователя по подписи. Данный статус настраивается в Справочнике сотрудников. |
| Я — временный заместитель в период неактивности замещаемого | Условие задается относительно первого активного временного заместителя, но только в случае, когда замещаемый сотрудник находится в состоянии, отличном от «Активен». Данный заместитель считается временным на основании того, что для него не установлен параметр Постоянный заместитель в Справочнике сотрудников. У данного сотрудника должно быть состояние «Активен» |
| Я — постоянный заместитель | Условие задается относительно постоянного заместителя вне зависимости от активности заместителя и самого замещаемого. Данный заместитель считается постоянным на основании установленного параметра Постоянный заместитель в Справочнике сотрудников |
| Я — заместитель подписи | Условие задается относительно заместителя текущего пользователя по праву подписи документа |
| Сегодня | Условие задается относительно текущей даты (без учета бизнес-календаря) |
| Сейчас | Условие задается относительно текущего момента времени (без учета бизнес-календаря) |
| Поле | Условие задается относительно некоторого поля карточки |
По сути дела, сегодня в системе существуют 3 типа параметров:
• Параметры, которые определяют контекст текущего пользователя. Самый простой пример – я = значение поля документа, текущий пользователь указан в каком-то поле документа. Существуют и более сложные условия, например, текущий пользователь – временный заместитель пользователя, указанного в поле карточки. Можно также в качестве значения выбирать не поле текущего документа, а поле документа (или другого объекта), связанного с текущим. Например, можно проверить условие: я являюсь временным заместителем пользователя, указанного в поле исполнитель задания, назначенного на данный документ.
• Параметры, связанные со временем. Условия можно связывать с текущей датой и с текущим временем, например, проверить, рабочее ли сейчас время, и запретить доступ к документу вне рабочего времени, или ограничить доступность документа календарным годом.
• Параметры, связанные с данными текущего документа. При открытии документа можно проверить, соответствует ли значение поля документа или связанного с ним объекта определенным условиям. Например, в зависимости от суммы договора можно дать права на его редактирование только пользователям определенной группы.
Как и при создании любого визуального конструктора, мы столкнулись с тем, что всех ситуаций из реальной жизни предусмотреть не получается. Поэтому дали возможность создать произвольное условие, подключив в качестве условия низкоуровневый код. Использовать этот механизм мы рекомендуем только опытным разработчикам, так как выполнение операций расчета ролевой модели может очень существенно повлиять на скорость работы решения. Особенно это касается расчета прав доступа к документам при выводе табличных представлений с большим количеством документов, например, журнала входящих документов за текущий год.
Определение операций обработки документа и данных, доступных для данной роли
Второй этап настройки контекстно-ролевой модели заключается в определении доступности тех или иных данных или операций для настроенных ролей.
Рисунок 2. Конструктор ролей позволяет предоставить права выполнения тех или иных операций и редактирования данных для различных ролей.
При этом одна роль может иметь различные права на выполнение операций с документом в различных его состояниях. Так, например, в примере на рис. 2. операция «Вернуть на подготовку» для входящего документа доступна регистратору в состоянии «Зарегистрирован» и недоступна в состоянии «Подготовка» и «В архиве».
Настройки безопасности ролевой модели работают на базе сервера приложений Docsvision. Если операция или данные закрыты в настройках контекстно-ролевой модели, то они недоступны не только из интерфейса приложений, но и на низком уровне, при доступе через API.
Связывание того или иного интерфейсного представления, настроенного в конструкторе карточек с конкретной ролью и состоянием документа
Последний этап настроек заключается в связывании конкретного интерфейса документа, настроенного в конструкторе карточек, с ролью для определенного состояния обработки документа. Делается это в дереве дизайнов конструктора карточек.
Рисунок 3. Конструктор карточек позволяет связать тот или иной интерфейс документа с состоянием и ролью с помощью «дерева дизайнов».
Описанный механизм ролевой модели позволил нам решить проблему простой настройки разрабатываемых на базе Docsvision приложений к условиям конкретной организации без существенных программных доработок.
В следующем эпизоде этой серии статей я напишу о разработке справочников в СЭД, а затем о разработке бизнес-процессов, подсистеме навигации и поиска, подсистеме представлений и отчётов.