Категоризація доступних послуг в кабінеті користувача

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Загальний опис

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

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

2. Актори та ролі користувачів

  • Отримувачі послуг

  • Посадові особи

  • Розробник регламенту

3. Загальні принципи та положення

  • Бізнес-процес не може бути прив’язаний до двох чи більше груп.

  • Група не є обов’язковою. Бізнес-процеси не прив’язані до групи відображаються поза групою. При відсутності налаштувань груп, вважається, що жоден бізнес-процес не прив’язаний до групи.

  • Групи в яких нема жодного бізнес-процесу доступного користувачу не відображаються в кабінеті користувача. В інтерфейсі адміністративного порталу відображаються всі групи.

  • Вкладеність груп не підтримується.

  • Реалізація інтернаціоналізації для назв груп поза межами цього документу.

4. Функціональні сценарії

  • Налаштування групування та сортування бізнес-процесів розробником регламенту через вебінтерфейс адміністративного порталу.

  • Валідація змін до налаштувань групування та сортування бізнес-процесів при публікації регламенту.

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

5. Дизайн управління налаштуваннями

bp-groups-configuration

Для збереження налаштувань групування та сортування, створюється новий елемент регламенту реєстру - файл налаштувань bp-grouping.yaml, який зберігається у папці bp-grouping

Файл налаштувань має наступну структуру:

Ім’я Тип Опис

groups

[]object

Список груп

groups[index]

object

Група

groups[index].name

string

Ім’я групи

groups[index].processDefinitions

[]string

Бізнес-процеси в групі

groups[index].processDefinitions[index]

string

processDefinitionId бізнес-процесу

ungrouped

[]string

Бізнес-процеси поза групами

ungrouped[index]

string

processDefinitionId бізнес-процесу
Порядок відображення груп та бізнес-процесів на інтерфейсі користувача визначається порядком у файлі налаштувань.

Адміністратор реєстру створює або редагує налаштування через вебінтерфейс адміністративного порталу, або вручну міняє файл налаштувань. В результаті чого налаштування потрапляють в регламент реєстру.

При публікації регламенту реєстру, пайплайн публікації регламенту пропагує налаштування у сервіс управління бізнес-процесами користувача.

На основі налаштувань, сервіс управління бізнес-процесами користувача повертає згруповані та впорядковані послуги доступні користувачу у своїй відповіді.

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

5.1. Адміністративний портал

5.1.1. Відображення в кабінетах

До вебінтерфейсу адміністративного порталу має бути доданий розділ Відображення в кабінетах, відповідно до узгодженого макета. Цей розділ має надавати можливість:

  • переглядати бізнес-процеси у групах

  • створювати групу

  • змінювати ім’я групи

  • видаляти групу

  • додавати бізнес-процеси у групу

  • видаляти бізнес-процеси із групи

  • змінювати порядок відображення груп

  • змінювати порядок відображення бізнес-процесі у групах та поза групами

При видаленні групи видаляється тільки група. Бізнес-процеси, які були до неї прив’язані, переходять в категорію не згрупованих.

5.1.2. Огляд версії

Розділ Внесені зміни на сторінці Огляд версії має бути доповнений можливістю відображення статусу змін файлу bp-grouping.yaml, так само як це зроблено для файлів форм та бізнес-процесів.

5.1.3. REST API

API сервісу надання конфігурації регламенту реєстру має бути доповнений методами які забезпечують функціональність вебінтерфейс.

OpenAPI Specification (Завантажити)

Для забезпечення зворотної сумісності з наявними регламентами реєстрів, та спрощення логіки роботи с файлом налаштувань, обробка запитів має відбуватися з урахуванням наступних правил:

  • При формуванні відповіді:

    • Групи та бізнес-процеси у відповіді мають бути впорядковані так само як і у файлі налаштувань.

    • Якщо файлу налаштувань bp-grouping.yaml не існує, відповідь повинна містити всі наявні бізнес-процеси в розділі ungrouped, впорядковані по назві за алфавітом.

    • Наявні бізнес-процеси, які відсутні у файлі налаштувань bp-grouping.yaml, мають бути додані у відповідь в кінець розділу ungrouped, впорядковані по назві за алфавітом.

    • Якщо файл налаштувань bp-grouping.yaml не відповідає правилам валідації повертати помилку 422

  • При отриманні запиту на зміну файлу налаштувань bp-grouping.yaml:

    • Якщо файлу налаштувань bp-grouping.yaml не існує в регламенті то він створюється.

    • Якщо файл налаштувань bp-grouping.yaml існує, то його вміст повністю замінюється на дані отримані в тілі запиту.

    • Якщо зміст тіла запиту не відповідає правилам валідації повертати помилку 422

  • При запиті на видалення бізнес-процесу DELETE /versions/candidates/{versionCandidateId}/business-processes/{businessProcessName} також має бути видалений його processDefinitionId з файлу bp-grouping.yaml.

5.2. Кабінети користувача

Сторінка Доступні послуги вебінтерфейс кабінетів користувача (officer та citizen portals) має бути доповнена, відповідно до узгоджених макетів, можливістю переглядати бізнес-процеси у групах. Порядок відображення груп та бізнес-процесів має відповідати порядку у відповіді REST API.

