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

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

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

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

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

User stories

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

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

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

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

meta: [
		{
		directions:[ 
				{
				name: commercialSell
				},
				{
				name: parking
				}
			],
			readOnly: true
		},
		{
		subdirections:[
				{
				name: amber
				},
				{
				name: customs
				}
			],
			readOnly: false
		}
	]

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

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

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

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

Directions

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

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

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

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

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

Auction type

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

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

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

Subdirections

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

Для 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 == 14360570, також є subdirection saltwater, для якого прописано фільтр items.classification.id == 77700000-7. В такому випадку для всіх процедур з зазначеним ЄДРПОУ буде додано subdirection fish, а для процедур з класифікатором 77700000-7 буде додано subdirection saltwater. 

Створення subdirection

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

Приклади

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