Система майданчика повинна використовувати централізований endpoint як єдине джерело прав доступу
Усі бізнес-рішення щодо доступу до:
оголошення процедур
подання заявок
роботи з реєстрами
повинні базуватись виключно на даних permissions, отриманих з endpoint.
Майданчик не має права надавати функціональність, яка не підтверджена наявними в endpoind permissions.
В Prozorro.Sale наявні два endpoints:
Система повинна перевіряти цілісність структури 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 рівні |
Майданчик має дозволяти:
Створення Об'єкту оренди, якщо: permissions.registry.object містить "object"
Майданчик має дозволяти:
Створення Об'єкту Малої приватизації, якщо: permissions.registry.asset містить "object"
В разі відсутності у Майданчика permissions.jobber.announcement "object", організатор НЕ може створити Інформаційне Повідомлення та, відповідно, - НЕ відбудеться автоматичного створення процедури Приватизації
Майданчик має дозволяти:
Створення Об'єкту Великої приватизації, якщо: permissions.registry.large_asset містить "object"
В разі відсутності : permissions.jobber.large_announcement "object", організатор не може створити Інформаційне Повідомлення та, відповідно, не буде автоматичного створення процедури Приватизації
UI майданчика повинен динамічно відображати або приховувати функціональність відповідно до permissions
Користувачі не повинні бачити дій, які їм недоступні згідно permissions Майданчика
У разі неочікуваної зміни permissions Майданчик повинен зафіксувати інцидент та менеджмент Майданчика повинен ініціювати звернення через Slack WF (“Приватні запити”)
Обробка permissions не повинна впливати на продуктивність UI
Логіка permissions повинна бути розширюваною для нових напрямків без зміни існуючих UC
У разі недоступності endpoint:
використовується остання валідна версія permissions, яка має локально зберігатись на стороні Майданчика
користувачі не отримують помилок UI
Система не повинна надавати нові доступи без наявності відповідних permissions в endpoint
Майданчик успішно пройшов тестування нової процедури (наприклад, landRental-english) у тестовому середовищі Prozorro.Sale та подав заявку на отримання відповідних доступів (permissions)
Видача доступів
Після обробки заявки зі сторони Prozorro.Sale Майданчику надаються permissions для роботи з новою процедурою. Результатом виконання буде, наприклад:

