Реалізація в ЦБД
Процедури: | BSE, BSD, APE, APD |
| Хто |
|
| Передумова |
|
Дії |
|
Запит: | PATCH /api/procedures/{procedure_id} |
Валідації: |
|
Результат: |
|
Додаткові умови: | *Організатор підчас редагування може одночасно редагувати:
|
Сповіщення: | У випадку відсутності завантаження документа clarifications { |
Особливості інактивації Біда (поле inactivationDate)
Якщо протягом rectificationPeriod була змінена Процедура (PATCH), то до цієї Процедури в API response додається поле inactivationDate заповнене датою PATCH процедури ( inactivationDate == dateModified )
Якщо процедуру PATCH-ать повторно, то поле inactivationDate оновлюється новою датою і так з кожним PATCH.
Для чого це потрібно по крокам:
- Опублікували Процедуру, почався active_tendering
- Біди подали і активували заяви на участь
- Після цього Організатор відредагував Процедуру (PATCH)
- Біди отримали статус inactivate (ЦБД їм змінило статус автоматично)
- В mirror потрапила змінена процедура, але нічого про Біди в ній ще нема (public API не віддає в mirror бідів по процедурі у статусі active_tendering) і Організатор не бачить Бідів в public API.
Майданчикам Бідів треба якось зрозуміти, що їх Біди деактивувалися і оновити їм статус.
- Через mirror прилітає змінена Процедура і вони бачать, що зʼявилося поле inactivationDate. Це є тригер для того, щоб пересинхронізувати своїх Бідів і оновити їм статус active -> inactivate (На стороні Майданчика ще може надсилатися нотифікація Учаснику, що Процедура була відредагована і заява на участь деактивована)
Щоб Майданчикам кожен раз НЕ пересинхронізовувати своїх бідів, як тільки вони отримують через mirror змінену процедуру, краще завʼязуватись на inactivationDate, а не на dateModified (бо dateModified оновлюється навіть при зміних, що не є потрібними для даної ситуації (наприклад, коли до Процедури додають "запитання чи відповідь"))
Зараз Майданчикам зручно завʼязати логіку на inactivationDate і не закидувати нас постійно запитами для синхронізації Бідів.
Особливості відображення на порталі
...