[EDP-DDM-33314] Added rbac-data-modeling.adoc, added info about rbac …

…for search conditions

Change-Id: I8f307b585d09698dfe3ea2c0c7dba92756e9a3a6
(cherry picked from commit 1c206cf06180714c77fed7f09dc613efefe0ac29)
(cherry picked from commit e3868dcd6d3826a1bd5b5ad9a810808cc9c77cb9)
(cherry picked from commit f5f433c09780a99c0738eda43a911a92aeb38c9a)

docs/ua/modules/registry-develop/pages/bp-modeling/bp/access/roles-rbac-bp-modelling.adoc

@@ -120,6 +120,8 @@ IMPORTANT: _Імена ролей, реалм та `process_definition_id` по
 </changeSet>
 ----
 
+TIP: Дізнайтеся, як налаштувати RBAC окремо для критеріїв пошуку на сторінці xref:data-modeling/data/physical-model/rbac/rbac-data-modeling.adoc[].
+
 == Моделювання бізнес-процесів
 
 === Розмежування прав доступу на виконання задач бізнес-процесу

docs/ua/modules/registry-develop/pages/data-modeling/data/physical-model/rbac/rbac-data-modeling.adoc

@@ -0,0 +1,132 @@
+= Моделювання доступу до даних за допомогою RBAC
+include::platform:ROOT:partial$templates/document-attributes/default-set-ua.adoc[]
+
+*Керування доступом на основі ролей (RBAC)* -- це механізм, який дозволяє групувати права доступу за ролями та застосовувати їх до різних об'єктів, таких як таблиці баз даних або критерії пошуку (Search Conditions). Докладнішу інформацію про загальні принципи та застосування RBAC дивіться на сторінці xref:bp-modeling/bp/access/roles-rbac-bp-modelling.adoc[].
+
+== Налаштування ролей та прав доступу
+
+RBAC використовується для моделювання доступу до даних у системі за допомогою XML-конфігурацій. Основний елемент налаштування -- це тег `<ext:rbac>`, в якому визначаються ролі та права доступу до об'єктів реєстру. Для кожної ролі можна вказати, до яких таблиць і стовпців вона має доступ, а також налаштувати доступ до критеріїв пошуку окремо.
+
+=== Структура конфігурації
+
+Налаштування прав доступу виконується через тег `<ext:rbac>`, який містить один або кілька тегів `<ext:role>`. Кожен тег `<ext:role>` відповідає за налаштування прав доступу для певної ролі в реєстрі.
+
+.Приклад. Структура конфігурації
+[source,xml]
+----
+<changeSet id="roles" author="registry owner">
+    <comment>SET PERMISSIONS</comment>
+    <ext:rbac>
+        <ext:role name="role_name">
+            <ext:table name="table_name" read="true" update="true" insert="true" delete="true"/>
+        </ext:role>
+    </ext:rbac>
+</changeSet>
+----
+
+* `<ext:role>` -- елемент, що визначає роль, для якої встановлюються права доступу.
+* `<ext:table>` -- елемент, який вказує на таблицю бази даних, для якої налаштовуються права. Доступ може бути встановлений на рівні таблиці або окремих колонок. У цьому прикладі права доступу встановлені на рівні таблиці, без необхідності вказувати кожну колонку окремо.
+
+=== Приклад налаштування прав доступу
+
+Наступний приклад показує, як налаштувати права доступу для кількох ролей, використовуючи доступ на рівні таблиць:
+
+[source,xml]
+----
+<changeSet id="roles" author="registry owner">
+    <comment>SET PERMISSIONS</comment>
+    <ext:rbac>
+        <ext:role name="viewer">
+            <ext:table name="employee_data" read="true"/>
+        </ext:role>
+
+        <ext:role name="editor">
+            <ext:table name="employee_data" read="true" update="true"/>
+        </ext:role>
+
+        <ext:role name="admin">
+            <ext:table name="employee_data" read="true" update="true" delete="true"/>
+        </ext:role>
+    </ext:rbac>
+</changeSet>
+----
+
+У цьому прикладі налаштовуються права доступу для трьох ролей:
+
+* `viewer` має доступ лише на читання до таблиці `employee_data`. Ця роль підходить для користувачів, яким потрібно переглядати дані, але не змінювати їх.
+* `editor` має доступ на читання та оновлення (`update`) даних. Ця роль дозволяє вносити зміни, але не видаляти записи.
+* `admin` має повний доступ, включаючи видалення записів (`delete`), що забезпечує найвищий рівень доступу.
+
+== Налаштування RBAC для критеріїв пошуку
+
+[NOTE]
+====
+За замовчуванням, коли роль має доступ до таблиці, ця роль автоматично отримує доступ до всіх критеріїв пошуку (Search Conditions), пов'язаних із цією таблицею. Це може призвести до надмірного поширення прав доступу, коли користувач має доступ до пошукових умов, до яких він не повинен мати доступ.
+====
+
+=== Налаштування прав доступу для критеріїв пошуку
+
+Для більшої гнучкості можна окремо налаштовувати права доступу для критеріїв пошуку. Це робиться через тег `<ext:searchCondition>`, який можна використовувати в межах іншого тегу `<ext:role>`. Таким чином, доступ до конкретних критеріїв пошуку можна налаштувати незалежно від доступу до таблиці.
+
+==== Приклад налаштування для критеріїв пошуку
+
+Припустимо, є таблиця `project_data` і критерій пошуку `search_active_projects`. Права доступу можна налаштувати окремо для таблиці та критерію пошуку:
+
+[source,xml]
+----
+<changeSet id="roles" author="registry owner">
+    <comment>SET PERMISSIONS</comment>
+    <ext:rbac>
+        <ext:role name="officer">
+            <ext:table name="project_data" read="true"/>
+        </ext:role>
+        <ext:role name="op-regression">
+            <ext:table name="project_data" read="true"/>
+        </ext:role>
+        <ext:role name="op-regression">
+            <ext:searchCondition name="search_active_projects"/>
+        </ext:role>
+    </ext:rbac>
+</changeSet>
+----
+
+У цьому прикладі:
+
+* Ролі `officer` і `op-regression` мають доступ на читання до таблиці `project_data`.
+* Критерій пошуку `search_active_projects` доступний лише для ролі `op-regression`.
+
+Таким чином, доступ до пошуку буде можливий для користувачів, які мають роль `op-regression`, що дозволяє точніше контролювати доступ до конкретних критеріїв пошуку.
+
+==== Принципи роботи RBAC для критеріїв пошуку
+
+RBAC на рівні критеріїв пошуку працює за принципом звуження доступу відносно прав доступу до таблиць. Наприклад, якщо доступ до таблиці `project_data` налаштований для ролей `officer` і `op-regression`, а доступ до критерію пошуку `search_active_projects` -- лише для ролі `op-regression`, то пошук можна виконати, якщо користувач має роль `op-regression`.
+
+== Динамічне оновлення RBAC-конфігурацій в одному changeSet
+
+Кожен новий changeSet із конфігураціями RBAC перезаписує попередні налаштування. Тому рекомендується використовувати окремий файл для конфігурацій RBAC, наприклад, `data-model/role_permission.xml` (_див. xref:bp-modeling/bp/access/roles-rbac-bp-modelling.adoc[]_).
+
+Щоб уникнути необхідності копіювати попередні налаштування в кожному новому changeSet-і, можна застосувати підхід, який дозволяє керувати RBAC в одному changeSet-і. Використання атрибута `runAlways="true"` та додавання тегу `<validCheckSum>ANY</validCheckSum>` забезпечують виконання changeSet-у при кожному оновленні.
+
+[source,xml]
+----
+<changeSet id="roles" author="registry owner" runAlways="true">
+    <validCheckSum>ANY</validCheckSum>
+    <ext:rbac>
+        <ext:role name="admin">
+            <ext:table name="employee_data" read="true" update="true" delete="true"/>
+        </ext:role>
+    </ext:rbac>
+</changeSet>
+----
+
+Це налаштування дозволяє динамічно змінювати вміст конфігурацій RBAC, без необхідності створювати нові changeSet-и для кожної зміни. Таким чином, ви можете керувати RBAC в одному файлі, зберігаючи всі попередні налаштування та додаючи нові зміни за потреби.
+
+== Переваги окремого налаштування для критеріїв пошуку
+
+Розширене налаштування RBAC для критеріїв пошуку дає такі переваги:
+
+* Точний контроль доступу до пошукових умов, що знижує ризик несанкціонованих операцій.
+* Гнучкість у налаштуванні доступу, що дозволяє створювати різні сценарії доступу до даних.
+* Підвищена безпека, оскільки користувачі отримують доступ лише до тих даних і пошукових умов, які відповідають їхнім ролям.
+
+Таке налаштування допомагає більш ефективно контролювати доступ до даних, уникаючи надмірного розповсюдження прав і забезпечуючи гнучке управління доступом.