Реліз на стороні Майданчика
Майданчик розгортає на Prod свою протестовану версію функціоналу, але не активує можливість:
створювати процедури landRental-english
подавати заявки на участь у таких процедурах
Синхронізація permissions
О 05:00 відбувається автоматична синхронізація доступів із endpoint Prozorro.Sale
Отримання актуальних прав доступу
Endpoint повертає перелік дозволених напрямків і ролей, зокрема:
"landRental-english": [
"procedure",
"bids"
]
Активація функціоналу
На основі отриманих permissions Майданчик автоматично:
вмикає можливість створення процедур landRental-english для Організаторів
відкриває можливість подання заявок для Учасників
Майданчик отримує повноцінну можливість працювати з новою процедурою як у ролі Організатора, так і Учасника. Весь необхідний функціонал стає доступним без ручних налаштувань.
Раніше Майданчик мав доступ до процедури (наприклад, landRental-english) та надавав користувачам відповідний функціонал.
Обмеження доступів зі сторони Prozorro.Sale
Prozorro.Sale відкликає permissions для Майданчика щодо конкретного напрямку, наприклад:
"landRental-english": []
Синхронізація permissions
Під час чергової синхронізації (о 05:00) Майданчик отримує оновлений перелік доступів із endpoint
Виявлення змін
Система Майданчика фіксує, що для landRental-english більше немає дозволів:
ні на створення процедур (procedure)
ні на подання заявок (bids)
Деактивація функціоналу
Майданчик автоматично:
приховує можливість створення нових процедур landRental-english
блокує подання нових заявок на участь у таких процедурах
Майданчик продовжує мати можливість працювати з раніше опублікованими Процедурами цього напрямку і з раніше створеними Бідами |
Майданчик більше не надає функціонал для відповідного напрямку. Робота з цією процедурою припиняється без необхідності ручного втручання.
Майданчик успішно пройшов тестування по роботі з Обʼєктами приватизації (Asset), Інформаційними Повідомленням (Announcement, Redemption) та процедури у тестовому середовищі Prozorro.Sale та подав заявку на отримання відповідних доступів (permissions)
Видача доступів
Після обробки заявки зі сторони Prozorro.Sale Майданчику надаються permissions для:
роботи з Обʼєктами приватизації
"registry":{
"asset":[
"object"
]
} |
роботи з Інформаційними Повідомленнями та Викупом
"jobber":{
"announcement":[
"object"
]
} |
роботи з новою процедурою. Результатом виконання буде, наприклад:
"procedure":{
"smallPrivatization-english":[
"bids"
]
} |
Реліз на стороні Майданчика
Майданчик розгортає на Prod свою протестовану версію функціоналу, але не активує можливість:
створювати Обʼєкти Приватизації, ІП, Обʼєкт Викупу та Процедури Приватизації
подавати заявки на участь у таких процедурах
Синхронізація permissions
О 05:00 відбувається автоматична синхронізація доступів із endpoint Prozorro.Sale
Отримання актуальних прав доступу
Endpoint повертає перелік дозволених напрямків і ролей
Активація функціоналу
На основі отриманих permissions Майданчик автоматично:
вмикає можливість створення сутностей Приватизації
відкриває можливість подання заявок для Учасників
Для роботи з напрямком Приватизації (Малої і Великої) Майданчику потрібно
Це дозволить Майданчику публікувати Обʼєкти Приватизації в реєстр, але не дозволись створювати Інформаційні Повідомлення або обʼєкти Викупу
Це дозволить Майданчику публікувати Інформаційні Повідомлення Малої чи Великої Приватизації
Це дозволить Майданчику публікувати обʼєкти Викупу Малої чи Великої Приватизації
Це дозволить Майданчику публікувати Заяви на участь для раніше створених процедур Малої чи Великої Приватизації !!! Ручного створення Процедур в напрямку Приватизації не відбувається, тому Майданчикам не видається permission procedure.{{procedure_type}} - "procedure" |
Назва | Отримання permissions з системного endpoint |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Отримано відповідь endpoint або зафіксовано помилку |
Інші вимоги | Endpoint викликається планово (наразі 1 раз на добу о 05:00) |
Назва | Отримання та локальне збереження permissions |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Майданчик має локально доступний перелік permissions GET /api/platform/cdb/status |
Інші вимоги | - |
Назва | Валідація структури та цілісності permissions |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Permissions визнані валідними або невалідними |
Інші вимоги | - |
Назва | Визначення права організатора на оголошення аукціонів |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Організатор може або не може створювати аукціони |
Інші вимоги | Логіка повинна застосовуватись для кожного напрямку окремо |
Назва | Визначення права користувачів на подання заявок |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Учасник може або не може подати заявку |
Інші вимоги | Має узгоджуватись з UI |
Назва | Визначення доступу до оголошення JAS (Інформаційного повідомлення) |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до SP* процедур дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до внесення об’єктів до реєстру Малої приватизації |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до створення execution Малої приватизації |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до створення redemption Малої приватизації |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до оголошення JAL (Інформаційного повідомлення) |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення JAL дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до внесення об’єктів до реєстру Великої приватизації |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до створення executionВеликої приватизації |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до створення redemption Великої приватизації |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до внесення об'єктів до реєстру оренди |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до створення Дій до об'єктів реєстру оренди |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Визначення доступу до створення Заяв до об'єктів реєстру оренди |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Доступ до створення об'єктів реєстру дозволено або заборонено |
Інші вимоги |
|
Назва | Керування UI відповідно до permissions |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Користувачі бачать лише дозволений функціонал |
Інші вимоги | UI та API мають бути синхронні |
Назва | Ескалація проблем з permissions |
| Актори |
|
Передумови |
|
Основний хід подій (дій) |
|
Альтернативні шляхи, помилки, крайові випадки |
|
Результат (Постумови) | Причина відсутності permissions з’ясована |
Інші вимоги | Всі звернення мають трасуватись |