Versions Compared

Old Version 2

changes.mady.by.user valeriia denysenko

Saved on

compared with

New Version 3

changes.mady.by.user valeriia denysenko

Saved on

Key

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

...

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

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

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

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

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

UseCase

Use Case 1.

...

Назва

...

Системні: ЕТМ (майданчик)

...

Передумови

...

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

...

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

...

  1. Майданчик надсилає запит по окремому endpointу. Наразі 1 раз на день о 5й ранку, надалі буде визначено
  2. Майданчик зчитує інформацію що виведена в endpoint 
  3. Майданчик аналізує інформацію в розділі permitions:
    1. Якщо в procedures наявна назва процедури (Приклад: subsoil-dutch) та значення procedure → тоді, мадайданчик може надати організаторам оголошувати нові аукціони за вказаним напрямком
    2. Якщо в procedures наявна назва процедури (Приклад: subsoil-dutch) та значення bids→ тоді, мадайданчик може надати потенційним учасникам (зареєстрованим користувачам) подавати заявку на участь за вказаним напрямком
    3. Для оголошення організаторами процедур за напрямком SP* та LP* необхідно перевіряти наявність permitions в частині jobber з назвою announcement/large_announcement що мають значення object
    4. Для внесення об'єктів оренди в реєстр об'єктів оренди і подальшого створення об'єктів оренди за напрямком LL* необхідно перевіряти наявність permitions в частині registry з назвою registry що мають значення object

...

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

...

  1. Якщо майданчик не бачить попередньо отриманого permitions і для цього не було якогось бізнес обгрунтування, тоді менеджмент ЕТМ потрібно звернутись через WF "Приватні запити" для уточнення ситуації

...

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

...

  1. Майданчик кешує отримані значення доступу до всіх напрямків за яким він акредитований

...

Інші вимоги

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

Назва

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

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

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

Передумови

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

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

  3. Є валідні облікові дані для доступу

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

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

  2. Центральна система повертає відповідь з permitions

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

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

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

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

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

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

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

Інші вимоги

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

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

Назва

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

Актори

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

Передумови

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

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

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

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

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

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

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

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

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

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

Інші вимоги

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

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

Назва

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

Актори

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

Передумови

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

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

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

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

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

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

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

Інші вимоги

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

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

Назва

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

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

Передумови

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

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

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

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

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

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

  1. Procedure відсутня

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

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

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

Інші вимоги

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

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

Назва

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

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

Передумови

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

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

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

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

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

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

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

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

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

Інші вимоги

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

Use Case 6. Перевірка доступу до оголошення SP* процедур

Назва

Визначення доступу до SP* процедур

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

Передумови

  1. Permitons валідні

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

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

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

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

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

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

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

Інші вимоги

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

Use Case 7. Перевірка доступу до оголошення LP* процедур

Назва

Визначення доступу до LP* процедур

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

Передумови

  1. Permitons валідні

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

  1. Перевіряється permitions.jobber.large_announcement

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

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

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

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

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

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

Інші вимоги

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

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

Назва

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

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

Передумови

  1. Permitons валідні

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

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

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

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

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

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

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

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

Інші вимоги

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

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

Назва

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

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

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

Передумови

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

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

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

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

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

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

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

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

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

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

Інші вимоги

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

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

Назва

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

Актори

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

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

Передумови

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

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

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

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

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

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

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

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

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

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

Інші вимоги

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