Мета

Сервіс додавання додаткової інформації створений для можливості внесення змін у будь-яку процедуру, в не залежності від її статусу співробітником АТ Прозоро.Продажі

Документація

• BRD BRD. Внесення додаткових даних у ЕТС в незалежності від статусу процедури
• ТЗ для адміністративної частини Створення/редагування додаткової інформації до процедури [Add/Edit additional information commands]

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

User Stories

Вимоги до процедури в ЦБД

Acceptance criteria

1. Має бути реалізовано модель у якій можна зберігати дані про додаткову інформацію у процедурі
2. Додавання та редагування даних моделі має відбуватись через адміністративну частину ЦБД (командою)
   1. Доступ до створення запису, чи зміни має бути реалізовано окремою роллю (User permisssion) на стороні адміністративної частини ЦБД
   2. Має бути реалізована історія змін запису, і доступний її перегляд
      1. Має фіксуватись Дата змін, Команда, яка була виконана і Автор, що виконав цю команду (користувач адміністративної частини ЦБД)
3. До однієї процедури може бути додано більше ніж один запис про додаткову інформацію
4. Створити або редагувати запис в моделі можливо у будь-який час (в не залежності від періоду та статусу поточної процедури).
5. При додаванні чи зміні запису в моделі дата останньої зміни процедури - залишається без змін.
   1. При цьому "Дата створення", "Дата змін" запису моделі створюється/оновлюється.
