Мета інформація процедури

Загальна інформація

Цей функціонал необхідний для покращення категоризації процедур, розширення можливостей пошуку процедур за певними критеріями без використання довгих та складних query запитів. В межах даного функціоналу буде додано масив мета-даних в процедуру. Дане поле може бути автогенерованим, може бути змінено через панель адміністратора, може бути заповнено вручну при створенні процедури.

Мета-дані допоможуть у вирішенні бізнесових запитів на вибірку процедур за певними параметрами, які в самій процедурі явно не зазначені. Наприклад, "термінальний статус". Хоча ми і розуміємо бізнесово, що є термінальний статус (статус, який є кінцевим для процедури, незворотнім), система не знає, що таке термінальний статус. Тому коли у бізнеса виникає потреба відобразити всі процедури в термінальних статусах, ми маємо перелічувати необхідні статуси по кожному типу процедури. Таким чином, додавши "термінальний статус" в мета-дані процедури, ми зможемо вирішити це питання як з процедурами, які наразі є в БД, так і з процедурами, які буде створено в майбутньому. 

Таким чином можливо вирішувати і категоризацію процедур за необхідності. 

User stories

1. Як адміністратор, я хочу щоб мета-дані генерувалися автоматично в залежності від заданих умов, щоб в процедуру було додано точні і релевантні значення без необхідності ручного втручання. 
2. Як адміністратор, я хочу мати можливість додавати мета дані в процедуру, щоб доповнювати мета-дані необхідними значеннями у випадку відсутності автогенерованих значень.
3. Як адміністратор, я хочу мати можливість редагувати мета дані, щоб змінювати їх вручну на більш точні та релевантні.
4. Як адміністратор порталу, я хочу налаштовувати напрямки роботи згідно мета даних, щоб 
5. Як користувач порталу, я хочу мати можливість шукати процедури по напрямку роботи в мета-даних, щоб швидко і точно знаходити необхідні мені процедури. 
6. Як учасник аукціону, я хочу мати можливість знаходити аукціони згідно мета-даних, щоб швидко і точно знаходити необхідні мені аукціони.

Структура мета-даних

В процедури необхідно додати масив meta: [] .

Даний масив буде в собі містити логіку мета-даних. Наприклад:

meta: [
		{
		directions:[ 
				{
				name: basicSell
				}
			]
		},
		{
		subdirections:[
				{
				name: freshwater,
				parent: fish
				}
			]
		},
		{
		auctionType:[
				{
				name: english
				}
			]
		}
	]

Тобто таким чином, мета-дані містять в собі різного типу інформацію, яка буде додаватись згідно  бізнес-потреб.

Структурно мета-дані є масивом, який містить в собі дані різного типу. Кожен окремий тип даних додається згідно запиту від бізнеса.

Наприклад, є запит додати в мета-дані directions. Ми створюємо задачу на додавання в мета-дані directions. В задачу входить:

1. Описати структуру мета-даних.
2. Описати логіку автоматичного додавання мета-даних в процедури. 
3. Описати чи потрібна можливість редагувати ці дані вручну (чи потрібно додавати команди в адмінку)
4. Описати чи потрібно проводити міграцію процедур (чи ми хочемо присвоїти старим процедурам мета-дані згідно описаної логіки)
5. Описати де буде використано додані мета-дані.

Directions

Першим, що має бути додано в мета-інформацію - напрямки роботи. Напрямки роботи наразі використовуються на порталі для групування та пошуку процедур. Напрямки роботи розподіляються згідно sellingMethod в процедурі. Необхідно додати дану логіку до процедур. 

Список напрямків робот на параметри, за якими потрібно додати напрямки робот до процедур:

За правилами вище необхідно додати в мета-дані процедури directions.

У однієї процедури може бути декілька directions. 

Не потрібно робити можливість обирати direction вручну організатором / майданчиком. Для панелі адміністратора необхідно додати команду зміни directions. 

Панель адміністратора

В панелі адміністратора необхідно реалізувати можливість редагувати directions для процедур. Для цього потрібно використати стандартний пошук процедур як в інших командах. 

Необхідно відобразити наступні поля: 

