Boxed Redmineには、かなり柔軟なクエリシステムがあります。 タスクは、ほとんどすべてのフィールドでフィルター処理でき、必要なフィールドを選択して、出力をグループ化し、結果を並べ替えることができます。
Redmineを社内の単一の情報環境として使用することに直面して、標準のクエリ機能は使用するのにあまり便利ではないという結論に達しました。
最初の理由は、クエリの総数が多いことです。
分岐したライフサイクルとさまざまなタイプのタスクには、十分な数のストアドクエリが必要です。 その結果、サイドバーは見づらいリンクの束に変わります。
私たちは何をしましたかタスクリクエストの処理を簡素化する小さなプラグイン
Redmine Extra Queriesを作成しました。
保存されたクエリを分類する機能を実装しました。 これはリクエストを体系化するのに役立ち、私たちはそれを長い間生き続けましたが、一般的な問題を解決しませんでした。 平均的なユーザーは、多数のリクエストから適切なリンクを選択することを恐れているため、最も重要なリクエストを上部のサイドバーに固定し、残りを非表示にする機能を実装しました。
Redmine管理者は、最も重要なリクエストをすべてのユーザーに固定し、マウスをドラッグして並べ替えることができます。 各ユーザーは、個人的に必要なリクエストを修正できます。 したがって、サイドバーのリンクの数を最小限に抑え、必要に応じてまれなクエリにアクセスできるようにしました。
Redmineでタスクをフィルタリングし、リクエストを保存するためのインターフェースは異なります（理由は完全に明らかではありません？！）。 さらに、後者は地獄のような形です。
2つのインターフェイスを1つに組み合わせて最小化しました。
ユーザーは最初にフィルターを構成してから、フィルター結果を制御し、すぐに要求を保存できます。
タスクがフィルタリングされるパラメーターによって常に確認できます。
何らかの理由で、Redmineの値のリストを持つフィールドはアルファベット順にソートされていません。 時間が経つにつれて、タスクやその他のエンティティは多数のカスタムフィールドに囲まれ、値を列挙するためのクエストのドロップダウンリストで目的の値を選択する手順につながります。
すべてのフィールドの値をソートし、サブストリングで検索する機能を追加して、フィルタリング条件をより速く設定できるようにしました。
Redmineでのタスクリクエストの使用方法。それは、意図した目的で使用していることは明らかです（開発者が意図しているためです）。 ユーザーが必要なタスクをすばやく見つけることができるように、リクエストを保存します。 しかし、さまざまな設定のためにそれらをどこでも使用します。
たとえば、未読の課題の数を示す緑と青の円を表示できるプラグイン
「未読の問題」があります。 ユーザーがタスクをまったく読んでいないときは緑、ユーザーが読んだときは青ですが、タスクを読んだ瞬間から何かが変わっています。
同じプラグインは、トップメニューのサークルカウンターとページへのリンクを作成します。 円は、ユーザーに割り当てられた未読タスクの総数を示します。
プログラマーは、カウンターのカウントを担当するリクエストを定期的に書き換える必要がありました。 次に、どのタスク要求に基づいて未読タスクのカウンターをカウントするかを決定する設定を導入しました。
問題はすぐに解消され、管理者は標準の幅広いフィルタリング機能を使用してタスク要求をすばやく変更でき、更新された要求に基づいてカウンターが自動的に計算されます。
次に、同じ概念を他の多くの場所に適用しました。
運用計画におけるタスクの選択（
以前に運用計画について
書いた ）は、タスクに対する通常の要求に基づいています。 これにより、管理者は、タスクが運用計画に該当する条件を柔軟に再構成できます。
要求に基づいて、タスクはWIP図の特定の列に分類されます（スクラムボード）
タスクリクエストに基づいて、ページにブロックを作成できます。 標準Redmineのブロックセットには制限があり、ブロックのタスクの選択はコードに縫い付けられています。
さて、どこかで表示する必要があるタスクの選択を定義する必要がある場合、どこでも標準タスククエリを使用します。
このようなアーキテクチャソリューションは、システムの構成に驚くほどの柔軟性を提供し、プログラマーが要求を書き換えるための一連の日常作業から節約します。
記事とプラグインが役立つことを願っています。