ファイルの読み取り権限を検索へ引き継ぐ処理と、文書から候補語を生成する処理が見直されました。FessのPR #3685・#3686・#3688・#3689はマージ済みです。
権限欄のdenyを保存し直したときの変化
クロール設定の権限欄に「(deny) {user}bob」のように接頭辞の後へ空白を入れた場合、拒否として保存されず、再保存で許可へ変わる問題がありました。修正後は(allow)・(deny)の後をtrimしてから解釈します。
拒否は「(deny){user}bob」「(deny){group}staff」「(deny){role}editor」のように、対象の種類を指定します。型のない「(deny)foo」は拒否として保存されず、呼び出し側で空値として除外されます。またDevelopersのようにDで始まる通常の値を、拒否の接頭辞と誤認しないようになります。
以前に拒否が許可へ変換されて保存された値は、修正版だけでは元に戻せません。該当するクロール設定を確認し、意図したdenyを入れ直します。初期の内部接頭辞はユーザー1・グループ2・ロールR・拒否Dですが、通常の設定欄では内部表現を直接書かず上記の形式を使います。
ローカルファイルのACLは読み取りだけを反映
file.role.from.fileの初期値はtrueです。file:のクロールでAclFileAttributeViewが得られるファイルシステムを対象に、READ_DATAを含むALLOWを許可、同じ権限を含むDENYを拒否として登録します。書き込みだけの許可やAUDIT・ALARMは読み手の追加に使いません。
これはNTFSなどのACL情報を取得できる場合の処理で、POSIXの完全な権限モデルを実装したり、あらゆるリモートストレージのACLを扱う変更ではありません。旧処理で登録した文書のロールは再クロールまで残るため、設定修正後は対象を再取得し、許可・拒否のそれぞれのユーザーで検索結果を確認します。
検索できない文書の語を候補へ出さない
文書を元にするサジェスト生成では、roleがない文書と、ユーザー・グループ・ロールへのdenyを含む文書を読み込み対象から除外します。サジェスト要求で個別ユーザーのdenyを表せないため、allowも持つ文書であってもdenyがあれば文書全体を除外します。閲覧できるユーザーにとっても、その文書由来の候補語が減る場合があります。
すでに作成済みの候補は、更新した瞬間に一括削除されるのではなく、通常のpurgeで期限切れになります。文書の再クロールとサジェストの更新・purgeを別々に確認します。検索ログなど別の供給元もあるため、単語が残っていることだけで今回の文書フィルターが未適用とは断定しません。
人気ワードのメモリー内キャッシュも、複数のロール名を区切りなしで結合したキーが別の組み合わせと衝突しないよう修正します。新しい有効化設定はありません。更新後は閲覧ロールの異なるユーザーを切り替え、文書・サジェスト・人気ワードをそれぞれ確認します。