kintoneのテーブル内項目を条件に応じて必須にしたいときは、何を条件にして、どの明細列へ入力を求めるかを整理します。例えば、通常の申請では任意の「理由」を、申請区分が「特別」のときだけ各明細行で必須にする運用です。
この記事では、条件付き入力制御・書式変更プラグインを使った設定例を紹介します。条件にはテーブル外の項目を使い、条件に一致すると、対象列の各行へ入力を求めます。明細行ごとの値を条件として判定する例とは異なります。
2行の申請明細で必須化の判定を確認する
「申請区分＝特別なら、各明細の理由を必須にする」という説明用ルールの確認表です。標準の必須設定や別の入力制御がない前提で、目指す保存結果を並べています。実機の試験結果ではありません。
| 申請区分 | 1行目の理由 | 2行目の理由 | 期待する確認結果 |
|---|---|---|---|
| 通常 | 空欄 | 空欄 | この条件による必須エラーを出さない |
| 特別 | 緊急手配のため | 空欄 | 2行目の未入力を確認し、保存を止める |
| 特別 | 緊急手配のため | 代替品を追加するため | この必須条件を満たして保存できる |
| 特別→通常へ変更 | 入力済み | 空欄 | 条件を外した後にエラーが残らないか確認 |
条件に使うのはテーブル外の申請区分です。金額の大きい行だけを対象にする例ではありません。新しい行を追加した場合、編集画面で行を増やした場合、いったんエラーを出してから条件を変更した場合も確かめます。一般項目の実画面は条件付き必須の基本設定で確認できます。
テーブル内項目をいつ必須にしたいかを決める
標準のフォーム設定では、フィールドごとに必須入力を指定できます。常に必要な項目なら、まずkintone標準のフォーム設定を確認してください。
一方、特別申請のときだけ、特定の明細列へ入力を求める場合は、条件と対象を分けて設計します。今回は、次の説明用のアプリ構成を使います。
- テーブル外：申請区分。選択肢は「通常」「特別」。
- テーブル：申請明細。
- テーブル内：品名、金額、特別申請の理由。
- 入力ルール：申請区分が「特別」のとき、各明細行の理由を必須にする。
これは設定を考えるための例です。お客様のアプリで動作を確認した事例ではありません。実際には、現在のフィールドコードと種類に合わせて設定します。
手順1：条件項目と対象のテーブル列を用意する
まず、フォームへ条件項目とテーブル列を配置します。理由を条件付きで必須にする場合、標準の必須設定と役割が重複していないかを確認してください。
標準側で常に必須になっている項目は、プラグインの条件を外しただけでは任意入力になりません。通常の申請で空欄を許可したいなら、どちらの設定で必須を管理するかを整理します。
また、対象列が非表示・編集不可になる別の設定がないかも確認します。入力できない状態で必須を求めると、利用者が保存まで進めないためです。
手順2：条件に一致したらテーブル内項目を必須化する
- PCでプラグイン設定を開き、「条件設定を追加」を押します。
- 条件設定名を「特別申請の理由を必須」など、目的が分かる名前にします。
- 条件項目でテーブル外の「申請区分」を選びます。
- 条件を等しい指定にし、条件値で「特別」を選びます。
- 対象項目で、申請明細内の「特別申請の理由」を選びます。
- 実行内容を「入力必須化」にします。
- 設定を保存し、アプリを更新します。
対象項目では、通常項目とテーブル内項目を取り違えないようにします。同じ名前の列がある場合は、テーブル名とフィールドコードも確認してください。
条件を複数にする場合は、ANDならすべて一致、ORならいずれか一致です。最初は1条件で確かめ、必要になってから条件を追加すると、意図しない必須化を調べやすくなります。
手順3：通常・特別・複数行の保存を試す
次に、検証用レコードで保存時の動作を確認します。画面に印が出るかだけで判断せず、空欄のまま保存したときの結果まで確認してください。
- 通常・理由が空欄：ほかの必須条件に問題がなければ保存できる。
- 特別・理由が空欄：対象項目に入力エラーが出る。
- 特別・理由を入力：必要な入力を満たした状態で保存できる。
- 複数行・一部だけ空欄：空欄の対象行が残っていないか確認できる。
- 条件を通常へ戻す：条件付きの必須エラーが残らないか確認する。
この設定では、テーブル外の条件が一致すると、対象列の各行を確認します。「金額が一定以上の行だけ理由必須」のように、行内の値に応じて対象行を選ぶ判定とは分けてください。
テーブルの追加・編集とほかの制御も確認する
既存レコードの編集でも、同じケースを試します。行を増やしたときや、条件項目を途中で切り替えたときにも、保存できる状態か確認します。
さらに、同じ対象へ入力必須化・非表示・編集不可などが重なっていないかを見直します。標準アクセス権で編集できない項目を必須にする設計も避け、実際の利用者で確認してください。
入力必須化は、追加・編集画面の保存時に確認する機能です。CSVや外部APIからの更新まで、同じ画面処理で検査するわけではありません。取り込みや連携がある場合は、別にデータ確認の手順を用意します。
必須入力と明細の計算・申請時の確認を使い分ける
条件付きの表示・書式も含む全体像は、条件付き入力制御の基本設定をご覧ください。明細の計算条件を分けたい場合は、テーブル内の条件付き計算が候補です。
保存の段階ではなく、申請アクションを実行する場面で入力を確認したい場合は、プロセス管理の入力確認を確認してください。どのタイミングで不足を知らせるかを分けて設計します。
この記事は条件付き入力制御・書式変更プラグイン1.0.17の仕様に基づく説明です。最新の対応範囲は詳細ページをご覧ください。
設定・運用の整理を相談する
検証用のアプリで操作を確認してから運用へ反映してください。項目設計や利用者への展開も一緒に進めたい場合は、ご相談いただけます。継続的な支援はサポートプランをご覧ください。