1. Поточні directions. Якщо його немає, відобразити порожнє значення. 
2. Причину редагування (має бути записана в логи)
3. created at
4. created by

Також має бути можливість додавати directions. Пропоную зробити в такому вигляді: 

Таким чином можна буде керувати directions в процедурі. 

У процедури не може не бути direction. Тобто на спробу користувача повністю видалити всі directions необхідно відобразити помилку. 

Auction type

Для того, щоб скоротити логіку в шаблонах на порталі, необхідно додати в мета інформацію тип аукціона:

У однієї процедури може бути тільки один auctionType. 

Не потрібно робити можливість обирати auctionType вручну. Для панелі адміністратора необхідно додати команду зміни auctionType. 

Панель адміністратора

В панелі адміністратора необхідно реалізувати можливість редагувати auctionType для процедур. Для цього потрібно використати стандартний пошук процедур як в інших командах. 

Необхідно відобразити наступні поля: 

1. Поточний auctionType. Якщо його немає, в такому випадку відобразити порожнє значення. 
2. Причину редагування (має бути записана в логи)
3. created at
4. created by

Також має бути можливість додавати auctionType. Пропоную зробити в такому вигляді: 

Таким чином можна буде керувати auctionType в процедурі. Якщо значення порожнє, відобразити "select" як плейсхолдер. Якщо користувач щось обирає, в подальшому у користувача не має бути можливості повернутися назад до стану плейсхолдера. 

У процедури не може не бути auctionType. 

Subdirections

Піднапрямки роботи. Ще один елемент мета-даних в процедурі, який відповідає за визначення піднапрямків роботи. Покликаний вирішити проблему запуску продажу різних типів майна на базі інших процедур. Наприклад, на базі процедури BSE продаються парковки, на базі процедури LRE здаються в суборенду земельні ділянки через Зембанк. 

В одній процедурі може бути декілька subdirections. 

Для subdirections необхідно додати опціонально можливість організатору обирати піднапрямок роботи. 

