担当者の欄に、置きたい人の名前が出てこない。あるいは選べたのに、その人がログインすると管理対象を開けない。どちらも設定の不備ではなく、指名できる人の条件がそう決まっているために起きます。
以下はコンテンツ更新管理というプラグインの話で、管理対象に置く3つの枠——担当者・承認者・エスカレーション先——に誰を入れられるのかを扱います。出荷前の製品なので運用の事例は出てきません。代わりに、なぜこの条件になったのかを開発中の記録から書きます。4つの単位で担当と期限を持たせる仕組みそのものは柱の記事のほうに。
「選べない」には、候補が無い場合と、変える権限が無い場合がある
先に見るのは、欄そのものを触れるかどうかです。担当者・承認者・エスカレーション先の割り当てを変更できるのは「管理対象全体を管理」する権限を持つ人だけで、既定では管理者。編集者や投稿者は管理対象を追加できるし、次回確認日も更新頻度も重要度も通知設定も編集できますが、この3つの枠だけは動かせません。
そして権限が無いときは、セレクトが操作できないだけでなく、候補にいま入っている人しか並びません。ここは開発の後半に入ったセキュリティレビューで直した箇所です。それまでは割り当てを一切変更できない相手にも候補の全一覧を返していて、購読者以外の全ロールぶんのユーザーIDと表示名が渡っていた。WordPress本体も投稿を持つ著者は公開しているので上乗せは大きくないのですが、渡す必要の無いものを渡していることに変わりはない。いまは権限が無ければ現在値の1件だけを返します。
つまり「同僚の名前が候補に出てこない」の見分けは二段階です。欄が灰色なら権限の話。触れるのに名前が無いなら、ここから先の条件の話。
担当者の候補に残るのは、権限とページの編集権限を両方持つ人
担当者に指名できるのは「確認を実行」する権限を持ち、かつその投稿を編集できるユーザーです。既定では管理者・編集者・投稿者が確認の権限を持ちますが、投稿者は他人の投稿と固定ページを編集できないので、その投稿の担当者候補には出ません。承認者はもう一段狭く、「承認を実行」する権限が要ります。既定でこれを持つのは管理者と編集者だけ。担当者との兼任は保存できません。この2つの枠をどう使い分けるかはもう1人の目を通す流れを書いた記事のほうに。
編集権限まで条件に入れているのは、確認作業の画面が投稿本文やフィールドの値をそのまま出すからです。開けない人を指名できてしまうと、指名された本人には何も見えない管理対象ができる。
条件を候補の絞り込みだけで担保していない点も書いておきます。判定は5つの経路——投稿の編集画面、フィールドのメタボックス、ブロックのインスペクタ、一覧の一括操作、運用ルール——のすべてが同じ関数を通ります。候補プルダウンを通らない経路が3つある以上、保存側にも同じ判定が要る。別の書き方をした瞬間に「選べるのに保存で弾かれる」か「保存できるのに開けない」のどちらかが戻ってきます。
制約もひとつ。候補として引くユーザーは表示名の順で100件までです。100件を取ってから編集権限で絞る順なので、実際に並ぶ数はそれより少なくなる。ユーザー数の多いサイトでは、置きたい人が候補に出てこないことがあります。上限は投稿の編集画面でもフィールドの行でも一覧の一括操作でも同じなので、別の入口へ回れば出てくる、という性質のものではありません。ユーザーが100人を超えるサイトでは踏みうる制約として書いておきます。
上長を置く枠だけ、絞り方が逆になっている
エスカレーション先は権限を問いません。実在するユーザーなら誰でも保存できる。これは想定している役どころが「管理上の上長や責任者」で、確認作業をしない人こそ宛先になるからです。指名しても通知が届くだけで、管理画面で見えるものは本人が持つ権限のまま変わりません。
ただし画面の候補からは購読者ロールを外しています。会員サイトで購読者が数万人いると、投稿の編集画面を1枚開くたびに、その全員を選択欄へ並べることになる。フィールドの欄は管理対象の行ごとに描くので、さらに重い。ここは権限の判定ではなく、ふつうに選ぶ相手だけを出すための絞り込みで、保存側の検証はロールを見ていません。「上長を絞る理由が無い」と「上長を全ユーザーから選ばせる必要も無い」が両立する場所でした。
担当者とエスカレーション先が同じ人になる設定は、警告は出ますが保存は通ります。兼任が意味を壊すのは承認のほうだけ、という線引きです。
一覧に出ない行と、一覧に出ているのに開けない行
管理対象の一覧に全件が出るのは、「管理対象全体を管理」する権限を持つ人か、他人の投稿を編集できる人（既定では管理者・編集者）。それ以外の人に見えるのは、自分が3つの枠のどれかに指名されている行と、自分が作成者でかつその投稿タイプを編集できる行だけです。
判定が投稿タイプ単位であることが、ここでは読み取りにくい。投稿者は「投稿」を編集できても「固定ページ」は編集できないので、自分で作った固定ページの管理対象は一覧に出ません。開発している間の受け入れテストで「投稿者の一覧が26件から24件に減ったのはなぜか」という質問が出たことがあって、減った2件がまさにこれでした。画面からは根拠が読み取れないので、説明が無いと不具合に見えます。
もうひとつ紛らわしいのが、この絞り込みは設定の「管理対象とする投稿タイプ」とは無関係だということ。設定のチェックを外しても既存の行は生き続け、期限も進みます。設定を根拠に一覧を絞ると、その行が作成者本人の一覧からだけ消えて辿れなくなる。だから連動させていません。
そして、一覧に出る＝開ける、ではありません。一覧はデータベース側で近い条件に絞ってから並べていて、開けるかどうかの最終判定は詳細画面で、その投稿を編集できるかどうかで行います。指名された本人に行が見えていないと状況を直しようがないので、見えるけれど開けない行は意図して残してあります。
指名の条件を満たさない人が、担当者に入ったまま残っていたら
割り当てに編集権限の条件を足したのは開発の途中です。それ以前に作られた行や、指名したあとで本人のロールを下げた行は残りえます。
こういう行のデータは自動で書き換えません。運用中の割り当てが黙って消えるほうが困るからです。代わりに一覧の上へ警告を出します。「担当者・承認者が対象の投稿を編集できない管理対象が N 件あります。指名された本人が確認作業に入れないため、割り当てを見直してください。」——削除済みのユーザーが入っている行は別の警告で知らせているので、この件数には数えません。同じ行について2つの警告が並ぶと、どちらを直せばいいのか読めなくなる。
運用ルールで担当者を配っている場合は、条件を満たさなかったときの挙動が少し違います。ルールを保存する時点では対象の投稿が決まっていないため、そこでは権限だけを見る。実際に投稿へ初期値を当てる瞬間に編集権限を判定し、満たさなければ担当者や承認者を空のまま管理対象を作り、理由を履歴に残します。ルールの定義自体は書き換えません。「ルールに書いたはずの担当者が入っていない管理対象」があるとしたら、これです。
なお、担当者が空でも承認の待ちが発生しても、作業そのものは止まりません。指名が決めるのは通知の宛先と「自分の担当」画面の絞り込みで、操作の鍵ではないからです。
ロールを決めると、見える範囲まで一緒に決まる
ここまでを逆から読むと、指名の設計はロールの設計とほぼ同じ問題になります。
誰かに他人の記事や固定ページの担当を持たせたいなら、その人には編集者以上のロールか、同等の個別権限が要ります。ところが他人の投稿を編集できる人には、管理対象の一覧が全件見える。担当できる範囲を広げると、見える範囲も一緒に広がる作りです。編集部で記事を分担して確認するなら編集者、書き手が自分の記事だけを持つなら投稿者。この2択がそのまま「その人の一覧に何行並ぶか」を決めます。
社外の人に担当を渡すときはこの組み合わせが効いてくるので、配置の考え方は社外と分担する場合の記事にまとめてあります。
指名の条件を一行にすると、担当者は「確認する権限＋そのページを開ける」、承認者は「承認する権限＋そのページを開ける」、上長の枠は「実在すること」。この3行を先に決めておくと、管理対象を作る側で迷わなくなります。
製品ページは コンテンツ更新管理 にあります。
