clear-code / redmine_full_text_search

Full text search for Redmine
MIT License
63 stars 24 forks source link

検索結果のソートにチケット番号を追加してほしい #115

Closed Stag0007 closed 10 months ago

Stag0007 commented 12 months ago

検索結果のソート対象に、チケット番号(issue_id)をサポートしてほしいです。 更新日時のソートを高頻繁で使用していますが、 過去チケットに対し一括更新をかけることがあり、そのような場合にチケット番号でのソートがあれば非常に助かります。 よろしくお願いいたします。

kou commented 12 months ago

こんな感じですか?

diff --git a/app/views/search/index.html.erb b/app/views/search/index.html.erb
index 329e5b0..d43032a 100644
--- a/app/views/search/index.html.erb
+++ b/app/views/search/index.html.erb
@@ -58,6 +58,10 @@
               <%= form.radio_button "order_target", "date", name: "order_target" %>
               <%= l(:label_full_text_search_order_target_date) %>
             </label>
+            <label>
+              <%= form.radio_button "order_target", "id", name: "order_target" %>
+              <%= l(:label_full_text_search_order_target_id) %>
+            </label>
           </p>
           <p>
             <label>
@@ -105,6 +109,12 @@
                                l(:label_full_text_search_order_target_date),
                              url_for(@search_request.to_params(order_target: "date"))) %>
         </li>
+        <li>
+          <%= link_to_unless(@search_request.order_target == "id",
+                             tag.i(class: "fas fa-id-badge") + " " +
+                               l(:label_full_text_search_order_target_id),
+                             url_for(@search_request.to_params(order_target: "id"))) %>
+        </li>
       </ul>
     </div>
     <div id="search-order-type" class="search-order">
diff --git a/config/locales/en.yml b/config/locales/en.yml
index 5f93af9..99c8bc9 100644
--- a/config/locales/en.yml
+++ b/config/locales/en.yml
@@ -5,6 +5,7 @@ en:
   label_full_text_search_result_order_type: Sort order
   label_full_text_search_order_target_score: score
   label_full_text_search_order_target_date: updated at
+  label_full_text_search_order_target_id: ID
   label_full_text_search_order_type_asc: asc
   label_full_text_search_order_type_desc: desc
   label_full_text_search_display_score: Display score
diff --git a/config/locales/ja.yml b/config/locales/ja.yml
index cf7dd3b..80dfe8d 100644
--- a/config/locales/ja.yml
+++ b/config/locales/ja.yml
@@ -5,6 +5,7 @@ ja:
   label_full_text_search_result_order_type: 並び順
   label_full_text_search_order_target_score: スコア
   label_full_text_search_order_target_date: 更新日時
+  label_full_text_search_order_target_id: ID
   label_full_text_search_order_type_asc: 昇順
   label_full_text_search_order_type_desc: 降順
   label_full_text_search_display_score: スコアを表示
diff --git a/lib/full_text_search/searcher.rb b/lib/full_text_search/searcher.rb
index bacde4e..3d2e82e 100644
--- a/lib/full_text_search/searcher.rb
+++ b/lib/full_text_search/searcher.rb
@@ -246,6 +246,11 @@ module FullTextSearch
         [
           "#{direction}last_modified_at",
         ]
