Linear migration metadata¶

• Linear issue: TAK-261
• Linear URL: https://linear.app/takayuki-komoda/issue/TAK-261/core-gui-楽観ロック設定を整理し承認後の更新方針へ置き換える
• Linear status: Backlog
• Linear team: Takayuki Komoda
• Linear project: EPAA Core
• Linear assignee:
• Linear labels:
• Linear created: 2026-09-05T13:51:26.581Z
• Linear updated: 2026-09-08T14:38:55.677Z
• Linear archived:

Original description¶

背景¶

Core GUI のアプリ詳細設定にある ロック設定 は、楽観ロック、楽観ロック項目、状態項目、ロック値、ロック時編集可項目、明細もロック が同じ領域に並んでいる。

しかし、楽観ロックは別セッション更新時に lock_version で競合を検出する標準機能であり、ユーザーが項目名を設定する性質のものではない。楽観ロック項目 = lock_version のような固定値を画面に出す意味も薄い。

一方で 状態項目 / ロック値 は、楽観ロックではなく「特定の業務ステータスになったレコードを編集不可にする」業務ロックである。現在の表示では、ユーザーが何を設定すべきか分かりにくい。

また、本システムでは承認済みデータを直接更新せず、変更申請・一時データとして保持し、次の承認で正本へ反映するモデルがある。そのため「承認済みだから編集禁止」という用途は、既存の承認ドラフト分離モデルと役割が重複しやすい。

台帳データのように承認後も変更申請で更新していくものと、見積書・契約書・発行済み文書のように一度承認/発行したら固定するものを、アプリ単位で分かりやすく選べるようにする。

要件¶

• Core GUI の簡単モードでは、固定の 楽観ロック項目 を表示しない。
• lock_version による楽観ロックは標準機能として扱い、通常ユーザー向けの設定値にしない。
• 状態項目 / ロック値 / ロック時編集可項目 / 明細もロック を、少なくとも簡単モードの 楽観ロック 配下から外す。
• 代わりに、アプリ単位の 承認後の更新方針 を設定できるようにする。
• 更新方針の候補は最低限、以下を検討する。
  • 更新可能: 承認済みデータも変更申請により更新できる。台帳・マスタ系向け。
  • 固定: 承認/発行後は更新不可とし、必要な場合は改訂版・再発行など別レコード/別版で扱う。見積書・契約書・発行済み文書向け。
• 既存の status_lock 相当の細かい制御を残す場合は、詳細モードまたは拡張設定として名称と役割を明確化する。

受入条件¶

• 簡単モードで、ユーザーが lock_version や 楽観ロック項目 を意識しなくてよい。
• 楽観ロックと業務状態ロックが同じ設定に見えないUIになっている。
• 承認後の更新方針 の各選択肢について、生成アプリでの更新・変更申請・削除・明細編集への影響が設計に明記されている。
• 固定 を選んだ場合、承認済み/発行済みデータに対してどの操作を禁止するかが明確である。
• 更新可能 を選んだ場合、既存の変更申請・一時データ分離モデルと矛盾しない。
• メタデータに新しい設定を追加する場合は、Core GUI から作成・編集・削除できる。
• YAML直接編集だけでしか扱えない設定を正式仕様にしない。
• 既存 status_lock との互換、移行、廃止、詳細モード残置のいずれかの方針が決まっている。

注意事項¶

• この issue は Core GUI の設定モデル見直しを対象とする。
• 承認済みデータの変更申請を一時データとして分離する既存モデル自体の再実装は対象外。
• 関連: TAK-79 承認済みデータの変更申請をJSONBドラフト分離で実装する。
• 関連: TAK-84 ワークフロー段階別入力セクションと項目編集制御を実装する。
• 詳細モードに業務状態ロックを残す場合でも、名称は 楽観ロック ではなく 状態による編集制限 など、役割が分かる表現にする。

追加方針: 楽観ロックと状態ロックの行分離¶

ユーザー合意済みの方針として、楽観ロックと状態ロックは同じ ロック設定 内で混在させず、画面上も別行・別ブロックとして分けて表示する。

• 楽観ロック は同時更新検知の標準機能として扱う。
• 楽観ロックで使う項目/テーブル/カラムは常に固定値とし、通常UIには表示しない。
• lock_version などの固定内部項目を、ユーザーが選択・入力する設定値として見せない。
• 明細もロックするかどうかは常に true とし、通常UIには表示しない。
• 状態ロック は楽観ロックとは別行に分け、業務状態による編集制限として扱う。
• 状態ロックを残す場合は、名称を 状態による編集制限 などに変更し、状態項目・ロック値・編集可項目の意味が分かるUIにする。
• 簡単モードでは、固定値や内部実装項目を出さず、必要な場合は 承認後の更新方針 のような業務判断だけを表示する。

追加受入条件¶

• 楽観ロックと状態ロックが、同じ設定行に混在して表示されない。
• 簡単モードで 楽観ロック項目 / lock_version / 固定テーブル・固定カラムが表示されない。
• 明細もロック は常に true として保存・生成され、通常UIには表示されない。
• 状態ロックを詳細モードに残す場合は、楽観ロックとは別の設定として見える。
• 固定値を非表示にしても、既存 metadata の読み込み・保存・生成結果が壊れない。

追加方針: 状態ロックの利用有無と選択肢表示¶

ユーザー合意済みの方針として、状態ロックは YAML 構造を変更せず、GUI のユーザビリティ改善として整理する。

• 状態ロックには 使用する / 使用しない を切り替えるチェックボックスを用意する。
• チェックが OFF の場合、状態項目・ロック値・ロック時編集可項目などの詳細入力は無効化または非表示にする。
• チェックが ON の場合だけ、状態ロック関連の詳細設定を表示・編集できるようにする。
• このチェックボックスは YAML の新規項目を増やすためのものではなく、既存の状態ロック設定の有無を GUI 上で分かりやすく扱うための表示制御とする。
• 状態項目の選択肢は、物理名と論理名を併記する。
  • 例: status / ステータス
• ロック値の選択肢も、値の物理名/コードと論理名/表示名を併記する。
  • 例: approved / 承認済み
• 物理名だけ、または論理名だけではなく、生成・DB観点と利用者表示の両方が分かる表示にする。

追加受入条件¶

• 状態ロックを使わないアプリでは、関連項目を見ずに設定を完了できる。
• 状態ロックを使う場合だけ、状態項目・ロック値などの詳細を設定できる。
• 状態項目候補で、フィールド物理名と日本語名が同時に確認できる。
• ロック値候補で、値コードと表示名が同時に確認できる。
• YAML の構造変更なしに、既存 metadata の状態ロック設定を読み書きできる。