Fess管理画面の検索結果編集でバリデーションとカスタムフィールド対応を改善

Fessの管理画面には、検索結果一覧からドキュメントを直接編集できる機能があります。今回、この編集画面のバリデーションメッセージの改善と、カスタムフィールドの編集対応を行いました。

背景

管理画面の検索結果編集画面(Admin Search List)では、ドキュメントのフィールドを編集する際にバリデーションが実行されます。しかし、いくつかの問題がありました。

  • バリデーションエラーのメッセージに doc. プレフィックスが表示され、ユーザーにとってわかりにくい表示になっていた
  • 配列フィールドのバリデーションで、配列用ではなく必須チェック用のエラーメッセージが誤って使われていた
  • 標準フィールド以外のカスタムフィールドが編集画面に表示されず、編集できなかった

バリデーションメッセージの修正

validateFields() メソッドでのエラーメッセージ生成を修正しました。従来は .map(s -> "doc." + s) でフィールド名にプレフィックスを付与した後、そのプレフィックス付きの名前をエラーメッセージの表示テキストとしても使っていました。

修正後は、"doc." プレフィックスはプロパティキー(JSPのバインディング用)にのみ使用し、表示テキストにはフィールド名そのものを使うようにしています。これにより、「doc.url is required.」ではなく「url is required.」と表示されるようになります。

// 修正前
.map(s -> "doc." + s)
.forEach(s -> messages.addErrorsPropertyRequired(s, s));

// 修正後
.forEach(s -> messages.addErrorsPropertyRequired("doc." + s, s));

配列フィールド用バリデーションメッセージの追加

配列フィールドのバリデーションでは、errors.property_required が誤って使用されていたため、専用の errors.property_type_array メッセージキーを新設しました。17言語すべてに翻訳を追加しています。

# 英語
errors.property_type_array={0} must be an array.

# 日本語
errors.property_type_array={0}は配列でなければなりません。

FessMessages クラスにも addErrorsPropertyTypeArray() メソッドを追加し、validateFields() メソッドから呼び出すようにしています。

カスタムフィールドの編集対応

編集画面では、URLやタイトルなどの標準フィールドはハードコードされた入力フォームで表示されますが、ユーザーが追加したカスタムフィールドは表示されていませんでした。

今回、registerExtraFields() メソッドを追加し、ドキュメントに含まれるフィールドのうち標準フィールド(STANDARD_EDIT_FIELDS)に含まれないものを動的に検出して編集画面に表示するようにしました。

フィールドの型は FessConfig の設定に基づいて自動判定されます。

  • 配列フィールド → テキストエリア
  • 日付フィールド → テキスト入力(日付フォーマットのバリデーション付き)
  • 数値フィールド(integer、long、float、double) → 数値入力
  • その他 → テキスト入力

また、_id_version_seq_no_primary_term などの内部メタデータフィールドは、セキュリティの観点から編集画面に表示されないよう除外しています。

カスタムフィールドの候補は、ドキュメントに含まれるキーだけでなく、FessConfig で定義されたフィールド定義からも取得されます。これにより、新規作成時やドキュメントにまだ値が設定されていないフィールドも編集画面に表示されます。

テストの追加

AdminSearchlistActionTest として27件のユニットテストを追加し、以下をカバーしています。

  • フォームの初期化とフィールドの割り当て
  • validateFields() の正常系・異常系(必須、float、long、日付)
  • バリデーションメッセージのプロパティキー形式
  • STANDARD_EDIT_FIELDS 定数の内容
  • registerExtraFields() のカスタムフィールド検出、型判定、ソート順、null処理
  • 予約フィールドの除外

まとめ

この改善により、管理画面の検索結果編集画面がより使いやすくなりました。バリデーションメッセージがわかりやすくなり、カスタムフィールドも直接編集できるようになっています。詳細は PR #3102 を参照してください。

Fessの設定系インデックスの再構築機能 

Fessをアップグレードする際、設定系インデックス(fess_config、fess_user、fess_log)のマッピングが変更されていることがあります。これまではマッピングの変更を手動で反映する必要がありましたが、管理画面のメンテナンス機能から簡単に再構築できるようにしました。

