Що нового у релізі 1.9

Ми раді повідомити, що в нашому останньому оновленні з’явилась цікава функція для розробників регламенту. Тепер в нашій інноваційній платформі є вбудований візуальний редактор коду, який надає можливість легко редагувати Groovy-скрипти.

Завдяки імплементації рішення Monaco Editor, ви можете зручно створювати та змінювати код, насолоджуючись простим та зручним дизайном у стилі Visual Studio Dark.

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

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

Для отримання цифрових файлів за віддаленою адресою розроблена JUEL-функція save_digital_document_from_url().

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

Тепер ви можете працювати з моделлю даних реєстру в режимі читання у версіях-кандидатах. Під час роботи з даними реєстру для кожної версії-кандидата створюється тимчасова репліка з еталонної бази даних (PostgreSQL).

Адміністратори можуть налаштувати спливні вікна для форм введення даних у Кабінетах посадових осіб та отримувачів послуг. Це можна зробити у розділі моделювання UI-форм Кабінету адміністратора регламентів за допомогою компонента Button («Кнопка») та параметра Pop-up should display.

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

Відтепер адміністратори реєстру можуть легко налаштувати тип автентифікації для Кабінету посадової особи в інтерфейсі Control Plane. Наша платформа надає можливість використовувати власний IIT-віджет для автентифікації за допомогою КЕП, або налаштувати інтеграцію із зовнішнім провайдером id.gov.ua.

При вході до Кабінету, посадові особи реєстру зможуть використовувати лише один тип автентифікації: або КЕП, або id.gov.ua. Оновлення стануть у пригоді всім, хто шукає простий та швидкий спосіб доступу до важливої інформації та функціональності Кабінетів.

Використовуйте нові можливості нашої платформи вже сьогодні!

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

Резервні копії створюються за допомогою інструменту velero та зберігаються у захищеному сховищі бекапів minio, що знаходиться поза межами кластера Платформи.

Налаштувати розклад бекапування можна у форматі unix-cron на інтерфейсі адміністративної панелі Control Plane. Обирайте зручний час для автоматичного запуску процесу створення резервних копій та задати термін зберігання бекапів у днях.

У новому релізі була додана можливість оновлення ключів цифрового підпису рівня Платформи безпосередньо з адміністративної панелі Control Plane.

Тепер адміністратор платформи може з легкістю оновлювати дані про файлові та апаратні ключі в розділі Керування Платформою під час редагування конфігурації компонента cluster-mgmt. Це робить процес керування ключами більш зручним та простим для користувачів.

Ми постійно працюємо над удосконаленням нашої платформи, і раді оголосити про нове оновлення, яке покращує процес автентифікації користувачів у реєстрах.

Ми використовуємо нові правила порівняння, щоб забезпечити успішну автентифікацію користувачів реєстру. Коли ми отримуємо ім’я користувача, тобто атрибут fullName (ПІБ) через КЕП або від зовнішнього провайдера ідентифікації, то порівнюємо його зі значенням, яке зберігається в Keycloak IAM. При цьому ми застосовуємо нові правила, які не враховують спеціальні символи та дозволяють нечітко порівнювати імена користувачів. Такий підхід забезпечує більш точну та надійну автентифікацію.

Наша платформа підтримує автентифікацію за допомогою інтегрованої системи електронної ідентифікації (ІСЕІ) id.gov.ua. Вбудований віджет дозволяє нашим користувачам автентифікуватися безпечно та зручно.

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

Звертаємо вашу увагу на те, що ІСЕІ id.gov.ua має атестат відповідності комплексної системи захисту інформації (КСЗІ), що гарантує надійний захист персональних даних наших користувачів.

Ми розширили можливості використання операції JOIN для поєднання таблиць-представлень (Search Conditions) у БД додатковою умовою OR, окрім вже наявної AND.

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

Операція <ext:join> дозволяє поєднувати таблиці за певними умовами. Використовується при створенні критеріїв пошуку всередині тегу <ext:createSearchCondition> для отримання необхідних даних у зведених таблицях.

Операцію <ext:join> можна використовувати із додатковими умовами and та or, які визначаються в рамках тегу <ext:condition> як значення атрибута logicOperator.

У цьому релізі імплементовано валідацію бізнес-процесів за XSD-схемою.

Створено XSD-схему для валідації бізнес-процесів. XSD імпортує схему Camunda та додатково валідує бізнес-назву процесу на наявність.

Створено кастомний валідатор бізнес-процесу через spring-boot-starter-validation.

Ми впровадили валідацію полів Назва версії та Опис зміни при створенні нового запита на внесення змін до регламенту реєстру.

Якщо поле Опис зміни міститиме подвійні лапки (""), то ви не зможете створити запит на внесення змін, оскільки спрацює валідація. Така ж логіка спрацює для інших перевірчих правил, описаних у підказці до кожного поля. При цьому на інтерфейсі ви побачите відповідну помилку у вигляді підказки: "Перевірте формат поля":