+      when "id"
+        [
+          "#{direction}source_id",
+          "-last_modified_at",
+        ]
       else
         # TODO: -_score is useful?
         [
Stag0007 commented 12 months ago

ありがとうございます。 私は詳しくないのですが、検索画面とモジュールにIDによるソートが追加されている、という認識でよろしいでしょうか。

kou commented 12 months ago

そのつもりです。 期待したものか動作確認してもらえますか?

Stag0007 commented 12 months ago

動作しました。ありがとうございます! 現在は変更を考えていないのですが、初期のソートを更新日時やチケット番号に変更することは可能でしょうか。

kou commented 12 months ago

これで変わると思いますが、コミットするなら管理画面で変更できるようにしないとですねぇ。

diff --git a/app/models/full_text_search/request.rb b/app/models/full_text_search/request.rb
index 9864382..203be69 100644
--- a/app/models/full_text_search/request.rb
+++ b/app/models/full_text_search/request.rb
@@ -122,7 +122,7 @@ module FullTextSearch
     end

     def order_target
-      @order_target.presence || "score"
+      @order_target.presence || "id"
     end

     def order_type
Stag0007 commented 12 months ago

ありがとうございます。変更できることを確認出来ました。 確かに管理画面で変更できると良いですね。 プロジェクト、メンバー単位でも意見が割れそうで難しい気もしますが。。。

この度はありがとうございました!

Stag0007 commented 12 months ago

すみません、追加で確認したところ、注記を更新した際の番号も込みでソートがかかっているようでした。 チケット番号のみを対象と出来ないでしょうか? image

kou commented 12 months ago

うーん、そういうデータの持ち方になっていないので追加でデータを入れないとできないんですよねぇ。

Stag0007 commented 12 months ago

searcher.rbで"#{direction}source_id"を"#{direction}container_id"では駄目でしょうか?

kou commented 12 months ago

注記のcontainer_idはチケット番号ですが、チケットのcontainer_idは常に0なんですよ。たしか。

Stag0007 commented 12 months ago

確かに。。。現状では難しそうですね。

kou commented 12 months ago

必要なのはチケット番号でのソートじゃない気がするんですよねぇ。 やりたいことは「一括更新した変更を無視したい」ですか?「一括更新した変更だけを知りたい」ですか?

Stag0007 commented 11 months ago

カテゴリ、カスタムフィールドに関して(可能であればステータスも)一括更新した変更を無視したい、です。

kou commented 11 months ago

一括更新ではないときのカテゴリー・カスタムフィールドの変更はどうしたいですか?反映されて欲しいですか?無視されて欲しいですか?

あと、どうして更新日時のソートを使っているのですか?更新日時でソートするとなぜ目的のチケットを見つけやすいのですか?

Stag0007 commented 11 months ago

一括更新でない場合のカテゴリ、カスタムフィールドの変更に関しても検索時は無視したいです。 職場では主にサービスデスクの対応履歴としてRedmineを使用しています。 システムや機器更新、運用変更が発生しうるので、検索時には直近で題名、説明、コメントで更新が発生したチケットを対象としたい為、更新日時をソートとして利用しています。

kou commented 11 months ago

キーワードでウォッチしたいチケットを絞り込んで、未対応のチケット順に並べて、その順にチケットを処理する運用にしたい、という感じですね。

今は検索対象にしていませんが、チケット本体とは別に題名と説明の更新履歴があります。それを検索対象にして、それらの更新履歴とコメントだけを検索対象にし、さらに、既存の更新日時のソートを組み合わせれば実現できそうな気がします。

Stag0007 commented 11 months ago

はい、その通りです。ちゃんとチケット整理してナレッジ化しろという話なのですが。。。 チケット番号でのソートより、記載いただいた検索対象の追加、絞り込み、更新日時のソートの組み合わせの方が、 希望する検索結果が得られそうですね。

Stag0007 commented 11 months ago

更新日時のようにチケット作成日時を検索対象としソートもよい気がするのですが、どうでしょうか。 一括更新するような項目ではないのですが、テキスト形式のカスタムフィールドを採用しており、 そちらの内容を検索することがあるのを失念していました。

kou commented 11 months ago

今は更新日時しか記録していないので追加で情報を記録しないとそれはできないのですが、それだと、題名・説明を更新したときにそれを検出できない(作成日時は変わらないため)ので、期待した挙動にならない気がします。

Stag0007 commented 11 months ago

題名・説明の更新を検出は出来ないのですが、更新日時ソートでノイズになるカテゴリ、カスタムフィールドの一括更新は除外出来ると思われるので、検索対象に追加いただくことが可能ならばありがたいです。

kou commented 11 months ago

うーん、そのアプローチが本当にこの問題を解決するアプローチとは思えないんですよねぇ。

チケット一覧ページでフィルタとして各種条件を指定できますが、そこでこのプラグインが提供する全文検索機能も使えるようにするのが必要なんじゃないかという気がしています。その条件で対象のチケットを絞り込んで、別途指定できるソート条件を設定したものをカスタムクエリとして登録して使う、みたいなのが必要なんじゃないかという気がします。

Stag0007 commented 11 months ago

検索窓ではなく、チケット一覧で条件指定したカスタムクエリ選択→フィルタのように検索ということでしょうか。 実装された場合、条件指定やソートがユーザー側で設定可能になる一方で、現在の全文検索機能の優れている、 検索結果ウィンドウから直接部分(説明、コメント)を開ける機能は使用できなる想定でしょうか。

kou commented 11 months ago

そうですね。 このユースケースで説明・コメントの検索結果から直接遷移できる機能は必要だったのですね。 動的なタスクリストを作りたい(そして上から順番に処理したい)、ということかと思っていたので重要じゃないのかと思っていました。

Stag0007 commented 11 months ago

特に検索で表示されたチケットは何かしらの処理を行うケースは少なく、 ヒットした記載内容の確認を行う意味で検索を行っています。 (特定の処理対象チケットはカスタムクエリでほぼ絞り込み可能です)

そのため、現在の検索結果→遷移は非常に使い易いのでそのまま利用したく、 チケットの更新上、一括での更新を除いては更新日時≒作成日時になるため、 チケット番号か作成日時でのソートが出来ればと思っておりました。

kou commented 11 months ago

なるほど。 それであれば作成日時でよさそうですね。

Stag0007 commented 11 months ago

こちらの伝え方が至らずにすみません。 作成日時を検索対象に追加していただくことは可能でしょうか。

otegami commented 11 months ago

こちらの Issue の「作成日時でソート」をできるようにするを対応したいなと考えています!


@kou 下記にざっくりと対応する必要がありそうな部分を列挙して、ざっくりと見積もりをしてみましたので、アドバイスをいただきたいです🙏

想定しているタスクのざっくり見積もり 14h(7h x2(バッファ) )を想定しています。 稼働できる時間を考慮すると 12/15 には完了できる見込みでいます。

見積もり内訳

気になり タスクとして全く考慮できていない部分がないかが気になっています。もしありましたらアドバイスいただきたいです🙏

kou commented 11 months ago

あざっす!

そうっすね。 やることはそんな感じですね。

あとは、fts_targets.created_atにはインデックスを貼りたいけどPGroongaの場合はどうやって既存のインデックスに組み合わせるかなぁ、一旦削除して新しいインデックス作成かなぁ、みたいなところですかねぇ。

otegami commented 11 months ago

あとは、fts_targets.created_atにはインデックスを貼りたいけどPGroongaの場合はどうやって既存のインデックスに組み合わせるかなぁ、一旦削除して新しいインデックス作成かなぁ、みたいなところですかねぇ。

ありがとうございます! 一旦既存のインデックスを削除して、再度 created_at を含めて複合インデックスを貼り直すことしか思いつけなかったので、とりあえずその方針で進めてみましたmm


@kou 方針に関して相談させてください。

redmine_full_text_search プラグインを既に利用されている環境を想定すると、fts_targets テーブルの既存レコードに対して created_at カラムの値を更新する必要があると考えています。

その際にどのように更新をかけるべきかで悩んでいます。下記の2つの選択肢を考えてみたのですが、もう少し良い案や勘違いをしていたらコメントいただきたいですmm

選択肢1: bin/rails full_text_search:synchronize を改良して、created_at が存在しない場合は outdated だとみなすように変更し更新するようにする

選択肢2: created_at を追加する migration 内で、source_type_idsource_id を利用して対象レコードを取得し、created_at を更新する

kou commented 11 months ago

選択肢2がよさそうに見えます。 そもそもマイグレーションでタイムアウトが起きることってあるんでしたっけ?

otegami commented 10 months ago

@kou 見積もり 10h(5h x2(バッファ)) 想定で、稼働できる時間を考慮し、12/22 に完了見込みで再度調整させていただきたいです🙏

otegami commented 10 months ago

そもそもマイグレーションでタイムアウトが起きることってあるんでしたっけ?

@kou 少し調べてみたのですが、純粋な Rails の設定では見つけられなかったです。 下記の gem を入れた場合に、長時間に及ぶマイグレーションをタイムアウトにしてくれる設定を入れられるみたいです。これと混同していたみたいです🙏

kou commented 10 months ago

では、その予定でやってみましょう。 少し作業をして知見が増えたと思うのですが、それをふまえて「作成日時でのソート機能を追加 」の見積もりを更新しなくても大丈夫ですか?

kou commented 10 months ago

全レコードにcreated_atを設定する処理よりもインデックスを創る処理の方が重いと思うんですが、今までインデックス作成でタイムアウト起因で失敗することは発生していないはずなので、今回はタイムアウトは気にしなくてもよさそうですね。

otegami commented 10 months ago

@kou

全レコードにcreated_atを設定する処理よりもインデックスを創る処理の方が重い

ありがとうございます。おっしゃる通りだと思うので問題なさそうですね。

少し作業をして知見が増えたと思うのですが、それをふまえて「作成日時でのソート機能を追加 」の見積もりを更新しなくても大丈夫ですか?

ありがとうございます。 下記の理由から残りの作業を7hで見積もり、12/22 完了見込みに変更させてください。🙏

下記の理由から見積もりを 10h -> 14h(7h x2(バッファ)) 想定に変更し、12/24 に完了見込みに変更させてください。🙏


(見積もり内訳)

otegami commented 10 months ago

@kou レビューありがとうございました。 残りの作業である「作成日時でのソート機能を追加」の PR を下記で作成しましたので、レビューをお願いします。

otegami commented 10 months ago

上記の PR 以外の残タスクは無い認識でいますが、もし考慮漏れなどがありましたら、コメントしていただけると嬉しいです🙏

kou commented 10 months ago

そうっすね。 今のところは一通り大丈夫そうな気はします。 が、実際に使ってみたらなにか漏れが見つかるかもしれません。

otegami commented 10 months ago

@kou 当日にすみません。完了見込み 12/28 に変更させてくださいmm

kou commented 10 months ago

はいー

otegami commented 10 months ago

@kou レビューありがとうございます。 度々、申し訳ないです。完了見込みを年明けにさせてくださいmm

kou commented 10 months ago

うっす。