Дані / Розріз / Фільтр: Орган управління

[ndrhzn]

Для проєктів нам потрібно відображати інформацію про "Орган управління". Оскільки напряму ця інформація не міститься у самому проєкті, нам потрібно виводити, хто є органом управління для проєкту, з інформації про ініціатора проєкту.

Для цього, маючи ідентифікатор ініціатора, ми можемо звернутися із ним до companies endpoint (або ж можемо завантажити всі компанії з цього endpoint та працювати з табличною репрезентацією), і перевірити, чи має організація з цим ідентифікатором властивість memberOf.

Властивість memberOf вказує на parent element для запитуваної організації. Тобто на те, кому підпорядковується обрана організація. Якщо у обраної організації немає властивості memberOf, тоді вона і є органом управління. Якщо у неї є властивість memberOf, тоді вона є дочірньою організацією, а органом управління є та організація, якій вона підпорядковується.

Тут є два нюанси

• В організацій цілком може бути декілька рівнів ієрархії - принаймні теоретично. На практиці, здається, наразі є лише два
• У проєкті може бути декілька ініціаторів. В цьому разі не одразу зрозуміло, від якого з них є сенс відбудовувати ієрархію

Скажімо, є реальний проєкт 231023-9DADF130, у котрого два ініціатора - Департамент економічного розвитку Запорізької міської ради (UA-EDR-37573157) та Запорізька міська рада (UA-EDR-04053915). Цей кейс відносно простий, оскільки Запорізька міська рада є органом управління для Департаменту економічного розвитку Запорізької міської ради.

Втім, є і складніші випадки. Наприклад, у проєкті 050923-8B098754 є два ініціатори - Київська обласна військова адміністрація (UA-EDR-00022533) та Бородянська селищна рада Київської області (UA-EDR-04363662). У цьому випадку жодна з організацій не має властивості memberOf, в такому разі вони обидві за нашою методикою можуть вважатися органом управління для проєкту.

В такому разі слід прояснити

• Чи може бути у проєкту два органи управління
• Якщо не може бути, то якій з організацій надавати перевагу в алгоритмі відбору органу управління

[ndrhzn]

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

Втім, відображати такі проєкти двома окремими рядками (один рядок для кожного ініціатора) теж не видається доречним.

Чи ми можемо в такому разі в одній комірці таблиці відображати обох ініціаторів через кому? І так само зробити із органами управління? Тобто конкатенувати назви ініціаторів / органів управління?

Видається, що технічно це можливо (ми наче подібну трансформацію застосовуємо до змінної "Стратегічні документи"), але питання в тому, наскільки це буде заторкати, наприклад, роботу фільтрів? @andrzejbeletsky

[andrzejbeletsky]

Доброго.
Якщо законкатенувати Ініціаторів в проєктах, то треба в таблиці також конкатенувати "Тип ініціатора", "Орган управління", "Тип органу управління" - вони всі пов'язані між собою.
Так?

[ndrhzn]

Хм, good point. Думаю, в такому разі треба конкатенувати всі повʼязані змінні теж. Це далекий від ідеального варіант, але в якості тимчасового рішення може бути

[andrzejbeletsky]

Take a look.
Фільтри продовжують відображати їх поокремо..

[ndrhzn]

Наче все добре, дякую Тільки, коли застосовуєте конкатенацію, додавайте пробіл після коми (розділювач не ",", а ", ")

[ndrhzn]

Знайшов одну проблему з конкатенацією

Які тут можливі варіанти рішення? Наприклад

• Якщо є два N/A, показувати лише одне N/A
• Якщо з двох значень лише одне N/A, показувати тільки те, що не N/A

Чи має це сенс і чи можливо це зробити?

[ndrhzn]

В контексті підготовки модулів, котрі стосуються органів управління, нам потрібно трохи змінити / вдосконалити методику визначення органів управління.

Наша оригінальна методика полягала в тому, щоби перевіряти, якій організації підпорядковується ініціатор проєкту. В процесі консультацій ми встановили випадки, коли звʼязок органу управління з проєктом може бути не лише через ініціатора проєкту, але й через виконавця.

Таким чином, ми можемо стверджувати, що орган управління може мати стосунок до проєкту в декілька способів

• Орган управління є ініціатором проєкту
• Орган управління звʼязаний з ініціатором проєкту
• Орган управління звʼязаний з виконавцем проєкту

Отже, у рамках цього нового підходу, нам потрібно змінити алгоритм визначення органу управління для проєкту, і фіксувати не лише звʼязок, але й характер звʼязку.

Ця зміна потенційно заторкає всі елементи (таблиці, графіки, фільтри), де використовується елемент "орган управління". Тому додатково потрібно буде застосовувати зміни обережно, аби нічого не зламати в процесі на публічному додатку.

Що ви про це думаєте? Чи є якісь зауваги щодо нової методики? @a-radik @andrzejbeletsky

[andrzejbeletsky]

Реалізовано