6. Запис ДІ має містити певну кількість параметрів і файли
   1. Опис параметрів наведено нижче (див. таблицю)
   2. Вимоги до файлів:
      1. Файли мають зберігатись в файловому сховищі ЦБД (Document service) після того, як успішно пройдуть перевірку на загрози.
      2. Типи даних (файлів) - не обмежені (стандартні вимоги до файлів в ЦБД)
      3. Розмір файлів - обмежений  у 50 Мб для файлу не обмежені (стандартні вимоги до файлів в ЦБД)
      4. Перед завантаженням файлів у файлове сховище має виконуватись антивірусна перевірка файлів на наявність вразливостей:
         1. Має бути реалізована асинхронна перевірка файлів, що завантажуються 
            1. Флоу: Завантажити файл → Перевірка (асинхронна) на наявність вірусів → повідомлення про результат перевірки (емейл) → Завантаження в ЦБД/Попередження про неможливість завантаження
               1. Для виконання антивірусної перевірки файлів можна використати стороннє open source рішення ClamAV (https://docs.clamav.net/Introduction.html)
            2. Якщо всі файли перевірені і в них не виявлено загроз - відбувається публікація ДІ в ЦБД
            3. Якщо перевірка виявила хоча б один файл, що містить загрозу - публікація в ЦБД не відбувається, файл, що містить загрозу переноситься в Карантин.
            4. На емейл-адресу користувача, що виконував команду система формує і надсилає лист, що містить інформацію про статус виконання команди
               1. При успішному виконання команди: "Вітаємо, команда по створенню/зміні додаткової інформації до аукціону [Ідентифікатор запису зв'язаного аукціону], була успішно виконана."
               2. При не успішному виконанні:  "Вітаємо, команда по створенню/зміні додаткової інформації до аукціону [Ідентифікатор запису зв'язаного аукціону], не була виконана. Помилка [код помилки], [опис помилки]"
      5. Запис у моделі може містити опис та один, або кілька файлів (кількість необмежена).
7. Команди, що виконуються на стороні ЦБД для роботи з ДІ
   
   1. Створити
   2. Редагувати
   3. Виконати перевірки
   4. Скасувати команду
8. Максимальна вага тіла будь-якого запиту - 50 Мб (якщо запит більший за 50 Мб - помилка 413 з перевищенням тіла запиту)
9. Структура даних прописана нижче:

Можливість приховання документів ДІ

Через Адмінку ЦБД є можливість змінювати scope (public <=> private) документа ДІ.

Токен зміненого документа логується в адмінці ЦБД так як це працює зараз з документами Процедури (в логах зміни scope Адміністратор ЦБД може побачити url на документ з Токеном до цього документа).

Власник Процедури, не маючи Токена private документа ДІ, не має можливості завантажувати/переглядати private документ ДІ. (endpoint */documents/{doc_id}/download  НЕ реалізовуємо для ДІ)

В Адмінці ЦБД інтерфейс команди зміни scope для документа ДІ має давати можливість адміністратору вказати:

• procedure._id
• Link на документ ДІ для якого треба змінити scope
• New Scope
• Reason
• Дата і час виконання запиту (автоматично)
• id адміністратора, який виконує запит (підтягується автоматично)
• Command result (стандартна існуюча логіка)

Для зміни scope використовуємо стандартну існуючу команду Move procedure document commands

Історія змін ДІ (Архів ДІ)

Кожна зміна у Процедурі ініціює створення копії Процедури перед її оновленням. Так як при оновленні полів/документів ДІ сам обʼєкт Процедури не змінюється, є необхідність створити окремо Архів змін ДІ.

Необхідно розробити функціонал, що дозволить підтримувати історичність змін, що відбуваються у ДІ.

Має бути можливість по окремому endpoint отримувати історію всіх обʼєктів ДІ у форматі: {obj_1_id: [obj_1_archive_1, obj_1_archive_2], ...}

• /api/procedures/{procedure_id}/additionalInformation/history

Має бути можливість по окремому endpoint отримувати історію конкретного об'єкта ДІ у форматі [obj_1_archive_1, obj_1_archive_2, ...]

• /api/procedures/{procedure_id}/additionalInformation/{add_info_id}/history

Має бути можливість по окремому endpoint отримувати історію всіх документів по {add_info_id} у вигляді {doc_1_id: [doc_1_archive_1, doc_1_archive_2], ...}

• /api/procedures/{procedure_id}/additionalInformation/{add_info_id}/documents/history

Має бути можливість по окремому endpoint отримувати історію певного документа по {doc_id} у вигляді [doc_1_archive_1, doc_1_archive_2, ...]

• /api/procedures/{procedure_id}/additionalInformation/{add_info_id}/documents/{doc_id}/history

Якщо історія по Обʼєкту відсутня, то запит повертає пустий масив.

Якщо історія у документа, по якому виконується запит відсутня, віддавати:

"message": "Not found documents history object with id {{doc_id}}"

Вимоги до міграції даних

Повний перелік існуючої ДІ, яку необхідно мігрувати знаходиться з користувацької сторони тут

Мігрувати є можливість тільки ДІ із ЦБД3 процедур. Немає можливості змінювати моделі обʼєктів ЦБД2.

При міграції у обʼєктів Процедур необхідно оновити systemDateModified, щоб Процедури потрапили в Mirror і Майданчики оновили у себе обʼєкти з ДІ

Acceptance criteria

1. Має бути реалізована міграція існуючих даних із "Додаткова інформація" порталу Прозоро.Продажі у ЦБД
2. Міграція має бути виконана автоматичною системою (не вручну переносити із БД Порталу)
3. Мапінг полів при міграції:

Приклади оголошень з ДІ на порталі Прозоро.Продажі

Локація: Портал Прозоро.Продажі (https://prozorro.sale/) → Аукціон→ Блок "Додаткова інформація"

BRE001-UA-20230518-79594
LLP001-UA-20230410-88502
LSP001-UA-20230407-03951
SPE001-UA-20230517-74896
LSE001-UA-20230427-30844
SPD001-UA-20230522-97850
SPE001-UA-20230417-34421
UA-PS-2022-01-27-000033-2
LSE001-UA-20230418-52681
SPE001-UA-20230422-43215
LRE001-UA-20230308-97678
SPE001-UA-20230505-76007
LRE001-UA-20230320-94476
UA-PS-2021-09-05-000005-2
LRE001-UA-20230321-02622
LSE001-UA-20230323-88980
LSP001-UA-20230203-46720
LSP001-UA-20230310-26569
SPE001-UA-20230302-16833
UA-PS-2021-11-24-000020-1
BSE001-UA-20230301-79169
SUE001-UA-20230223-49035
SPE001-UA-20230302-85727
SPE001-UA-20230217-49301

Вимоги до API

Acceptance criteria

1. Записи моделі "Додаткова інформація" мають бути доступні в API Прозоро.Продажі на читання
2. Майданчики-партнери та портал Прозоро.Продажі мають мати можливість “забрати” інформацію моделі "Додаткова інформація" по конкретній процедурі для подальшого відображення на своєму майданчику/порталі.
3. Майданчики-партнери та портал Прозоро.Продажі мають мати можливість “забрати” оновлення інформації про вже існуючий запис в моделі "Додаткова інформація"
4. Необхідно врахувати, можливість в подальшому надати можливість майданчикам-партнерам публікувати (створювати) та редагувати записи моделі "Додаткова інформація" на своїй стороні і передати ці записи в ЦБД:
   1. Створення нових записів ДІ до оголошень
   2. Редагування існуючих записів ДІ (окрім редагування файлів)
5. BI Прозоро.Продажі має мати можливість “забрати” інформацію про наявність записів моделі "Додаткова інформація" в розрізі процедур 
6. BI Прозоро.Продажі має мати можливість “забрати” оновлення інформації про вже існуючі записи в моделі "Додаткова інформація"

Вимоги до інтерфейсу порталу Прозоро.Продажі

Acceptance criteria

1. На Порталі має відображатися ДІ із API Процедури (нова реалізація) так і ДІ, що зберігаються у сховищі Порталу (стара реалізація). Тобто, треба не втратити відображення ДІ у процедурах, в яких ДІ має "стару" логіку"
2. Вимоги до пошуку на порталі по ДІ Прозоро.Продажі - відсутні
3. Посилання на опис логіки відображення на Порталі

Вимоги до BI Прозоро.Продажі

Приклад Процедури з ДІ тут

Acceptance criteria

1. Необхідно реалізувати фільтр, який дозволить відбирати Аукціони, у яких присутня ДІ (в обʼєкті присутній масив additionalInformation[] )
2. Необхідно додати фільтри, що будуть давати можливість відбирати Аукціони по наявності значення у полях:
   1. additionalInformation[].reason (Причина ДІ)
   2. additionalInformation[].initiator (Ініціатор ДІ)
   3. additionalInformation[].datePublished (Дата створення ДІ)
   4. additionalInformation[].dateModified (Дата редагування ДІ)
   5. additionalInformation[].description.uk_UA (Опис ДІ)

Необхідно звернути увагу, що Процедура може отримати зміни в procedure.additionalInfo[] навіть в термінальному статусі. Концептуально поля Процедури не змінюються, тому ми НЕ оновлюємо procedure.dateModified

Тому, якщо Ваша логіка оновлення об'єктів зав'язана на стандартному procedure.dateModified, необхідно розширити цю логіку, та також відслідковувати зміни поля procedure._meta.systemDateModified

Вимоги до інтерфейсів майданчиків

Acceptance criteria

1. Необхідно розширити/переглянути логіку синхронізації об'єктів з ЦБД: коли до Об'єкта додається/змінюється Додаткова Інформація (ДІ), то значення параметру procedure.dateModified НЕ зміниться. Об'єкт попаде в Mirror ЦБД зі зміненою датою procedure._meta.systemDateModified

Необхідно звернути увагу, що Процедура може отримати зміни в procedure.additionalInfo навіть в термінальному статусі. Концептуально поля Процедури не змінюються, тому ми НЕ оновлюємо procedure.dateModified

Тому, якщо Ваша логіка оновлення об'єктів зав'язана на стандартному procedure.dateModified, необхідно розширити цю логіку, та також відслідковувати зміни поля procedure._meta.systemDateModified

      2. На сторінці Процедури необхідно відобразити розділ з Додатковою Інформацією.

1. 1. Назва блоку - Додаткова інформація.
   2. Дані для параметрів блоку ДІ беруться безпосередньо з процедури
      1. Записи ДІ може існувати в будь-якій процедурі ЦБД
   3. Додаткова інформація (ДІ), це масив, у якому може існувати необмежена кількість записів.
   4. Додаткова інформація - не обов'язкова, тому, при відсутності записів в об'єкті, блок Додаткова інформація не відображається

     3. НЕ обовʼязкова вимога: додати відображення історії змін документів ДІ

Приклад обʼєкта з ДІ тут

Публічні для відображення поля:

• Заголовок: "Додаткова інформація"
• Опис: "{{procedure.additionalInformation[*].description.uk_UA}}
• Перелік файлів (масив): {{procedure.additionalInformation[*].documents.title.uk_UA}} + {{procedure.additionalInformation[*].documents.url}}  (!Використовуєтся стандартна модель documents)

Приклад вигляду ДІ (на Порталі): 

Довідники

Acceptance criteria

1. Значення довідників мають бути відсортовані в алфавітному порядку

* не зберігається в ЦБД.

Права доступу