У цьому релізі ми розробили функціональність, яка дозволяє посадовим особам та отримувачам послуг реєстру працювати з файлами у форматах p7s та asics та використовувати їх у рамках бізнес-процесів. Ці файли є документами, що підписані КЕП, і мають специфічне розширення.

Користувачі кабінетів можуть завантажити, або дозавантажити один або декілька таких файлів на UI-формі бізнес-процесу до фабрики даних як один масив.

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

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

При заповненні поля Опис зміни спрацьовує перевірка наявності подвійних лапок.

Якщо поле Опис зміни міститиме подвійні лапки (""), то ви не зможете створити запит на внесення змін, оскільки спрацює валідація. При цьому на інтерфейсі ви побачите відповідну помилку у вигляді підказки: "Перевірте формат поля".

У цьому релізі ми зробили перевірку обов’язкових полів при збереженні змін для усіх вкладок бізнес-процесів та UI-форм у Кабінеті адміністратора регламентів. Це дозволить уникнути збереження невалідних даних, або порожніх значень.

Коли користувач намагається зберегти зміни при створенні, або редагуванні бізнес-процесу, чи UI-форми, та знаходиться на будь-якій вкладці розділів Моделі процесів та UI-форми, то на усіх вкладках цих розділів спрацьовує валідація.

Ми реалізували можливість переглядати структуру таблиць бази даних реєстру при роботі з майстер-версією регламенту у Кабінеті адміністратора. Працювати з таблицями можливо лише у режимі перегляду (read-only). Імплементовано розбивку інтерфейсу за вкладками, зокрема впроваджено вкладку Загальна.

Тепер адміністратори можуть швидко переглянути основну інформацію про таблицю та деякі її атрибути.

Ми реалізували можливість переглядати структуру таблиць бази даних реєстру при роботі з майстер-версією регламенту у Кабінеті адміністратора. Працювати з таблицями можливо лише у режимі перегляду (read-only). Імплементовано розбивку інтерфейсу за вкладками, зокрема впроваджено вкладку Індекси.

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

Використовуйте можливості вкладки Код для моделювання бізнес-процесів. Функціональність дозволяє працювати напряму з кодом процесу, тобто його XML-представленням.

Доступ до XML-коду відкриває нові можливості та полегшує моделювання, коли потрібно, наприклад:

Просто скопіюйте готову BPMN-діаграму та вставте XML-опис у відповідне поле на вкладці Код.

У цьому релізі ми імплементували попередню валідацію даних у CSV-файлі одразу на UI-формі Кабінету посадової особи. Таким чином розширено функціональність завантаження даних до БД масивом з СSV-файлу.

Тепер, у випадку помилки, система попереджує користувача про невідповідність формату та даних CSV-файлу ще до переходу на форму підписання КЕП.

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

Реалізовано підтримку як висхідного ↑, так і низхідного ↓ сортування за алфавітом для колонки Статус виконання.

При сортуванні, послуги групуються за статусом (Очікує виконання задачі, У виконанні, Призупинено адміністратором тощо), а також автоматично спрацьовує додаткова прив’язка до сортування за датою старту (ініціювання послуги). Таким чином при натисканні клавіші Статус виконання, послуги будуть також автоматично відсортовані й за датою старту, що дозволяє показувати згруповані заявки, що були створені раніше, знизу, або зверху у списку, залежно від типу сортування, яке ви застосуєте — висхідне ↑, або низхідне ↓.

Таким чином, для кожного окремого статусу, відсортованого за алфавітом, працюватиме й окреме сортування за датою старту послуги.

У цьому релізі ми винесли сервіси Jenkins та Gerrit реєстру за Kong API Gateway. Це дозволяє мати єдину точку входу до реєстрових роутів Jenkins та Gerrit через API-шлюз Kong для адміністраторів Платформи.

Функціональність забезпечує додатковий захист адміністративних ендпоінтів реєстру, а також покращує безпекові характеристики Платформи в цілому.

Розроблено типове інтеграційне розширення-конектор Keycloak Get Officer Users By Attributes Equals And Start With.

Делегат потрібний для того, щоб при виконанні бізнес-процесу отримувати список користувачів (посадових осіб) за атрибутами KATOTTG, edrpou, drfo та fullName із сервісу керування ідентифікацією та доступом Keycloak.

Пошук за атрибутами edrpou, drfo та fullName здійснюється за допомогою функції equal, яка повертає значення, що мають точну відповідність (дорівнюють) заданим.

Пошук за атрибутом KATOTTG здійснюється за допомогою функції Inverse startsWith, яка повертає значення зі вказаним префіксом, тобто значення, які "починаються із" заданої умови.

Для моделювання бізнес-процесу розроблено типове розширення для задач на відправлення повідомлення (Send Task) — Send User Notification.

Розширення Send User Notification — делегат для відправлення повідомлень отримувачам послуг через канали зв’язку inbox, email, diia з використанням заданих шаблонів у структурі регламенту реєстру.

