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

  1. Система майданчика повинна використовувати централізований endpoint як єдине джерело прав доступу
  2. Усі бізнес-рішення щодо доступу до:

    повинні базуватись виключно на даних permissions, отриманих з endpoint.

  3. Майданчик не має права надавати функціональність, яка не підтверджена наявними в endpoind permissions.

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

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

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

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

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

Валідація permissions

  1. Система повинна перевіряти цілісність структури permissions, зокрема:

  2. У разі виявлення невалідної структури необхідно передати інформацію Prozorro.Sale, наприклад, через запит в Slack Workflow

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

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

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

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

    1. Створення Об'єкту оренди, якщо: permissions.registry.object містить "object"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сценарії на прикладі

Зʼявилась нова процедура

Передумови

Майданчик успішно пройшов тестування нової процедури (наприклад, landRental-english) у тестовому середовищі Prozorro.Sale та подав заявку на отримання відповідних доступів (permissions)

Кроки

  1. Видача доступів
    Після обробки заявки зі сторони Prozorro.Sale Майданчику надаються permissions для роботи з новою процедурою. Результатом виконання буде, наприклад:

  2. Реліз на стороні Майданчика
    Майданчик розгортає на Prod свою протестовану версію функціоналу, але не активує можливість:

  3. Синхронізація permissions
    О 05:00 відбувається автоматична синхронізація доступів із endpoint Prozorro.Sale

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

    "landRental-english": [ "procedure", "bids" ]

  5. Активація функціоналу
    На основі отриманих permissions Майданчик автоматично:

Результат

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

Майданчик перестав працювати з певним одним напрямком

Передумови

Раніше Майданчик мав доступ до процедури (наприклад, landRental-english) та надавав користувачам відповідний функціонал.

Кроки

  1. Обмеження доступів зі сторони Prozorro.Sale
    Prozorro.Sale відкликає permissions для Майданчика щодо конкретного напрямку, наприклад:

    "landRental-english": []

  2. Синхронізація permissions
    Під час чергової синхронізації (о 05:00) Майданчик отримує оновлений перелік доступів із endpoint

  3. Виявлення змін
    Система Майданчика фіксує, що для landRental-english більше немає дозволів:

  4. Деактивація функціоналу
    Майданчик автоматично:

Майданчик продовжує мати можливість працювати з раніше опублікованими Процедурами цього напрямку і з раніше створеними Бідами

Результат

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

Майданчик працює з напрямком Приватизації

Передумови

Майданчик успішно пройшов тестування по роботі з Обʼєктами приватизації (Asset), Інформаційними Повідомленням (Announcement, Redemption) та процедури у тестовому середовищі Prozorro.Sale та подав заявку на отримання відповідних доступів (permissions)

Кроки

  1. Видача доступів
    Після обробки заявки зі сторони Prozorro.Sale Майданчику надаються permissions для:

  2. Реліз на стороні Майданчика
    Майданчик розгортає на Prod свою протестовану версію функціоналу, але не активує можливість:

  3. Синхронізація permissions
    О 05:00 відбувається автоматична синхронізація доступів із endpoint Prozorro.Sale

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

  5. Активація функціоналу
    На основі отриманих permissions Майданчик автоматично:

Для роботи з напрямком Приватизації (Малої і Великої) Майданчику потрібно

  • Мати permission registry.{{asset_type}} - "object"
    • де asset_type == asset OR large_asset

Це дозволить Майданчику публікувати Обʼєкти Приватизації в реєстр, але не дозволись створювати Інформаційні Повідомлення або обʼєкти Викупу

  • Мати permission jobber.{{announcement_type}} - "object"
    • де announcement_type == announcement OR large_announcement

Це дозволить Майданчику публікувати Інформаційні Повідомлення Малої чи Великої Приватизації

  • Мати permission jobber.{{redemption_type}} - "object"

Це дозволить Майданчику публікувати обʼєкти Викупу Малої чи Великої Приватизації

  • Мати permission procedure.{{procedure_type}} - "bids"

Це дозволить Майданчику публікувати Заяви на участь для раніше створених процедур Малої чи Великої Приватизації


!!! Ручного створення Процедур в напрямку Приватизації не відбувається, тому Майданчикам не видається permission procedure.{{procedure_type}} - "procedure"



UseCases

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

Назва

Отримання permissions з системного endpoint
Актори
  • Основний: Майданчик

  • Системний: ЦБД

Передумови

  1. Майданчик акредитований у системі

  2. Endpoint доступний

  3. Є валідні облікові дані для доступу  - не актуально, бо endpoints публічні

Основний хід подій (дій)

  1. Майданчик надсилає запит до endpoint permissions

  2. ЦБД повертає відповідь з permissions

  3. Дані передаються у внутрішню логіку майданчика

Альтернативні шляхи, помилки, крайові випадки

  1. Endpoint недоступний

  2. Помилка авторизації - не актуально, бо endpoints публічні

  3. Некоректний формат відповіді

Результат (Постумови)

Отримано відповідь endpoint або зафіксовано помилку

Інші вимоги

Endpoint викликається планово (наразі 1 раз на добу о 05:00)

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

Назва

Отримання та локальне збереження permissions

Актори
  • Майданчик

Передумови

  1. Успішно виконано UC-1
  2. Отримано відповідь endpoint

