Запити завдань Redmine. Як ми їх удосконалили і як використовуємо


Коробковий Redmine має досить гнучку систему запитів. Завдання можна фільтрувати практично по всіх полях, вибираючи потрібні, групувати висновок і сортувати результати.

Зіткнувшись з використанням Redmine в якості єдиної інформаційної середовища в компанії, ми прийшли до висновку, що стандартний функціонал запитів використовувати не зовсім зручно.

Перша причина — це велика загальна кількість запитів.

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



Що ми зробили

Написали невеликий плагинчик Redmine Extra Queries, який спрощує роботу з запитами завдань.

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

Адміністратор Redmine може закріпити найважливіші запити всім користувачам і відсортувати їх перетягуванням миші. Кожен користувач може закріпити потрібні особисто йому запити. Таким чином, ми мінімізували кількість посилань на бічній панелі, залишивши можливість отримувати доступ до більш рідкісним запитами в разі необхідності.



Інтерфейс фільтрації завдань і збереження запиту в Redmine різний (не зовсім зрозуміло чому?!). Причому, останній являє собою пекельну форму.
Пекельна форма збереження запиту

Ми об'єднали два інтерфейсу в один і мінімізували його.
Користувач може спочатку налаштувати фільтри, потім проконтролювати результат фільтрації і тут же зберегти запит.



Завжди можна подивитися за якими параметрами відфільтровані завдання.



Чомусь поля зі списком значень Redmine не сортуються за алфавітом. З часом, завдання та інші сутності обростають великою кількістю полів, що призводить процедуру вибору потрібного значення у списку на квест по перебору значень.
Ми отсортировали значення у всіх полях і додали функцію пошуку по підрядку, щоб умови фільтрації можна було ставити швидше.



Як ми використовуємо запити завдань в Redmine.

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

Наприклад, у нас є плагін «Unread issues», який дозволяє відображати зелений і синій кружечок з кількістю непрочитаних завдань. Зелений, коли користувач зовсім не читав завдання і синій — коли читав, але з моменту прочитання в задачі щось змінилося.

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



Програмісту періодично доводилося переписувати запит, який відповідає за підрахунок лічильників. Потім ми ввели настройку, яка визначала на основі якого запиту завдань вважати лічильники непрочитаних завдань.



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

Потім ми застосували цю ж концепцію в масі інших місць:

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

На основі запиту завдання потрапляють у певну колонку WIP-діаграми (Scrum-дошки)



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

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

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

Сподіваюся, стаття і плагіни будуть корисні.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.