Redmine task requests. How we improved them and how we use them

Boxed Redmine has a fairly flexible query system. Tasks can be filtered by almost all fields, selecting the ones you need, grouping the output and sorting the results.

Faced with the use of Redmine as a unified information environment in the company, we concluded that the standard query functionality is not very convenient to use.

The first reason is the large total number of requests.

Extensive life cycles and various types of tasks necessitate a sufficiently large number of stored queries. As a result, the sidebar turns into a bunch of poorly visible links.
')


What we did

They wrote a small plugin Redmine Extra Queries , which simplifies the work with task requests.

It implemented the function of breaking down the saved queries into categories. This helped to systematize requests, and we lived with it for a long time, but did not solve the common problem. The average user is frightened of choosing the right link from a large number of requests, so we implemented the ability to pin the most important requests to the sidebar from the top, while the others were hidden.

Redmine administrator can pin the most important requests to all users and sort them by dragging the mouse. Each user can assign the necessary personal requests. Thus, we minimized the number of links in the sidebar, leaving the opportunity to access more rare requests if necessary.



The interface for filtering tasks and saving a request in Redmine is different (it’s not quite clear why ?!). Moreover, the latter is a hellish form.

We combined the two interfaces into one and minimized it.
The user can first set up filters, then monitor the result of the filter and immediately save the query.



You can always see by what parameters the tasks are filtered.



For some reason, the fields with a list of values ​​in Redmine are not sorted alphabetically. Over time, tasks and other entities acquire a large number of custom fields, which leads to the procedure for selecting the desired value in the drop-down list in the quest to search for values.
We sorted the values ​​in all the fields and added a search function by substring so that the filter conditions could be set faster.



How we use task requests in Redmine.

Well, it is clear that we use for its intended purpose (as it is conceived by the developers). We save requests so that the user can quickly find the tasks he needs. But we also apply them everywhere to various settings.

For example, we have the “Unread issues” plugin, which allows you to display a green and blue circle with the number of unread tasks. Green, when the user did not read the task at all and blue - when he read, but from the moment of reading in the task something has changed.

The same plugin makes a link with circles-counters in the top menu on my page. Circles show the total number of unread tasks assigned to the user.



The programmer had to periodically rewrite the query responsible for counting the counters. Then we entered a setting that determined based on which task request counts the unread tasks.



The problem is immediately gone, now the administrator can quickly change the task request using the standard wide filtering capabilities, and the counters will be considered based on the updated request automatically.

Then we applied the same concept in most other places:

The selection of tasks into the operational plan ( I wrote about operational planning earlier ) is based on the usual request for tasks. This allows the administrator to flexibly reconfigure the conditions under which the task falls into the operational plan.

Based on the request, the tasks fall into a specific column of the WIP diagrams (Scrum boards)



Based on any task request, you can create a block on my page. Standard Redmine has a limited set of blocks, sampling tasks for blocks embedded in the code.

Well, and so on, we use standard task requests everywhere, when you need to define a sample of tasks that should be displayed in some place.

This architectural solution gives an amazing flexibility in setting up the system and saves programmers from the heap of the routine work of rewriting requests.

I hope the article and the plugins will be useful.