Імплементовано підтримку двох сценаріїв моделювання відправлення повідомлень у межах моделювання бізнес-процесів:

Можливість завантаження даних масивом до БД дозволяє створювати бізнес-процеси, завдяки яким користувачі реєстру можуть вносити масив даних одним файлом, наприклад, наповнення довідників реєстру або дозавантаження даних.

Платформа надає можливість переглядати та редагувати JSON-представлення форми на вкладці Код.

Функціональність дозволяє швидко та легко внести зміни до даних форми без використання конструктора для моделювання.

Редагування складових регламенту реєстру можливо внести лише в рамках версій-кандидатів на внесення змін. Для майстер-версії доступна лише опція перегляду.

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

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

При застосуванні змін до майстер-версії, усі гілки-кандидати автоматично отримують оновлення, включно з датами редагування форм.

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

При роботі з компонентом Edit Grid моделювальник може обирати тип сортування, який має застосовуватися для стовпців компонента.

Наразі можна сортувати значення як числові (Sort as number, або як текстові для компонентів, які є частиною сітки Edit Grid.

Завантажити дані масивом до фабрики даних можливо, якщо при моделюванні форми використати компонент Edit Grid.

Компонент Edit Grid дозволяє змоделювати записи з різних компонентів як єдиний масив і завантажити його до бази даних. Масив має відповідати структурі, визначеній моделлю даних.

Ми покращили досвід моделювання UI-форм з використанням компонента Text Field. Додано підтримку функції Trim Spaces.

Функція Trim Spaces відпрацьовує таким чином, що коли користувач вносить у текстовому полі на формі значення, які містять пробіли на початку (перед текстом), або в кінці (після тексту), то при надсиланні запита з форми такі пробіли видаляються.

У цьому релізі додано функціональність відправлення електронних повідомлень громадянам із використанням різних каналів зв’язку, а саме:

Налаштування шаблонів відбувається в регламенті реєстру, у директорії notifications.

Користувач (отримувач послуг) може дозволити отримання повідомлень, тобто верифікувати відповідний канал зв’язку у профілі Кабінету.

Реалізовано логування подій завантаження користувачів у журналі аудиту системи. Змодельовано "Журнал управління користувачами".

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

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

Імплементовано логування технічних подій завантаження користувачів у сервісі Kibana.

Модуль перевіряє увесь файл і пише всі знайдені проблеми в сховище технічних логів Kibana. У логах фіксується інформація про кожен запис, пропущений при створенні, із зазначеною причиною пропуску, а успішно відпрацьовані порядково не фіксуються (показується лише загальна кількість успішних). Також присвоюється унікальний ідентифікатор користувача в Keycloak (Username), який дублюється.

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

Події успішного, або неуспішного відправлення повідомлень користувачу через канали зв’язку inbox, email та diia логуються в журналі аудиту та зберігаються у базі даних audit.

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

Надалі перелік налаштувань буде розширено.

Редагування складових регламенту реєстру можливо внести лише в рамках версій-кандидатів на внесення змін. Для майстер-версії доступна лише опція перегляду.

У цьому релізі ми імплементували можливість працювати із таблицями бази даних реєстру у режимі перегляду (read-only).

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

Реалізовано можливість керувати запитами на внесення змін до регламенту реєстру. Адміністратор може:

Адміністратор тепер має можливість переглядати інформацію щодо конфліктних змін у різних гілках (версіях-кандидатах) розробки регламенту.

Конфлікт злиття — це подія, яка виникає, коли система (Git) не може автоматично вирішити відмінності в коді між двома версіями змін.

У цьому релізі ми розробили зручний інтерфейс, який дозволяє налаштовувати власні DNS-імена для публічних Кабінетів отримувача послуг та посадової особи. Адміністратор може зробити це в адміністративній панелі керування платформою та реєстрами Control Plane.

При редагуванні реєстру адміністратор легко може завантажити файл SSL-сертифіката для власного імені у реєстрових кабінетах.

Інтерфейс адміністрування розділяє отриманий сертифікат на CA-сертифікат (Certificate Authority) і ключ, зберігає їх в центральному сховищі секретів HashiCorp Vault та додає отримані DNS-імена до налаштувань реєстру values.yaml.

Ми імплементували можливість обмежувати доступ до компонентів, що використовуються на Платформі, за допомогою правил безкласової маршрутизації.

Адміністратор має можливість задавати список IP-адрес та підмереж окремо для Кабінетів посадової особи та отримувача послуг, окремо для адміністративних компонентів реєстру, а також для платформних та інфраструктурних компонентів.

Віднині адміністративна панель Control Plane дозволяє переглядати та підтверджувати запити на внесення змін до конфігурації реєстру в Gerrit, тобто виконувати git merge до репозиторію, не виходячи за межі Control Plane.

Запропоновані зміни вносяться до конфігурації файлу deploy-templates/values.yaml.

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

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

Платформа дозволяє налаштовувати та підтверджувати відправлення повідомлень у Кабінеті отримувача послуг через канали зв’язку inbox, email та diia.

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