Closed Stag0007 closed 7 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?
[
ありがとうございます。 私は詳しくないのですが、検索画面とモジュールにIDによるソートが追加されている、という認識でよろしいでしょうか。
そのつもりです。 期待したものか動作確認してもらえますか?
動作しました。ありがとうございます! 現在は変更を考えていないのですが、初期のソートを更新日時やチケット番号に変更することは可能でしょうか。
これで変わると思いますが、コミットするなら管理画面で変更できるようにしないとですねぇ。
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
ありがとうございます。変更できることを確認出来ました。 確かに管理画面で変更できると良いですね。 プロジェクト、メンバー単位でも意見が割れそうで難しい気もしますが。。。
この度はありがとうございました!
すみません、追加で確認したところ、注記を更新した際の番号も込みでソートがかかっているようでした。
チケット番号のみを対象と出来ないでしょうか?
うーん、そういうデータの持ち方になっていないので追加でデータを入れないとできないんですよねぇ。
searcher.rbで"#{direction}source_id"を"#{direction}container_id"では駄目でしょうか?
注記のcontainer_id
はチケット番号ですが、チケットのcontainer_id
は常に0なんですよ。たしか。
確かに。。。現状では難しそうですね。
必要なのはチケット番号でのソートじゃない気がするんですよねぇ。 やりたいことは「一括更新した変更を無視したい」ですか?「一括更新した変更だけを知りたい」ですか?
カテゴリ、カスタムフィールドに関して(可能であればステータスも)一括更新した変更を無視したい、です。
一括更新ではないときのカテゴリー・カスタムフィールドの変更はどうしたいですか?反映されて欲しいですか?無視されて欲しいですか?
あと、どうして更新日時のソートを使っているのですか?更新日時でソートするとなぜ目的のチケットを見つけやすいのですか?
一括更新でない場合のカテゴリ、カスタムフィールドの変更に関しても検索時は無視したいです。 職場では主にサービスデスクの対応履歴としてRedmineを使用しています。 システムや機器更新、運用変更が発生しうるので、検索時には直近で題名、説明、コメントで更新が発生したチケットを対象としたい為、更新日時をソートとして利用しています。
キーワードでウォッチしたいチケットを絞り込んで、未対応のチケット順に並べて、その順にチケットを処理する運用にしたい、という感じですね。
今は検索対象にしていませんが、チケット本体とは別に題名と説明の更新履歴があります。それを検索対象にして、それらの更新履歴とコメントだけを検索対象にし、さらに、既存の更新日時のソートを組み合わせれば実現できそうな気がします。
はい、その通りです。ちゃんとチケット整理してナレッジ化しろという話なのですが。。。 チケット番号でのソートより、記載いただいた検索対象の追加、絞り込み、更新日時のソートの組み合わせの方が、 希望する検索結果が得られそうですね。
更新日時のようにチケット作成日時を検索対象としソートもよい気がするのですが、どうでしょうか。 一括更新するような項目ではないのですが、テキスト形式のカスタムフィールドを採用しており、 そちらの内容を検索することがあるのを失念していました。
今は更新日時しか記録していないので追加で情報を記録しないとそれはできないのですが、それだと、題名・説明を更新したときにそれを検出できない(作成日時は変わらないため)ので、期待した挙動にならない気がします。
題名・説明の更新を検出は出来ないのですが、更新日時ソートでノイズになるカテゴリ、カスタムフィールドの一括更新は除外出来ると思われるので、検索対象に追加いただくことが可能ならばありがたいです。
うーん、そのアプローチが本当にこの問題を解決するアプローチとは思えないんですよねぇ。
チケット一覧ページでフィルタとして各種条件を指定できますが、そこでこのプラグインが提供する全文検索機能も使えるようにするのが必要なんじゃないかという気がしています。その条件で対象のチケットを絞り込んで、別途指定できるソート条件を設定したものをカスタムクエリとして登録して使う、みたいなのが必要なんじゃないかという気がします。
検索窓ではなく、チケット一覧で条件指定したカスタムクエリ選択→フィルタのように検索ということでしょうか。 実装された場合、条件指定やソートがユーザー側で設定可能になる一方で、現在の全文検索機能の優れている、 検索結果ウィンドウから直接部分(説明、コメント)を開ける機能は使用できなる想定でしょうか。
そうですね。 このユースケースで説明・コメントの検索結果から直接遷移できる機能は必要だったのですね。 動的なタスクリストを作りたい(そして上から順番に処理したい)、ということかと思っていたので重要じゃないのかと思っていました。
特に検索で表示されたチケットは何かしらの処理を行うケースは少なく、 ヒットした記載内容の確認を行う意味で検索を行っています。 (特定の処理対象チケットはカスタムクエリでほぼ絞り込み可能です)
そのため、現在の検索結果→遷移は非常に使い易いのでそのまま利用したく、 チケットの更新上、一括での更新を除いては更新日時≒作成日時になるため、 チケット番号か作成日時でのソートが出来ればと思っておりました。
なるほど。 それであれば作成日時でよさそうですね。
こちらの伝え方が至らずにすみません。 作成日時を検索対象に追加していただくことは可能でしょうか。
こちらの Issue の「作成日時でソート」をできるようにするを対応したいなと考えています!
@kou 下記にざっくりと対応する必要がありそうな部分を列挙して、ざっくりと見積もりをしてみましたので、アドバイスをいただきたいです🙏
想定しているタスクのざっくり見積もり 14h(7h x2(バッファ) )を想定しています。 稼働できる時間を考慮すると 12/15 には完了できる見込みでいます。
見積もり内訳
created_at
を含める
fts_targets
テーブルに作成日時を格納するようのカラムを追加するcreated_at
を含める
created_at
の値を保存するようにする気になり タスクとして全く考慮できていない部分がないかが気になっています。もしありましたらアドバイスいただきたいです🙏
あざっす!
そうっすね。 やることはそんな感じですね。
あとは、fts_targets.created_at
にはインデックスを貼りたいけどPGroongaの場合はどうやって既存のインデックスに組み合わせるかなぁ、一旦削除して新しいインデックス作成かなぁ、みたいなところですかねぇ。
あとは、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
だとみなすように変更し更新するようにする
created_at
が存在しない初回のみ実行されるコードになってしまうので、普段は利用されないコードになってしまう選択肢2: created_at
を追加する migration 内で、source_type_id
や source_id
を利用して対象レコードを取得し、created_at
を更新する
created_at
を更新するマイグレーション内でデータの整合性を取れる選択肢2がよさそうに見えます。 そもそもマイグレーションでタイムアウトが起きることってあるんでしたっけ?
@kou 見積もり 10h(5h x2(バッファ)) 想定で、稼働できる時間を考慮し、12/22 に完了見込みで再度調整させていただきたいです🙏
そもそもマイグレーションでタイムアウトが起きることってあるんでしたっけ?
@kou 少し調べてみたのですが、純粋な Rails の設定では見つけられなかったです。 下記の gem を入れた場合に、長時間に及ぶマイグレーションをタイムアウトにしてくれる設定を入れられるみたいです。これと混同していたみたいです🙏
では、その予定でやってみましょう。 少し作業をして知見が増えたと思うのですが、それをふまえて「作成日時でのソート機能を追加 」の見積もりを更新しなくても大丈夫ですか?
全レコードにcreated_at
を設定する処理よりもインデックスを創る処理の方が重いと思うんですが、今までインデックス作成でタイムアウト起因で失敗することは発生していないはずなので、今回はタイムアウトは気にしなくてもよさそうですね。
@kou
全レコードにcreated_atを設定する処理よりもインデックスを創る処理の方が重い
ありがとうございます。おっしゃる通りだと思うので問題なさそうですね。
少し作業をして知見が増えたと思うのですが、それをふまえて「作成日時でのソート機能を追加 」の見積もりを更新しなくても大丈夫ですか?
ありがとうございます。 下記の理由から残りの作業を7hで見積もり、12/22 完了見込みに変更させてください。🙏
下記の理由から見積もりを 10h -> 14h(7h x2(バッファ)) 想定に変更し、12/24 に完了見込みに変更させてください。🙏
(見積もり内訳)
order_target
parameter で created_at
が送られたてきた際の考慮を追加するcreated_at
カラムが追加されていることを考慮する@kou レビューありがとうございました。 残りの作業である「作成日時でのソート機能を追加」の PR を下記で作成しましたので、レビューをお願いします。
上記の PR 以外の残タスクは無い認識でいますが、もし考慮漏れなどがありましたら、コメントしていただけると嬉しいです🙏
そうっすね。 今のところは一通り大丈夫そうな気はします。 が、実際に使ってみたらなにか漏れが見つかるかもしれません。
@kou 当日にすみません。完了見込み 12/28 に変更させてくださいmm
はいー
@kou レビューありがとうございます。 度々、申し訳ないです。完了見込みを年明けにさせてくださいmm
うっす。
検索結果のソート対象に、チケット番号(issue_id)をサポートしてほしいです。 更新日時のソートを高頻繁で使用していますが、 過去チケットに対し一括更新をかけることがあり、そのような場合にチケット番号でのソートがあれば非常に助かります。 よろしくお願いいたします。