Page History

...

1. Система майданчика повинна використовувати централізований endpoint permissions як єдине джерело прав доступу

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

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

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

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

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

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

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

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

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

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

Валідація

...

permissions

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

   • наявність ключа permissions;

   • наявність секцій procedures, jobber, registry (за потреби);

   • допустимі значення (procedure, bids, object).

2. У разі виявлення невалідної структури permissions система повинна зафіксувати помилку.

...

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

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

3. UI та API повинні використовувати одну й ту саму логіку перевірки permissions

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

...

permissions

1. У разі втрати або несподіваної зміни permitions permissions система EТМ повинна зафіксувати інцидент.
2. Менеджмент ЕТМ повинен мати можливість ініціювати звернення через WF (“Приватні запити”).

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

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

2. Використання permitions permissions повинно бути ідемпотентним (однакові дані → однаковий результат).
3. Логіка permitions permissions повинна бути розширюваною для нових напрямків без зміни існуючих UC.

4. Усі перевірки permitions permissions повинні логуватись для аудиту. - Чи потрібно ?

...

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

   • використовується остання валідна версія permissions;

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

2. Система не повинна надавати нові доступи без підтверджених permissions.

3. Будь-яка критична невідповідність permitions permissions повинна бути видимою для відповідальних осіб.

UseCase

Use Case 1. Отримання

...

permissions з системного endpoint

Use Case 2. Отримання та збереження

...

permissions майданчиком

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

...

permissions

...

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

...

permissions