docs/ua/modules/registry-develop/partials/nav.adoc

@@ -162,32 +162,40 @@ include::registry-develop:partial$registry-admin/abandoned-processes/nav.adoc[]
 // DEBUG REGISTRY REGULATIONS
 *** xref:registry-develop:registry-admin/debug-registry-regulations.adoc[]
 +
-// ------------------- Моделювальникам даних -------------------
+// ======================= DATA MODELING ======================================
 ** xref:registry-develop:data-modeling/index.adoc[Моделювальникам даних]
 +
 //Створення логічної моделі даних реєстру
 *** xref:registry-develop:data-modeling/data/logical-model/data-modelling-logical-datamodel.adoc[Створення логічної моделі даних реєстру]
 +
+// PHYSICAL DATA MODEL
 *** xref:registry-develop:data-modeling/data/physical-model/overview.adoc[]
 **** xref:registry-develop:data-modeling/data/physical-model/liquibase-introduction.adoc[]
 **** xref:registry-develop:data-modeling/data/physical-model/data-model-changes-algorithm.adoc[]
 **** xref:registry-develop:data-modeling/data/physical-model/liquibase-standard-change-types.adoc[]
++
+// LIQUIBASE DDM EXT
 **** xref:registry-develop:data-modeling/data/physical-model/liquibase-ddm-ext.adoc[]
 +
