Розробка регламенту у майстер-версії для форм та процесів: спрощення моделювання та захист від перезапису
| 🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію. | 
1. Загальний опис
В процесі розробки або виправлення незначних помилок які не потребують значних змін в регламенті розробнику все одно доводиться робити велику кількість дій, а саме: створення версії кандидати в Адмін порталі, внесення змін в регламент та інтеграція змін в мастер-версію. Це вимагає великої кількості часу та зусиль. Для покращення досвіду моделювання необхідно надати можливість вносити зміни в безпосередньо в мастер-версію регламенту.
2. Функціональні сценарії
- 
Редагування форми безпосередньо в мастер-версії регламенту реєстру 
- 
Редагування бізнес-процесу безпосередньо в мастер-версії регламенту реєстру 
- 
Створення форми безпосередньо в мастер-версії регламенту реєстру 
- 
Створення бізнес-процесу безпосередньо в мастер-версії регламенту реєстру 
- 
Редагування форми в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату 
- 
Редагування бізнес-процесу в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату 
- 
Створення форми в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату 
- 
Створення бізнес-процесу в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату 
- 
Копіювання форми в мастер-версії регламенту реєстру 
- 
Копіювання бізнес-процесу в мастер-версії регламенту реєстру 
- 
Видалення форми в мастер-версії регламенту реєстру 
- 
Видалення бізнес-процесу в мастер-версії регламенту реєстру 
| Усі функціональні сценарії належать до Вебінтерфейсу моделювання регламенту. | 
3. Ролі користувачів
- 
Розробник регламенту 
4. Загальні принципи та положення
- 
Розробник регламенту може редагувати,створювати або видаляти форму або бізнес-процес безпосередньо в мастер-версії регламенту реєстру 
- 
Сутність - це загальна назва форми або бізнес-процесу в цьому документі 
- 
Спрощений процес створення версії кандидату містить в собі автоматизовану послідовність кроків при натисканні кнопки редагування/створення/видалення сутності, а саме внесення інформації про версію-кандидат, створення версії кандидату, внесення змін в сутність та збереження змін в версії кандидату 
- 
При редагуванні, створенні та видаленні сутності необхідно забезпечити захист від перезапису змін, які можуть бути внесені іншими моделювальниками 
- 
При створенні сутності повинна виконуватися перевірка на наявність сутності з таким іменем 
- 
При редагуванні та видаленні сутності повинна виконуватися перевірка на те що зміни застосовуються відносно останньої версії сутності (незалежно у версії-кандидаті чи мастер-версії) 
- 
При перевірці на зміни повинно враховуватися що зміни можуть бути внесені як через Адмін портал, так і напряму у Gerrit 
- 
При редагуванні та видаленні сутності (http method PUT, DELETE) використовується загальний RestAPI Optimistic locking підхід який використовується в системі 
- 
При наявності змін, що конфліктують система після обробки такого запиту повинна залишатися в консистентному стані 
- 
При наявності змін, що конфліктують користувач повинен власноруч скопіювати контент, який редагував, оновити сторінку з сутністю та внести зміни вручну 
- 
При заведенні змін безпосередньо в мастер повинен створюватися Gerrit MR з параметром submit та private. Submit - вказує на те, що зміни повинні бути відразу інтегровані. Private - використовується для розділення для маркування змін, які не потребуються запуски пайплайну перевірки регламенту (додаткове налаштування в Jenkins-Gerrit інтеграції) 
5. Високорівневий дизайн рішення
5.1. Захист від перезапису
6. Обсяг робіт
6.1. Попередня декомпозиція
- 
[FE] Додати можливість створення/редагування форми/бізнес-процесу з мастер-версії 
- 
[BE] Розширити API для роботи з формами та бізнес-процесами в мастер-версії 
- 
[DEVOPS] Налаштувати пайплайн перевірки регламенту на роботу тільки з публічними змінами Gerrit (exclude Private changes) 
- 
[FE] Додати спрощений процес створення версії кандидату зі сторінки створення сутності 
- 
[FE] Додати посилання на Jenkins для відстежування результату публікації регламенту в Адмін Порталі 
- 
[FE] Додати обробку помилок з конфліктами з підказками по діям користувачу 
- 
[BE] Реалізувати BusinessProcessEtagInterceptor для перевірки etag при оновленні бізнес-процесу 
- 
[BE] Додати перевірку на дублікат імен при створенні сутності на рівні VersionedFileRepository 
- 
[BE] Додати перевірку по etag при оновленні сутності на рівні VersionedFileRepository 
- 
[BE] Додати обробку merge conflicts при публікації змін в Gerrit 
- 
[BE] Розширити HeadFileRepositoryImpl підтримкою запису файлів в репозиторій 
- 
[BE] Розширити HeadFileRepositoryImpl підтримкою видалення файлів в репозиторій 
- 
[FE] Додати можливість копіювання сутності в мастер-версії 
- 
[FE] Додати можливість видалення сутності в мастер-версії 
- 
[DEVOPS] Додати права сервіс акаунту RRM на виконання update by submit операції в Gerrit 
6.2. Зміни в REST API
Registry Regulation Management
6.3. Обмеження рішення
- 
При змінах, що конфліктують користувачу потрібно власноруч скопіювати контент, оновити сторінку та повторити збереження з аналізом конфліктів 
- 
Поточний дизайн не покриває фактичне видалення форм та бізнес-процесів в Form-management-provider та BPMS відповідно