Коробковий Redmine має досить гнучку систему запитів. Завдання можна фільтрувати практично по всіх полях, вибираючи потрібні, групувати вивід і сортувати результати.
Зіткнувшись з використанням Redmine як єдиного інформаційного середовища в компанії, ми дійшли висновку, що стандартний функціонал запитів використовувати не зовсім зручно.
Перша причина - це велика загальна кількість запитів.
Розгалужені життєві цикли і різні типи завдань обумовлюють необхідність досить великої кількості збережених запитів. Як наслідок, бічна панель перетворюється на купу погано різноманітних посилань.
Що ми зробили
Написали невеликий плагінчик Redmine Extra Queries, який спрощує роботу із запитами завдань.
У ньому реалізували функцію розбивки збережених запитів за категоріями. Це допомогло систематизувати запити, і ми досить довго жили з цим, але загальної проблеми не вирішило. Середньостатистичний користувач лякає вибору потрібного посилання з великої кількості запитів, тому ми реалізували можливість закріплення найважливіших запитів на бічній панелі зверху, а решта сховали.
Адміністратор Redmine може закріпити найважливіші запити всім користувачам і відсортувати їх перетягуванням миші. Кожен користувач може закріпити потрібні особисто йому запити. Таким чином, ми мінімізували кількість посилань на бічній панелі, залишивши можливість отримувати доступ до більш рідкісних запитів у разі необхідності.
Інтерфейс фільтрування завдань і збереження запиту в Redmine різний (не зовсім зрозуміло чому?!). Причому, останній представляє собою пекельну форму.
Пекельна форма збереження запиту
Ми об'єднали два інтерфейси в один і мінімізували його.
Користувач може спочатку налаштувати фільтри, потім проконтролювати результат фільтрації і тут же зберегти запит.
Завжди можна подивитися за якими параметрами відфільтровані завдання.
Чомусь поля зі списком значень в Redmine не сортуються за алфавітом. З часом завдання та інші сутності обростають великою кількістю налаштовуваних полів, що приводить процедуру вибору потрібного значення у спадному списку до квесту за перебором значень.
Ми відсортували значення у всіх полях і додали функцію пошуку по підрядку, щоб умови фільтрації можна було задавати швидше.
Як ми використовуємо запити завдань в Redmine.
Ну зрозуміло, що використовуємо за прямим призначенням (оскільки це задумано розробниками). Зберігаємо запити, щоб користувач міг швидко знайти потрібні йому завдання. Але ще ми застосовуємо їх повсюдно для різних налаштувань.
Наприклад, у нас є плагін «Unread issues», який дозволяє відображати зелений і синій кружечок з кількістю непрочитаних завдань. Зелений, коли користувач зовсім не читав завдання і синій - коли читав, але з моменту прочитання в завданні щось змінилося.
Цей же плагін робить посилання з кружечками-лічильниками в топ-меню на мою сторінку. Кружечки показують сумарну кількість непрочитаних завдань, призначених на користувача.
Програмісту періодично доводилося переписувати запит, що відповідає за підрахунок лічильників. Потім ми ввели налаштування, яке визначало на основі якого запиту завдань вважати лічильники непрочитаних завдань.
Проблема відразу пішла, тепер адміністратор може швидко змінити запит завдань, скориставшись стандартними широкими можливостями фільтрації, і лічильники будуть рахуватися на основі оновленого запиту автоматично.
Потім ми застосували цю ж концепцію в масі інших місць:
Вибірка завдань в оперативний план (про оперативне планування я писав раніше) будується на основі звичайного запиту завдань. Це дозволяє адміністратору гнучко переналаштовувати умови, за якими завдання потрапляє в оперативний план.
На основі запиту завдання потрапляють у певну колонку WIP-діаграми (Scrum-дошки)
На основі будь-якого запиту завдань можна створити блок на моїй сторінці. Стандартний Redmine має обмежений набір блоків, вибірка завдань для блоків вшита в код.
Ну і так далі, ми використовуємо стандартні запити завдань повсюдно, коли потрібно визначити вибірку завдань, яка повинна відображатися в якомусь місці.
Таке архітектурне рішення дає дивовижну гнучкість у налаштуванні системи і позбавляє програмістів від купи рутинної роботи з переписування запитів.
Сподіваюся, стаття і плагіни будуть корисні.