Панель адміністратора (керування безпосередньо subdirections, не зв'язок з процедурою)

Ключова відмінність від direction та auctionType є те, що subdirections мають налаштовуватись через панель адміністратора. 

Загальний процес: 

1. Новий subdirection створюється через панель адміністратора.
2. Для нового subdirection вказуються параметри, за якими необхідно додавати його до процедур
3. Зберігаються зміни
4. Через розробку додається логіка в код, за якою subdirection буде додаватися до процедур.
5. Якщо subdirection необхідно додати до вже існуючих процедур, в такому випадку міграції будемо виконувати через окрему задачу на розробку. 

Створення subdirection

Для створення subdirection необхідно вказати наступні параметри: 

1. name
2. description (має додаватись в словник)
3. додати фільтра для процедур
   1. обрати тип фільтру (and / or)
   2. поле з процедури для фільтрації
   3. Matching
      1. Equal
      2. Not equal
      3. Regexp
      4. Contain
      5. Not contain
   4. value
4. parent subdirection

В рамках одного subdirection можна додати декілька фільтрів. Так само в рамках одного фільтра можна задати декілька параметрів. По аналогії з налаштуванням відображення даних на порталі. 

Parent subdirection - для того, щоб мати можливість створювати декілька рівнів вкладеності, необхідно надати можливість при створенні обирати батьківський subdirection. Реалізація по аналогії з категоріями в функціоналі довіднику. 

Якщо у subdirection є parent, в такому випадку має застосовуватись логіка не тільки самого subdirection, але і батьківського.

Наприклад, маємо два subdirection: fish, де прописано фільтр sellingEntity.identifier.id == 37472282, також є subdirection saltwater, для якого прописано фільтр items.classification.id == 77700000-7. В такому випадку для всіх процедур з зазначеним ЄДРПОУ буде додано subdirection fish, а для процедур з класифікатором 77700000-7 буде додано subdirection saltwater. 

Редагування subdirection

Необхідно додати можливість редагувати subdirection, який було створено.

Для редагування мають бути доступні наступні поля: 

1. name
2. description
3. фільтра
4. parent subdirection

Після редагування зробити міграцію потрібно лише за наявності задачі на розробку. Якщо цього не прописано, в такому в задачі буде прописана лише зміна логіки згідно відредагованим параметрам в адмінці. 

Приклади

Приклади було взято з білінгу, порталу. 

name		Data extraction path	Matching	value	опис в dict
fish		procedure.sellingEntity.identifier.id	==	37472282	Продаж майна "Державного агентства меліорації та рибного господарства України"
	saltwater	items.classification.id	==	98361000-1	Продаж права на укладення договору користування на умовах оренди акваторією для цілей морської аквакультури
	freshwater	items.classification.id	==	77700000-7	Продаж права використання водних біоресурсів (прісної води)
privatbank		procedure.sellingEntity.identifier.id	==	14360570	Продаж майна Приватбанку
UZ		procedure.sellingEntity.identifier.id	==	40075815	Продаж майна Укрзалізниці
metalRepository		procedure.sellingEntity.identifier.id	==	30438549	Продаж майна "Державного сховища дорогоцінних металів і дорогоцінного каміння України"
customs		procedure.sellingEntity.identifier.id	in	43333459 43337207 43350935 43332958 43348711 43335608 43336287 43337359 43350542 43333684 43332675 43332555 43350888 43971359 43971343 43958385 43946385 44029605 43997555 44030626 44005631 43971371 44017631 43958370 44005668	Митний аукціон
NBU		procedure.sellingEntity.identifier.id	==	00032106	Продаж від НБУ
NPL		procedure.sellingEntity.identifier.id	in	09302607 09303328 09305480 09334702 09311380 09312190 02760363 09336500 09323408 09304612 09325703 09326464 09328601 09331508 09333401 09337356 09338500 09351600 02766367 09315357 02767059 09356307 09353504 00032112 00032129 23697280	Продаж майна та непрацюючих кредитів держ банків
SAR		procedure.sellingEntity.identifier.id	==	37472392	Продаж майна "Державного агентства  резерву України"
FGVFO		procedure.sellingEntity.identifier.id	in	38591533 19364584 33305163 23926846 37176171 14351016 38619024 19364259 38061253 22906155 20050951 05839888 35574578 36406512 35264721 20305925 36470620 09807856 21593719 19361746 26287625 20017340 22932856 36964568 13486837 34047020 20028816 24262992 23478833 24191588 20929956 20057663 19019775 24214088 19356840 14371869 36335426 19357762 20025456 21666051 20971504 35894495 19388768 21536532 09806437 19017842 34353904 26549700 20717958 14291780 37987811 33972230 13881479 19357516 37731532 09322299 13550848 35863708 26051650 24425738 26253000 20015529 34693790 26444836 14366762 19358767 19024948 20058668 20046323 19233095 14358604 21574573 14360386 19357489 14360721 26475516 19454139 34817907 38514375 35371070 26253023 26254732 33308489 20026740 14359319 19361982 20041917 20935649 23362711 38770082 34540113 14349442 39037656 21708016 19361386 33299878 20966466 20280450 37716841 09804119	Продаж майна банківських установ, які знаходяться в управлінні ФГВФО
parkinglots		items.classification.id	==	63712400-7	Паркувальні послуги
landbank		procedure.sellingEntity.identifier.id	==	44248443	Передача землі в суборенду від Зембанку

Панель адміністратора (редагування в зв'язку з процедурою)

В панелі адміністратора необхідно реалізувати можливість редагувати subdirections для процедур. Для цього потрібно використати стандартний пошук процедур як в інших командах. 

Необхідно відобразити наступні поля: 

1. Поточні subdirections. Якщо їх немає, в такому випадку відобразити порожнє значення. 
2. Причину редагування (має бути записана в логи)
3. created at
4. created by

Також має бути можливість додавати subdirections. Пропоную зробити в такому вигляді: 

Тобто враховуючи вкладені списки реалізація має бути аналогічною до реалізації дерева класифікаторов. Але при цій реалізації, якщо користувач обирає батьківський subdirections, не мають обиратися діти. 

Таким чином можна буде керувати auctionType в процедурі. Якщо значення порожнє, відобразити "select" як плейсхолдер. 

У користувача має бути можливість повністю прибрати всі subdirections з процедури.