Improve search functionality

[okkez]

権限まわりをGroonga側に寄せる方法がよくわからない。

---

ログイン必須かどうかは関係なし。

• 公開プロジェクト: 権限気にしない
• 非公開プロジェクト: 権限のチェックが必要
• User.current が admin の場合も権限チェック不要

326b032 までだと、Groonga側に作るテーブルはsearcher_recordsだけ。

Redmine本体側だと、projectにmemberがいてmemberにroleが設定されている。

project <- member <- role (permissions)
                └─ user(group)

Groonga側のテーブルが searcher_records 1つだけだと、権限まわりの情報を表現できない。

権限のカスタマイズをしていなければ、searcher_records.project_id はあるので公開プジェクトのidと User.current.projects.map(&:id) を渡せば検索できる。

[okkez]

@kou 何かアイデアがあれば、教えてください。。。

[kou]

Project.allowed_to_conditionとIssue.visible_conditionを見ると複雑なのでこれをGroongaレベルでも再実装するのは（バグって見えちゃいけないものが見えるのが怖いので）避けたいですね。。。

別途SQLを3回実行することになってしまいますが、こんなんでいけないですかねぇ。SQLはクエリーキャッシュが効く気がするのであんまり遅くならないかも。

--filter \
  '(in_values(project_id, #{User.current.visible_project_ids.join(", ")}) &! \
    in_values(original_type, "Issue", "Journal") || \
   (original_type == "Issue" && \
    in_values(original_id, #{Issue.visible.pluck(:id).join(", ")})) || \
   (original_type == "Journal" && \
    in_values(original_id, #{Journal.visible.pluck(:id).join(", ")}))'

[okkez]

なるほど filter でがんばるんですね！あとで試してみます。

[kou]

IssueとJournalのvisibleなIDのリストは長くなりそうなので、invisibleなIDのリストにできた方がよさそうなんですが、そうするとそのロジックをプラグイン側でメンテナンスしないといけなくなるのがアレなんですよねぇ。

SQLでNOT visibleなconditionみたいな条件が効率よく動くならそっちの方がいいかもしれません。（全体からのNOTは効率よくなりにくいので難しい気がしますが。。。）

[okkez]

original_idのリストが長くなりそうな気がしたのでfiterで↓のようにしようと考えています。 数が多いので、一つだけ例示します。これだと権限の数だけSQLを発行すればいいです。 プロジェクトの数はそんなに多くないはずなので、最初はこれでいいかなぁと思います。

(original_type == "Issue" && is_private == false && in_values(project_id, #{Project.allowed_to(user, :view_issues).pluck(:id).join(",")})

[kou]

プライベートなやissue/journalは全部対象外にするってことですね。 最初のステップとしては妥当だと思います。

[okkez]

:memo:

• 動的カラムの機能を使うと snippet_html が複数あってもそれぞれに別名を付けることができる
• Mroonga 7.05を使うと、mroonga_command が可変長引数になって便利
  • このプラグインのユーザーは最新版を使ってもらう(制限が増える)
• キーワードのハイライトの色分けは嬉しいかどうかわからないのでしない
• query_escape なしで検索して、失敗したらアリで検索しなおす
• ベンチマーク方法を考えたい
  • bin/rails r で実行できるやつ
• 類似issue検索は一旦リリースした後で。

[okkez]

:memo: 残作業

• カスタムフィールドのデータを正しくロードする
  • issue しか対応できていない
  • 作業時間、プロジェクト、バージョン、文書、ユーザー、グループ、作業分類（時間管理）、チケットの優先度、文書カテゴリのうち必要なものに対応する
  • あとプロジェクトだけ！
• スコアの重み付け（前のバージョンと同じにしておく）
• 添付ファイルまわりのテスト
• カスタムフィールドまわりのテスト

[okkez]

• 添付ファイル
  • Project
  • Issue
  • Journal チケットのコメントを書くときに添付したファイルはチケットに紐付く
  • News
  • Document
  • Version
  • Message
  • WikiPage
• カスタムフィールド (テキスト、リスト、長いテキストのみ)
  • Project
  • Issue

以上について動作を確認した。