Table of Contents

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

Система

...

майданчика повинна використовувати централізований

...

endpoint як єдине джерело прав доступу

Усі бізнес-рішення щодо доступу до:

• оголошення процедур

...

• подання заявок

...

• роботи з реєстрами

...

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

...

• створення дій над об'єктами оренди

...

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

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

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

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

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

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

...

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

...

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

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

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 та відображення

UI майданчикаповинен динамічно відображати або приховувати функціональність відповідно до permissions

Користувачі не повинні бачити дій, які їм недоступні згідно permissions Майданчика

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

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

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

Обробка permissions не повинна впливати на продуктивність UI

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

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

...

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

• користувачі не отримують помилок UI

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

...