Основний хід подій (дій)

  1. Майданчик зчитує дані з відповіді endpoint

  2. Дані зберігаються у локальному сховищі

  3. Дані маркуються як актуальні

Альтернативні шляхи, помилки, крайові випадки

  1. Дані не збереглись

  2. Частково збережені permissions

Результат (Постумови)

Майданчик має локально доступний перелік permissions 

GET /api/platform/cdb/status

Інші вимоги

-

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

Назва

Валідація структури та цілісності permissions

Актори
  • Майданчик

Передумови

  1. Успішно виконано UC-2

Основний хід подій (дій)

  1. Майданчик перевіряє наявність ключа permissions
  2. Перевіряє обов’язкові секції (procedures, jobber, registry)
  3. Перевіряє допустимі значення (procedure, bids, object)
  4. Фіксує результат валідації

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутня секція
  2. Невідоме значення permissions
  3. Порожні permissions

Результат (Постумови)

Permissions визнані валідними або невалідними

Інші вимоги

-

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

Назва

Визначення права організатора на оголошення аукціонів

Актори
  • Основний: Майданчик
  • Другорядний: Організатор

Передумови

  1. Permissions валідні UC-3

Основний хід подій (дій)

  1. Майданчик перевіряє permissions.procedures.<procedure_name>

  2. Якщо значення procedure — доступ дозволено

  3. Функціонал створення аукціону активується

Альтернативні шляхи, помилки, крайові випадки

  1. Procedure відсутня

  2. Значення ≠ procedure

Результат (Постумови)

Організатор може або не може створювати аукціони

Інші вимоги

Логіка повинна застосовуватись для кожного напрямку окремо

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

Назва

Визначення права користувачів на подання заявок

Актори
  • Основний: Майданчик
  • Другорядний: Потенційний учасник (зареєстрований на Майданчику користувач з роллю "Учасник")

Передумови

  1. Permissions валідні UC-3

Основний хід подій (дій)

  1. Майданчик перевіряє permissions.procedures.<procedure_name>

  2. Якщо значення bids — доступ дозволено

  3. Активується можливість подання заявки

Альтернативні шляхи, помилки, крайові випадки

  1. Значення відсутнє
  2. Значення ≠ bids

Результат (Постумови)

Учасник може або не може подати заявку

Інші вимоги

Має узгоджуватись з UI

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

Назва

Визначення доступу до оголошення JAS (Інформаційного повідомлення)

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.jobber.announcement
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ announcement
  2. Значення ≠ object

Результат (Постумови)

Доступ до SP* процедур дозволено або заборонено

Інші вимоги

  • Обов’язково для напрямків SP*
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до внесення об’єктів до реєстру Малої приватизації

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.registry.asset
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ asset
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з RAS
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до створення execution Малої приватизації

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.registry.execution
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ execution
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з REL
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до створення redemption Малої приватизації

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.jobber.redemption
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ redemption
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з JRS
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до оголошення JAL (Інформаційного повідомлення)

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.jobber.large_announcement
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ large_announcement
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення JAL дозволено або заборонено

Інші вимоги

  • Обов’язково для напрямків LP*
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до внесення об’єктів до реєстру Великої приватизації

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.registry.large_asset
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ large_asset
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з RAL
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до створення executionВеликої приватизації

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.registry.large_execution
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ large_execution
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з REL
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до створення redemption Великої приватизації

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.jobber.large_redemption
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ large_redemption
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з JRL
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до внесення об'єктів до реєстру оренди

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.registry.object
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ object
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з RGL
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до створення Дій до об'єктів реєстру оренди

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.registry.action
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ action
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з RGL
  • Не застосовується до інших напрямків

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

Назва

Визначення доступу до створення Заяв до об'єктів реєстру оренди

Актори
  • Основний: ЕТМ

Передумови

  1. Permissions валідні

Основний хід подій (дій)

  1. Перевіряється permissions.registry.lease_request
  2. Якщо значення object — доступ дозволено

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутній ключ lease_request
  2. Значення ≠ object

Результат (Постумови)

Доступ до створення об'єктів реєстру дозволено або заборонено

Інші вимоги

  • Обов’язково для роботи з RGL
  • Не застосовується до інших напрямків

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

Назва

Керування UI відповідно до permissions

Актори
  • Основний: ЕТМ
  • Другорядні: Організатор, Учасник

Передумови

  1. Виконані UC-4 – UC16

Основний хід подій (дій)

  1. ЕТМ агрегує результати бізнес-UC

  2. Відображає лише дозволені дії

  3. Приховує або блокує заборонений функціонал

Альтернативні шляхи, помилки, крайові випадки

  1. Конфлікт доступів

  2. Застарілі permissions

Результат (Постумови)

Користувачі бачать лише дозволений функціонал

Інші вимоги

UI та API мають бути синхронні

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

Назва

Ескалація проблем з permissions

Актори
  • Основний: Менеджмент ЕТМ

  • Системний: WF (“Приватні запити”)

Передумови

  1. Виявлено аномалію permissions

Основний хід подій (дій)

  1. ЕТМ фіксує невідповідність

  2. Менеджмент ініціює звернення у WF

  3. Очікується роз’яснення або корекція

Альтернативні шляхи, помилки, крайові випадки

  1. Відсутня відповідь

  2. Підтверджена бізнес-зміна

Результат (Постумови)

Причина відсутності permissions з’ясована

Інші вимоги

Всі звернення мають трасуватись