Versions Compared

Old Version 10

changes.mady.by.user valeriia denysenko

Saved on

compared with

New Version 11

changes.mady.by.user Filip Kuzmin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

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

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

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

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

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

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

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

...

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

...

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

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

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

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

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

...

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

...

  1. Система повинна дозволяти:

    1. Створення Об'єкту оренди, якщо: permitionspermissions.registry.object = object

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

...

  1. Система повинна дозволяти:

    1. Створення Об'єкту Малої приватизації, якщо: permitionspermissions.registry.asset= object

    2. Створення Контракту Малої приватизації, якщо: permitionspermissions.registry.execution = object
    3. Створення Інформаційного повідомлення Малої приватизації, якщо: permitionspermissions.jobber.announcement = object
    4. Створення Викупу Малої приватизації, якщо: permitionspermissions.jobber.redemption= object
  2. В разі відсутності відсутності : permitionspermissions.jobber.announcement = object, організатор не може створити ІП та відповідно не буде автоматично створено процедуру

...

  1. Система повинна дозволяти:

    1. Створення Об'єкту Малої приватизації, якщо: permitionspermissions.registry.large_asset= object

    2. Створення Контракту Малої приватизації, якщо: permitionspermissions.registry.large_execution = object
    3. Створення Інформаційного повідомлення Малої приватизації, якщо: permitionspermissions.jobber.large_announcement = object
    4. Створення Викупу Малої приватизації, якщо: permitionspermissions.jobber.large_redemption= object
  2. В разі відсутності відсутності : permitionspermissions.jobber.large_announcement = object, організатор не може створити ІП та відповідно не буде автоматично створено процедуру

...

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

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

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

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

...

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

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

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

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

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

...

Назва

Отримання permitions з системного endpoint
Актори

  • Основний: ЕТМ (майданчик)

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

Передумови

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

  2. Endpoint доступний майданчику

  3. Є валідні облікові дані для доступу  - Наразі не актуально

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

  1. ЕТМ надсилає запит до endpoint permitionspermissions

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

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

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

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

  2. Помилка авторизації - наразі відсутня

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

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

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

Інші вимоги

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

...

Назва

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

Актори

  • Основний: ЕТМ (майданчик)

Передумови

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

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

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

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

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

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

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

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

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

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

Інші вимоги

Повинна зберігатись попередня версія permitions permissions (за потреби)

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

Назва

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

Актори

  • Основний: ЕТМ (майданчик)

Передумови

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

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

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

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

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

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

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

Інші вимоги

Результат валідації має логуватись

...

Назва

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

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

Передумови

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

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

  1. ЕТМ перевіряє permitionspermissions.procedures.<procedure_name>

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

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

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

  1. Procedure відсутня

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

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

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

  1. ЕТМ перевіряє permitionspermissions.procedures.<procedure_name>

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

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

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

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

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

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

  1. Відсутній ключ announcement

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitionspermissions.registry.asset

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

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

  1. Відсутній ключ asset

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitionspermissions.registry.execution

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

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

  1. Відсутній ключ execution

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons Permissions валідні

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

  1. Перевіряється permitionspermissions.jobber.redemption

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

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

  1. Відсутній ключ redemption

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

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

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

  1. Відсутній ключ large_announcement

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitionspermissions.registry.large_asset

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

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

  1. Відсутній ключ large_asset

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitionspermissions.registry.large_execution

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

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

  1. Відсутній ключ large_execution

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitionspermissions.jobber.large_redemption

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

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

  1. Відсутній ключ large_redemption

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitionspermissions.registry.object

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

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

  1. Відсутній ключ object

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitionspermissions.registry.action

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

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

  1. Відсутній ключ action

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

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

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

Інші вимоги

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

...

Назва

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

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitionspermissions.registry.lease_request

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

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

  1. Відсутній ключ lease_request

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

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

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

Інші вимоги

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

...

Назва

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

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

  • Другорядні: Організатор, Учасник

Передумови

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

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

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

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

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

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

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

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

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

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

Інші вимоги

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

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

Назва

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

Актори

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

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

Передумови

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

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

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

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

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

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

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

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

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

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

Інші вимоги

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