Дизайн керування ролями чиновників для задач бізнес-процесів

Даний дизайн описує принципи за якими працює система в контексті розподілення задач між чиновниками та деталі авторизації на рівні Camunda.

Життєвий цикл задачі

Користувацька задача може знаходитись в одному з наведених станів:

task lifecycle

  • NEW - новостворені задачі знаходяться у стані "нова"

  • UNASSIGNED - задачі без призначеного уповноваженого. Задачі, які були змодельовані з використанням атрибутів CandidateUsers, CandidateGroups також знаходяться в цьому стані

  • ASSIGNED - задачі з призначеним уповноваженим. Уповноважений для задачі може бути назначений при моделюванні бізнес-процесу у полі assignee, при ручному назначенні через business-process-admin-portal, або якщо чиновник сам візьме задачу у виконання

  • COMPLETED - при завершенні задачі вона переходить у стан виконана

Сценарії призначення уповноваженого для задачі

Існує декілька засобів призначити уповноваженого для викоанння користувацької задачі:

  • Призначення уповноваженого при моделюванні бізнес-процесу

    • Використання системної змінної initiator для поля assignee. В такому сценарії задача автоматично буде призначена на людину, яка ініціювала бізнес-процес. Підходить для Використання в невеликих бізнес-процесах, які виконує одна людина.

    • Використання конкретного уповноваженого для виконання задачі при моделюванні. В такому разі задача буде завжди призначенв на одну і туж людину (не рекомендується)

  • Призначення потенційних виконавцив задачі

    • Використання атрибуту Candidate Users при моделюванні бізнес-процесу. В такому разі задача буде доступна для взяття у виконання усім користувачам, які були вказані в атрибуті Після того, як один з кандидатів візьме задачу у виконання, вона стає недоступною для інших користувачів у списку

    • Використання атрибуту Candidate Groups при моделюванні бізнес-процесу. Усі користувачі, які мають одну з вказаних в атрибуту ролей, можуть взяти задачу у виконання. Після того, як один з кандидатів візьме задачу у виконання, вона стає недоступною для інших користувачів з вказаними ролями

  • Призначення уповноваженого на виконання задачі адміністратором бізнес-процесів. Первинне признечення уповноваженого або його зміна (у разі відпустки, хвороби або звільнення) може бути виконано через Адмін інтерфейс (business-process-admin-portal) адміністратором бізнес-процесів

Авторизація для користувацьких задач

Схема авторизаціних об’єктів у Camunda engine має наступний вигляд

task auth

При досягненні користувацької задачі створються набір авторизаційних правил:

  • Task authorization: READ, UPDATE - надає права на перегляд та оновлення задачі (виконання, взяття у виконання (claim))

  • History task authorization: READ - надає права на перегляд задачі після її викоання

За замовчуванням наведені привілеї надаються корустувачу якщо він:

  • Є assignee у задачі. Якщо він був вказан assignee безпосередньо при моделюванні, або якщо він був призначений адміністратом бізнес процесів через Адмін інтерфейс

  • Є в переліку Candidate Users

  • Має роль з переліку Candidate Groups

За замовчуванням Camunda Engine не видаляє авторизаційні права при зміні уповноваженого. Тобто якщо чиновник Петро та Павло булт вказані як потенційні виконанвці задачі, вони обидва будуть її бачити, та зможуть взяти у виконання. Після того, як Петро візьме задачу у викоання, Павло все ще зможе переглядати та навіть виконувати задачу. Для запобігання такої поведінки додаткова логіка по перевірки assignee задачі повинна бути виконана заздалегідь.

Окрім цього, роль користувача який працює з задачею повинна мати права для роботи з описом послуги (process definition) для можливості отримання імені цієї послуги для задачі.

Виконавець задачі може, але не повинен мати доступ до бізнес процесу в рамках якого виконується задача.

Користувацькі сценарії по роботі з задачами

task use case

Для чиновника задача може знаходитись в одному з 3 станів:

  • Призначена на виконання на нього. У цьмоу разі користувач має можлівість

    • Зчитати інформацію про задачу

    • Виконати задачу

    • Знятися з виконання задачі. В такому разі задача переходить в стан unassigned та стає досупнв для усіх потенційних виконавців

  • Користувач є потенційним виконавцем задачі. Якщо користувач є у переліку Candidate Users або має роль з переліку Candidate Groups. Можливі дії:

    • Зчитати інформацію про задачу

    • Взяти задачу у виконання

  • Задачі, до яких користувач не має доступу:

    • Задачі, у яких користувач є потенційним виконавцем, але вони були призначені на іншу людіну

    • Усі інші задачі