5.2.1. REST API

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

OpenAPI Specification (Завантажити)

Для забезпечення зворотної сумісності з наявними регламентами реєстрів, та спрощення логіки роботи с файлом налаштувань, при формуванні відповіді мають бути враховані наступні правила:

  • Групи та бізнес-процеси у відповіді мають бути впорядковані так само як і у файлі налаштувань.

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

  • Якщо файлу налаштувань bp-grouping.yaml не існує чи він порожній, відповідь повинна містити всі доступні бізнеси процеси в розділі ungrouped, впорядковані по назві за алфавітом.

  • Доступні бізнес-процеси, які відсутні у файлі налаштувань bp-grouping.yaml, мають бути додані у відповідь в кінець розділу ungrouped, впорядковані по назві за алфавітом.

5.3. Компоненти системи та їх призначення в рамках дизайну рішення

У даному розділі наведено перелік компонент системи, які залучені або потребують змін/створення в рамках реалізації функціональних вимог згідно з технічним дизайном рішення.

Компонент Службова назва Призначення / Суть змін

Регламент реєстру

registry-regulation

Розширення регламенту налаштуванням bp-grouping

Пайплайн публікації регламенту

registry-jenkins

Пропагування налаштувань bp-grouping.yaml в сервіс user-process-management

CLI-утиліта валідації цілісності регламенту

registry-regulations-validator-cli

Валідація bp-grouping.yaml

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

user-process-management

Збагачення списку бізнес-процесів інформацією про групи до якої вони належать

Сервіс надання конфігурації регламенту реєстру

registry-regulation-management

Додавання методів для створення, редагування і видалення груп, а також методів для додавання бізнес-процесів у групи та видалення їх із груп

Веб компоненти та портали

common-web-app

Додавання UI елементів для управління та перегляду груп

6. Моделювання регламенту реєстру

6.1. Структура регламенту налаштувань реєстру

В рамках задачі по розширенню налаштувань, необхідно розширити відповідну конфігурацію реєстру за замовчуванням у шаблоні репозиторію регламенту empty_regulation_template. За замовчанням налаштування групування bp-grouping.yaml пусті.

Структура регламенту реєстру
Зображення 1. Структура регламенту реєстру
Приклад конфігурації реєстру bp-grouping/bp-grouping.yaml
groups:
  - name: Перша група
    processDefinitions:
      - bp-1-process_definition_id
      - bp-2-process_definition_id
  - name: Друга група
    processDefinitions:
      - bp-3-process_definition_id
  - name: Третя група
ungrouped:
  - bp-4-process_definition_id
  - bp-5-process_definition_id

6.2. Валідація регламенту реєстру

В рамках реалізації рішення, необхідно розширити CLI-утиліту валідації регламенту registry-regulations-validator-cli додатковими правилами:

  • Назви груп унікальні.

  • Бізнес-процеси в масивах processDefinitions та ungrouped зустрічаються не більше одного разу. Тобто бізнес-процес не може бути прив’язаний до різних груп одночасно, чи більше чим один раз до однієї групи.

  • Бізнес-процеси вказані в масивах processDefinitions та ungrouped існують в регламенті (папці bpmn).

6.3. Публікація змін до регламенту реєстру

Налаштування bp-grouping.yaml монтується як ConfigMap до сервісу управління бізнес-процесами користувача (user-process-management). Пайплайн публікації регламенту повинен оновлювати вміст ConfigMap bp-grouping.yaml відповідно до змісту регламенту реєстру що публікується.

7. Високорівневий план розробки

7.1. Технічні експертизи

  • BE

  • FE

  • DevOps

7.2. План розробки

  • Розширення конфігурацію реєстру за замовчуванням у шаблоні репозиторію регламенту.

  • Розширення Пайплайну Публікації Регламенту логікою пропагування налаштувань bp-grouping.yaml в сервіс user-process-management.

  • Створити JSON-схему валідації налаштувань групування та валідацію згідно з правилами.

  • Розширення API сервісу user-process-management.

  • Розширення API сервісу registry-regulation-management.

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

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

  • Розробка інструкцій для розробника регламенту та референтних прикладів.

8. Безпека

8.1. Бізнес Дані

Категорія Даних

Опис

Конфіденційність

Цілісність

Доступність

Дані реєстру, що містять відкриту інформацію

Інформація у форматі, що дозволяє її автоматизоване оброблення електронними засобами, вільний та безоплатний доступ до неї, а також її подальше використання

Відсутня

Висока

Висока

8.2. Спрощена модель загроз

bp grouping TM.drawio

8.3. Механізми протидії ризикам безпеки та відповідність вимогам безпеки

Ризик Засоби контролю безпеки Реалізація Пріоритет

Ризик експлуатація веб вразливості на Gerrit через некоректну типізацію на нових API-ендпоінтах. Параметр versionCandidateId типізований як string, але є ідентифікатором, який надалі передається напряму в gerrit як номер мердж реквесту що потенційно може призвести до вебуразливості

Необхідно змінити тип очікуваних даних з string на int що у випадку передачі некоректних даних призведе до звичайної помилки яка буде безпечно опрацьована

Не враховано в початковому дизайні

Низький