Бізнес вимоги:

Система майданчика повинна використовувати централізований endpoint як єдине джерело прав доступу
Усі бізнес-рішення щодо доступу до:
- оголошення процедур,
- подання заявок,
- роботи з реєстрами,
- подачі заяв на об'єкти оренди,
- створення дій над об'єктами оренди,
- створення контрактів для Малої та Великої приватизації
- створення викупу для Малої та Великої приватизації
- створення Інфораційних повідомлень для Малої та Великої приватизації
- створення об'єктів для Малої та Великої приватизації
повинні базуватись виключно на даних permissions, отриманих з endpoint.
Майданчик не має права надавати функціональність, яка не підтверджена наявними в endpoind permissions.

Функціональні вимоги

В Prozorro.Sale наявні два endpoints:

Для отримання загального списку прав і дозволів одразу по всім Майданчикам - https://procedure.prozorro.sale/api/auth/brokers
Для отримання списку прав і дозволів по одному конкретному Майданчику - https://procedure.prozorro.sale/api/auth/brokers/system/services
- де замість system в запит необхідно підставити owner name Майданчика

Інтеграційні вимоги

Майданчик повинен виконувати запит до endpoint не рідше ніж 1 раз на добу (наразі о 05:00)
Майданчик повинен обробляти успішну відповідь та зчитувати всі отримані permissions
Отримані permissions повинні зберігатись локально для подальшого використання бізнес-логікою та UI
Система повинна зберігати останню валідну версію permissions у разі тимчасової недоступності endpoint

Валідація permissions

Система повинна перевіряти цілісність структури permissions, зокрема:
- наявність ключа permissions
- наявність секцій procedures, jobber, registry
- допустимі значення (procedure, bids, object)
У разі виявлення невалідної структури необхідно передати інформацію Prozorro.Sale, наприклад, через запит в Slack Workflow

Доступ до процедур

Майданчик має дозволяти оголошення аукціонів організаторами, якщо permissions.procedures.<procedure_name> містить "procedure"
Майданчик має дозволяти подання заявок учасниками, якщо permissions.procedures.<procedure_name> містить "bids"
За відсутності відповідного значення permissions функціональність повинна бути недоступною як на UI, бо вона буде недоступна і на API рівні

Доступ до дій з Реєстром об’єктів оренди

Майданчик має дозволяти:
1. Створення Об'єкту оренди, якщо: permissions.registry.object містить "object"
2. Створення Дії до об'єкту оренди, якщо: permissions.registry.action містить "object"
3. Створення Заяв до об'єкту оренди, якщо: permissions.registry.lease_request містить "object"

Робота з напрямком Приватизації

Доступ до створення Інформаційних повідомлень, контрактів, об'єктів, викупу Малої приватизації

Майданчик має дозволяти:

Створення Об'єкту Малої приватизації, якщо: permissions.registry.asset містить "object"
Створення Інформаційного повідомлення Малої приватизації, якщо: permissions.jobber.announcement містить "object"
Створення Викупу Малої приватизації, якщо: permissions.jobber.redemption містить "object"

В разі відсутності у Майданчика permissions.jobber.announcement "object", організатор НЕ може створити Інформаційне Повідомлення та, відповідно, не відбудеться автоматичного створення процедури Приватизації

Доступ до створення Інформаційних повідомлень, контрактів, об'єктів, викупу Великої приватизації

Майданчик має дозволяти:

Створення Об'єкту Великої приватизації, якщо: permissions.registry.large_asset містить "object"
Створення Інформаційного повідомлення Великої приватизації, якщо: permissions.jobber.large_announcement містить "object"
Створення Викупу Великої приватизації, якщо: permissions.jobber.large_redemption містить "object"

В разі відсутності : permissions.jobber.large_announcement "object", організатор не може створити Інформаційне Повідомлення та, відповідно, не буде автоматичного створення процедури Приватизації

UI та відображення

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

Обробка змін і відсутніх permissions

У разі неочікуваної зміни permissions Майданчик повинен зафіксувати інцидент та менеджмент Майданчика повинен ініціювати звернення через Slack WF (“Приватні запити”)

Нефункціональні вимоги

Обробка permissions не повинна впливати на продуктивність UI
Логіка permissions повинна бути розширюваною для нових напрямків без зміни існуючих UC

