リストの行

list フィールドの行がどのように検証されるか

list フィールドは行を保持し、各行はそのサブフォームのインスタンスで、行エディターで入力します。 subform を持つ yaml フィールドも、そうした行の 1 つです。サーバーはこれらを、ブラウザーの行エディターと同じように扱います。各行はサブフォームを通じて解決され、フォームの値が __parent__ となり、ルールがチェックされ、計算フィールドが評価されます。ネストしたリストも同じように動作します。行自体のリストでは、 $(__parent__.__parent__.x) でフォームに到達できます。

行は次のようにチェックされます。

ユーザーがエディターで追加または編集した行 は、解決され、検証されます。
誰も触れていない行 (リスト自体の既定値、式、クエリによって生成された行。たとえば ACL リストの既存のエントリ) は、ブラウザーと同じように 受け取ったとおりのまま 通過します。再検証されず、何も追加されません。後から書かれたルールに反する既存のエントリがあっても、起動は止まりません。
削除済みとしてマークされた行 (リストの deleteMarker ) は、そのまま保持され、検証されません。

リクエストを信頼せずにこれらの行を区別するため、サーバーは起動時の検証の中で、リスト自体のソース (既定値、それがなければ式またはクエリ) を再度実行します。エディターを経由していない行が変更なしで通過するのは、 そのソースが生成する行のいずれかである場合だけ です。それ以外の行 (REST の呼び出し元が作り出した行など) は、編集された行と同じように解決され、検証されます。そのため、単なる行がチェックを回避することはできず、一方でブラウザーの触れられていない行は引き続き変更なしで通過します。

ブラウザーのユーザーがこれに気づくのは、1 つのケースだけです。フォームを開いてから起動するまでの間にソースのデータが変わり (その間にエントリが変更または削除された)、かつその行がサブフォームのルールに反する場合です。その行はもうソースの行とはみなされないため、検証され、起動はその行の名前とともに拒否されます。たとえば acls[2].user_or_group (regex) です。

失敗した行は、 rowErrors に index とともに表示され ( yaml フィールドには index はありません)、ログには disks[1].size (maxValue) のように表示されます。

各行がサブフォームのクエリを実行するため、1 回の起動に含められる行は、すべてのネストレベルを合わせて最大 500 行 です。

行のマーカー

リストが行に設定するマーカー ( insertMarker、 updateMarker、 deleteMarker。 insertMarker がない場合、リストが allowDelete: false、 deleteMarker、 updateMarker のいずれかを設定していれば、新しい行には __inserted__ が付きます) は、マーカーを持つすべての行で playbook に届きます。削除された行は削除マーカー付きで送信されるため、 playbook はその行を削除できます。6.4.1 より前は、リストの行がマーカーを持つのは、サブフォームがそれを (非表示の) フィールドとして宣言している場合だけでした。