背景

Fessでは、検索ドキュメント用のインデックス(fess.YYYYMMDD)とは別に、設定情報を保存する設定系インデックスがあります。バージョンアップ時にマッピングの変更があった場合、設定系インデックスにも最新のマッピングを適用する必要があります。これまではOpenSearchの管理ツールなどを使って手動で対応する必要がありましたが、この作業を管理画面から実行できるようにしました。

再構築の仕組み

管理画面のメンテナンスページに「Rebuild Config Index」カードを追加しました。再構築は以下の手順で安全に実行されます。

  1. バックアップの作成: 対象インデックスのデータをバックアップ用インデックスにリインデックス
  2. インデックスの削除と再作成: 元のインデックスを削除し、最新のマッピングで再作成
  3. データの復元: バックアップからデータをリインデックスして復元
  4. エイリアスの再設定: エイリアスを再設定してサービスを継続
  5. 検証: ドキュメント数を検証し、不整合があれば自動でロールバック

再構築対象のインデックスは、fess_config、fess_user、fess_logの3種類から個別に選択できます。検索ドキュメント用のインデックス(DOC_INDEX)は対象外です。

デフォルトデータの読み込み

「Load Default Data」チェックボックスをオンにすると、再構築時にデフォルトのバルクデータを投入できます。この際、OpType.CREATEを使用しているため、既存のドキュメントは上書きされません。新規のデフォルトデータのみが追加されます。

利用方法

管理画面の「メンテナンス」ページにアクセスすると、「Rebuild Config Index」セクションが表示されます。再構築したいインデックスのチェックボックスを選択し、必要に応じて「Load Default Data」にチェックを入れて実行します。

この機能を利用するには、OpenSearchのreindexモジュールが必要です。Fessのmodule.xmlにreindexモジュールのインストール設定が追加されています。

詳細はPR #3097を参照してください。

Fessのスクリプト監査ログの改善

Fessでは、スクリプトの実行内容をaudit.logに出力する機能がありますが、実際に運用してみると、ログが長すぎて扱いにくいという問題がありました。今回、スクリプト監査ログの最大長を設定可能にし、あわせて文字列の正規化処理の順序も修正しました。

問題点

以前の実装では、スクリプトの監査ログに記録されるテキストの最大長が1000文字にハードコードされていました。スクリプトの実行内容をaudit.logに出力するようにしていましたが、ログが長くなりすぎて確認しづらく、実用的ではありませんでした。

また、文字列の正規化処理の順序にも問題がありました。制御文字(改行、タブなど)の置換を先に行ってから切り詰めていたため、切り詰め位置を超えた部分の制御文字まで不要に処理されていました。

改善内容

最大長の設定プロパティ追加

fess_config.propertiesscript.audit.log.max.lengthプロパティを追加し、監査ログに記録するスクリプトテキストの最大長を設定できるようにしました。デフォルト値は100です。

# スクリプト監査ログの最大長(デフォルト: 100)
script.audit.log.max.length=100

以前のデフォルト値1000文字で運用していた環境では、必要に応じて明示的に設定してください。

script.audit.log.max.length=1000

正規化処理の順序修正

ActivityHelper.normalizeScript()メソッドで、処理の順序を変更しました。

変更前: 制御文字の置換 → 切り詰め
変更後: 切り詰め → 制御文字の置換

これにより、切り詰め位置を超えた部分の制御文字に対する不要な処理がなくなり、効率的になりました。

GroovyEngineの最適化

GroovyEngineでは、監査ログが無効な場合の早期リターンを追加しました。初期化時にscriptAuditLogEnabledフラグをキャッシュしておくことで、監査ログが無効な場合はlogScriptExecution()メソッドで無駄な処理を行わずに即座にリターンします。また、getCurrentScheduledJob()でのnullチェックも追加しています。

まとめ

スクリプトの実行内容をaudit.logに出力する機能自体は便利ですが、実際に使ってみると、ログが長すぎて扱いにくいという問題がありました。今回の改善で、最大長を環境に合わせて設定できるようになり、処理効率も向上しました。この変更はFess 15.6.0で利用可能になる予定です。