Запросы задач Redmine. Как мы их усовершенствовали и как используем
Коробочный Redmine имеет достаточно гибкую систему запросов. Задачи можно фильтровать практически по всем полям, выбирая нужные, группировать вывод и сортировать результаты.
Cтолкнувшись с использованием Redmine в качестве единой информационной среды в компании, мы пришли к выводу, что стандартный функционал запросов использовать не совсем удобно.
Первая причина – это большое общее количество запросов.
Разветвленные жизненные циклы и различные типы задач обуславливают необходимость достаточно большого количества сохраненных запросов. Как следствие, боковая панель превращается в кучу плохо различимых ссылок.
Что мы сделали
Написали небольшой плагинчик Redmine Extra Queries, который упрощает работу с запросами задач.
В нем реализовали функцию разбивки сохраненных запросов по категориям. Это помогло систематизировать запросы, и мы достаточно долго жили с этим, но общей проблемы не решило. Среднестатистический пользователь пугается выбора нужной ссылки из большого количества запросов, поэтому мы реализовали возможность закрепления самых важных запросов на боковой панели сверху, а остальные спрятали.
Администратор Redmine может закрепить самые важные запросы всем пользователям и отсортировать их перетаскиванием мыши. Каждый пользователь может закрепить нужные лично ему запросы. Таким образом, мы минимизировали количество ссылок на боковой панели, оставив возможность получать доступ к более редким запросам в случае необходимости.
Интерфейс фильтрации задач и сохранения запроса в Redmine разный (не совсем понятно почему?!). Причем, последний представляет собою адскую форму.
Мы объединили два интерфейса в один и минимизировали его.
Пользователь может сначала настроить фильтры, затем проконтролировать результат фильтрации и тут же сохранить запрос.
Всегда можно посмотреть по каким параметрам отфильтрованы задачи.
Почему-то поля со списком значений в Redmine не сортируются по алфавиту. Со временем, задачи и другие сущности обрастают большим количеством настраиваемых полей, что приводит процедуру выбора нужного значения в выпадающем списке в квест по перебору значений.
Мы отсортировали значения во всех полях и добавили функцию поиска по подстроке, чтобы условия фильтрации можно было задавать быстрее.
Как мы используем запросы задач в Redmine.
Ну понятно, что используем по прямому назначению (так как это задумано разработчиками). Сохраняем запросы, чтобы пользователь мог быстро найти нужные ему задачи. Но еще мы применяем их повсеместно для различных настроек.
Например, у нас есть плагин «Unread issues», который позволяет отображать зеленый и синий кружочек с количеством непрочитанных задач. Зеленый, когда пользователь совсем не читал задачу и синий – когда читал, но с момента прочтения в задаче что-то изменилось.
Этот же плагин делает ссылку с кружочками-счетчиками в топ-меню на мою страницу. Кружочки показывают суммарное количество непрочитанных задач, назначенных на пользователя.
Программисту периодически приходилось переписывать запрос, отвечающий за подсчет счетчиков. Затем мы ввели настройку, которая определяла на основе какого запроса задач считать счетчики непрочитанных задач.
Проблема сразу ушла, теперь администратор может быстро изменить запрос задач, воспользовавшись стандартными широкими возможностями фильтрации, и счетчики будут считаться на основе обновленного запроса автоматически.
Затем мы применили эту же концепцию в массе других мест:
Выборка задач в оперативный план (про оперативное планирование я писал ранее) строится на основе обычного запроса задач. Это позволяет администратору гибко перенастраивать условия, по которым задача попадает в оперативный план.
На основе запроса задачи попадают в определенную колонку WIP-диаграммы (Scrum-доски)
На основе любого запроса задач можно создать блок на моей странице. Стандартный Redmine имеет ограниченный набор блоков, выборка задач для блоков вшита в код.
Ну и так далее, мы используем стандартные запросы задач повсеместно, когда нужно определить выборку задач, которая должна отображаться в каком-то месте.
Такое архитектурное решение дает удивительную гибкость в настройке системы и избавляет программистов от кучи рутинной работы по переписыванию запросов.
Надеюсь, статья и плагины будут полезны.
Автор: tdvsdv