+//RBAC
+***** xref:registry-develop:data-modeling/data/physical-model/rbac/rbac-data-modeling.adoc[]
++
 //SEARCH CONDITIONS
 include::registry-develop:partial$data-modeling/data/physical-model/sc/nav.adoc[]
 +
 //SOME LIQUIBASE SCENARIOS
 ***** xref:registry-develop:data-modeling/data/physical-model/liquibase-changes-management-sys-ext.adoc[]
++
+// ACCESS TO REGISTRY REST API VIEWS
 **** xref:registry-develop:data-modeling/data/physical-model/rest-api-view-access-to-registry.adoc[]
 **** xref:registry-develop:data-modeling/data/physical-model/auto-generate-number.adoc[]
 +
-// Первинне завантаження даних
+// INITIAL DATA LOAD
 *** xref:registry-develop:data-modeling/initial-load/index.adoc[Первинне завантаження даних]
 **** xref:registry-develop:data-modeling/initial-load/data-initial-data-load-prep.adoc[Підготовка даних до міграції]
 **** xref:registry-develop:data-modeling/initial-load/data-initial-data-load-pl-pgsql.adoc[Опис процедури PL/pgSQL для первинного завантаження даних реєстру]
 +
-// Моделювання звітів
+// MODELING REPORTS
 *** xref:registry-develop:data-modeling/reports/reports-overview.adoc[]
 **** xref:registry-develop:data-modeling/reports/restrict-select-data-based-on-token-context.adoc[]
 +