本シリーズについて：全体構成はこちら
課題
取引先の担当者は、kViewerの確認書の詳細画面に表示される「FormBridge編集ボタン」から、確認書の実績データを追記・修正できます。一時保存したデータに後から追記できる点は便利な一方で、提出後も同じボタンから編集できてしまうという課題がありました。
確認書は提出後、社内の業務担当部門・経理部門による確認フェーズに入ります。確認中や確認後に取引先側でデータが書き換えられると、社内で確認した内容と実際のデータに差異が生じてしまうため、「提出後は取引先から編集できない」状態にする必要がありました。
しかし、kViewerの標準設定には、レコードのステータスに応じて編集ボタンの表示・非表示を切り替える機能が用意されていません。kViewerのページを閲覧、編集用と複数用意する事で実現する方法がありますが、利用者の利便性からJavaScriptカスタマイズで独自に実装することにしました。
実行内容・取り組んだこと
ステータス連動のボタン制御の実装
確認書の「受付ステータス」に応じて、kViewer詳細画面のFormBridge編集ボタンの表示・非表示を切り替えるカスタマイズを実装しました。
- 一時保存：編集ボタンを表示（取引先は追記・修正が可能）
- 提出済み：編集ボタンを非表示（取引先は閲覧のみ）
処理の流れ
- 取引先の担当者がkViewerで確認書の詳細画面を開く
- 詳細画面の表示に合わせてJavaScriptが起動し、レコードの「受付ステータス」を取得する
- ステータスが「一時保存」の場合は、編集ボタンをそのまま表示する
- 「一時保存」以外の場合は、画面上の編集ボタンを非表示にする
kViewerには、詳細画面の表示時にJavaScriptの処理を実行できる仕組み（イベント）が用意されているため、これを利用してステータスを判定しています。ボタンの非表示は、DOM操作（画面を構成するHTML要素をJavaScriptで直接操作すること）で実現しました。
実施ポイント
① 「提出ロック」をkViewer側で実現
記事①で紹介した「二段階の編集ロック設計」のうち、「提出ロック」を担うのが本カスタマイズです。
- 提出ロック：提出後は取引先から編集不可（本カスタマイズでkViewerの編集ボタンを制御）
- 締めロック：締め処理後は全ユーザーが編集不可（kintone側で制御）
取引先の操作窓口であるkViewer上で制御することで、取引先が入力するフェーズと、社内で確認するフェーズを明確に分離しています。
② 「一時保存のときだけ表示する」判定条件
判定条件は「提出済みなら非表示」ではなく、「一時保存のときだけ表示」としています。今後ステータスの種類が増えた場合でも、意図せず編集ボタンが表示されることがなく、処理変更が不要な設計です。
③ 取引先にとってわかりやすい画面
編集できない状態ではボタン自体を表示しないため、取引先の担当者は「このデータはもう編集できない」ことを画面上で直感的に判断できます。誤って編集しようとして操作に迷うこともありません。
まとめ・効果
このステータス連動のボタン制御により、以下の効果を見込んでいます。
- 提出後の誤修正の防止：取引先が提出済みのデータを誤って修正するリスクを低減
- 社内確認との整合性の確保：社内で確認した内容と実際のデータに差異が生じない
- わかりやすい操作性：編集できるかどうかが画面上で明確になる
kViewerの標準設定で対応できない要件に対して、JavaScriptカスタマイズにより、ステータスに応じた編集制御を実現しました。同様の考え方で、ステータスに応じて表示する項目や案内文を切り替えるといった応用も可能です。（※DOM操作は推奨されていません。kViewerのアップデートにより画面構成が変わると動作しなくなる可能性があるため、実装をする場合は実装後の管理などを踏まえてご判断ください。）
← 記事③ に戻る
→ 記事⑤ へ
