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

[Stag0007]

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

[kou]

こんな感じですか？

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]

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

[kou]

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

[Stag0007]

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

[kou]

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

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]

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

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

[Stag0007]

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

[kou]

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

[Stag0007]

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

[kou]

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

[Stag0007]

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

[kou]

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

[Stag0007]

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

[kou]

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

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

[Stag0007]

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

[kou]

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

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

[Stag0007]

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

[Stag0007]

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

[kou]

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

[Stag0007]

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

[kou]

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

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

[Stag0007]

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

[kou]

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

[Stag0007]

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

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

[kou]

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

[Stag0007]

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

[otegami]

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

---

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

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

見積もり内訳

• 3h 検索対象データに作成日時を追加
  • 1h: 検索対象テーブルにcreated_atを含める
    • fts_targets テーブルに作成日時を格納するようのカラムを追加する
  • 2h: Indexing の対象にcreated_atを含める
    • 各 Mapper Class でcreated_atの値を保存するようにする
    • テスト追加
• 4h 作成日時でのソート機能を追加
  • 1h: 検索画面上で「作成日時」のソートを選択できるようにする
  • 3h: ソート時に「created_at」をソート対象にする
    • 全文検索エンジンに投げるクエリで sort_key の生成時に作成日時を考慮する
    • テスト追加

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

[kou]

あざっす！

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

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

[otegami]

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

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

• ref: https://github.com/clear-code/redmine_full_text_search/pull/118

---

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

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

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

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

• メリット: 既存レコードが大量にある環境では、migration のタイムアウトなどを考慮せずに更新できる
• デメリット: created_at が存在しない初回のみ実行されるコードになってしまうので、普段は利用されないコードになってしまう

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

• メリット: created_at を更新するマイグレーション内でデータの整合性を取れる
• デメリット: データ量が多い環境では、マイグレーションのタイムアウトが起きてしまう可能性がありそう
  • ↑ 不安があるだけで、実際に計測などはできていないですmm

[kou]

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

[otegami]

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

• 検索対象データに作成日時を追加
  • 1h(見積もり) -> 3h(実績): 検索対象テーブルにcreated_atを含める
    • fts_targets テーブルに作成日時を格納するようのカラムを追加する
  • 2h(見積もり) -> 3h(実績): Indexing の対象にcreated_atを含める
    • 各 Mapper Class でcreated_atの値を保存するようにする
    • テスト追加
  • 残タスク
    • 1h 追加: migration ファイルの修正
• 作成日時でのソート機能を追加
  • 1h(見積もり): 検索画面上で「作成日時」のソートを選択できるようにする
  • 3h(見積もり): ソート時に「created_at」をソート対象にする
    • 全文検索エンジンに投げるクエリで sort_key の生成時に作成日時を考慮する
    • テスト追加

[otegami]

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

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

• https://github.com/ankane/strong_migrations?tab=readme-ov-file#migration-timeouts

[kou]

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

[kou]

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

[otegami]

@kou

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

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

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

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

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

• 「作成日時でのソート機能を追加」の作業内容をもう少し具体化して、完全に考慮できていない対応があったようにプラス 2h 追加したいため

---

(見積もり内訳)

• 検索対象データに作成日時を追加
  • 1h(見積もり) -> 3h(実績): 検索対象テーブルにcreated_atを含める
  • 2h(見積もり) -> 3h(実績): Indexing の対象にcreated_atを含める
  • 残タスク
    • 1h(見積もり) 追加: migration ファイルの修正
• 作成日時でのソート機能を追加
  • 1h(変更前の見積もり) -> 2h(見積もり): 検索画面上で「作成日時」のソートを選択できるようにする
  • 3h(変更前の見積もり)-> 4h(見積もり): ソート時に「created_at」をソート対象にする
    • 全文検索エンジンに投げるクエリで sort_key の生成時に作成日時を考慮する
      • [追加] order_target parameter で created_at が送られたてきた際の考慮を追加する
      • [追加] 検索結果の出力に created_at カラムが追加されていることを考慮する
    • テスト追加

[otegami]

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

• https://github.com/clear-code/redmine_full_text_search/pull/119

[otegami]

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

[kou]

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

[otegami]

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

• 「検索結果に「作成日時 or 更新日時」を含める」部分が考慮できておらず、実装方針にもよると思うのですが、この部分の作業量を 3h として見積もらせてくださいmm
  • https://github.com/clear-code/redmine_full_text_search/pull/119#discussion_r1434628671

[kou]

はいー

[otegami]

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

• 所感としては、あと1 往復レビュー & レビュー対応があれば完了できるかなと考えています。

[kou]

うっす。