Вимоги до помилок і стабільності

У разі недоступності endpoint:

використовується остання валідна версія permissions, яка має локально зберігатись на стороні Майданчика
користувачі не отримують помилок UI

Система не повинна надавати нові доступи без наявності відповідних permissions в endpoint

UseCases

Use Case 1. Отримання permissions з системного endpoint

Назва	Отримання permissions з системного endpoint
Актори	Основний: ЕТМ (майданчик) Системний: ЦБД
Передумови	Майданчик акредитований у системі Endpoint доступний майданчику ~~Є валідні облікові дані для доступу~~ - Наразі не актуально
Основний хід подій (дій)	ЕТМ надсилає запит до endpoint permissions ЦБД повертає відповідь з permissions Дані передаються у внутрішню логіку майданчика
Альтернативні шляхи, помилки, крайові випадки	Endpoint недоступний Помилка авторизації - наразі відсутня Некоректний формат відповіді
Результат (Постумови)	Отримано відповідь endpoint або зафіксовано помилку
Інші вимоги	Endpoint викликається планово (наразі 1 раз на добу о 05:00)

Use Case 2. Отримання та збереження permissions майданчиком

Назва	Отримання та локальне збереження permissions
Актори	Основний: ЕТМ (майданчик)
Передумови	Успішно виконано UC-1 Отримано відповідь endpoint
Основний хід подій (дій)	ЕТМ зчитує дані з відповіді endpoint Дані зберігаються у локальному сховищі (cache / БД) Дані маркуються як актуальні
Альтернативні шляхи, помилки, крайові випадки	Дані не збереглись Частково збережені permissions
Результат (Постумови)	Майданчик має локально доступний перелік permissions
Інші вимоги	Повинна зберігатись попередня версія permissions (за потреби)

Use Case 3. Валідація цілісності permissions

Назва	Валідація структури та цілісності permissions
Актори	Основний: ЕТМ (майданчик)
Передумови	Успішно виконано UC-2
Основний хід подій (дій)	ЕТМ перевіряє наявність ключа `permissions` Перевіряє обов’язкові секції (`procedures`, `jobber`, `registry`) Перевіряє допустимі значення (`procedure`, `bids`, `object`) Фіксує результат валідації
Альтернативні шляхи, помилки, крайові випадки	Відсутня секція Невідоме значення permissions Порожні permissions
Результат (Постумови)	Permitons визнані валідними або невалідними
Інші вимоги	Результат валідації має логуватись

Use Case 4. Визначення доступу до оголошення аукціонів

Назва	Визначення права організатора на оголошення аукціонів
Актори	Основний: ЕТМ Другорядний: Організатор
Передумови	Permitons валідні UC-3
Основний хід подій (дій)	ЕТМ перевіряє `permissions.procedures.<procedure_name>` Якщо значення `procedure` — доступ дозволено Функціонал створення аукціону активується
Альтернативні шляхи, помилки, крайові випадки	Procedure відсутня Значення ≠ `procedure`
Результат (Постумови)	Організатор може або не може створювати аукціони
Інші вимоги	Логіка повинна застосовуватись для кожного напрямку окремо

Use Case 5. Визначення доступу до подання заявок (bids)

Назва	Визначення права користувачів на подання заявок
Актори	Основний: ЕТМ Другорядний: Потенційний учасник (зареєстрований на ЕТМ користувач з роллю учасник)
Передумови	Permitons валідні UC-3
Основний хід подій (дій)	ЕТМ перевіряє `permissions.procedures.<procedure_name>` Якщо значення `bids` — доступ дозволено Активується можливість подання заявки
Альтернативні шляхи, помилки, крайові випадки	Значення відсутнє Значення ≠ `bids`
Результат (Постумови)	Учасник може або не може подати заявку
Інші вимоги	Має узгоджуватись з UI та API

Use Case 6. Доступ до оголошення JAS і подальшого автоматичного створення процедур SP*

Назва	Визначення доступу до оголошення JAS (Інформаційного повідомлення)
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.jobber.announcement` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `announcement` Значення ≠ `object`
Результат (Постумови)	Доступ до SP* процедур дозволено або заборонено
Інші вимоги	Обов’язково для напрямків SP* Не застосовується до інших напрямків

Use Case 7. Доступ до внесення об’єктів у реєстр Малої приватизації (RAS)

Назва	Визначення доступу до внесення об’єктів до реєстру Малої приватизації
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.registry.asset` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `asset` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з RAS Не застосовується до інших напрямків

Use Case 8. Доступ до створення execution Малої приватизації (RES)

Назва	Визначення доступу до створення execution Малої приватизації
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.registry.execution` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `execution` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з REL Не застосовується до інших напрямків

Use Case 9. Доступ до створення redemption Малої приватизації (JRS)

Назва	Визначення доступу до створення redemption Малої приватизації
Актори	Основний: ЕТМ
Передумови	Permissions валідні
Основний хід подій (дій)	Перевіряється `permissions.jobber.redemption` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `redemption` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з JRS Не застосовується до інших напрямків

Use Case 10. Доступ до оголошення JAL і подальшого автоматичного створення процедур LP*

Назва	Визначення доступу до оголошення JAL (Інформаційного повідомлення)
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.jobber.large_announcement` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `large_announcement` Значення ≠ `object`
Результат (Постумови)	Доступ до створення JAL дозволено або заборонено
Інші вимоги	Обов’язково для напрямків LP* Не застосовується до інших напрямків

Use Case 11. Доступ до внесення об’єктів до реєстру Великої приватизації (RAL)

Назва	Визначення доступу до внесення об’єктів до реєстру Великої приватизації
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.registry.large_asset` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `large_asset` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з RAL Не застосовується до інших напрямків

Use Case 12. Доступ до створення execution Великої приватизації (REL)

Назва	Визначення доступу до створення executionВеликої приватизації
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.registry.large_execution` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `large_execution` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з REL Не застосовується до інших напрямків

Use Case 13. Доступ до створення redemption Великої приватизації (JRL)

Назва	Визначення доступу до створення redemption Великої приватизації
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.jobber.large_redemption` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `large_redemption` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з JRL Не застосовується до інших напрямків

Use Case 14. Доступ до внесення об’єктів у реєстр оренди (RGL)

Назва	Визначення доступу до внесення об'єктів до реєстру оренди
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.registry.object` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `object` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з RGL Не застосовується до інших напрямків

Use Case 15. Доступ до створення Дій до об'єктів реєстру оренди (RGLA)

Назва	Визначення доступу до створення Дій до об'єктів реєстру оренди
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.registry.action` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `action` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з RGL Не застосовується до інших напрямків

Use Case 16. Доступ до створення Заяв до об'єктів реєстру оренди (RGLR)

Назва	Визначення доступу до створення Заяв до об'єктів реєстру оренди
Актори	Основний: ЕТМ
Передумови	Permitons валідні
Основний хід подій (дій)	Перевіряється `permissions.registry.lease_request` Якщо значення `object` — доступ дозволено
Альтернативні шляхи, помилки, крайові випадки	Відсутній ключ `lease_request` Значення ≠ `object`
Результат (Постумови)	Доступ до створення об'єктів реєстру дозволено або заборонено
Інші вимоги	Обов’язково для роботи з RGL Не застосовується до інших напрямків

Use Case 17. Керування відображенням функціоналу на сайті

Назва	Керування UI відповідно до permissions
Актори	Основний: ЕТМ Другорядні: Організатор, Учасник
Передумови	Виконані UC-4 – UC16
Основний хід подій (дій)	ЕТМ агрегує результати бізнес-UC Відображає лише дозволені дії Приховує або блокує заборонений функціонал
Альтернативні шляхи, помилки, крайові випадки	Конфлікт доступів Застарілі permissions
Результат (Постумови)	Користувачі бачать лише дозволений функціонал
Інші вимоги	UI та API мають бути синхронні

Use Case 18. Обробка відсутніх або змінених permissions

Назва	Ескалація проблем з permissions
Актори	Основний: Менеджмент ЕТМ Системний: WF (“Приватні запити”)
Передумови	Виявлено аномалію permissions
Основний хід подій (дій)	ЕТМ фіксує невідповідність Менеджмент ініціює звернення у WF Очікується роз’яснення або корекція
Альтернативні шляхи, помилки, крайові випадки	Відсутня відповідь Підтверджена бізнес-зміна
Результат (Постумови)	Причина відсутності permissions з’ясована
Інші вимоги	Всі звернення мають трасуватись