﻿# 05C-顧客権限ページ

## 1. ドキュメントの位置づけ

本ドキュメントは、顧客詳細ページの `権限` / `編集` タブにおける基本情報編集、タグ編集、コンテンツ権限選択、個人権限追加、最終権限の保存ルールを定義する。

顧客一覧ページ、顧客詳細概要、顧客新規登録については、それぞれ以下を参照：

- `05A-顾客列表页.md`
- `05B-顾客详情页.md`
- `05D-新增顾客.md`

タグ本体のルールは `02-顾客标签管理.md`、タグ権限テンプレートのルールは `03-标签权限模板.md`、`customer_status` 同名タグの設定境界は `bak-04-第三方字段映射与权限判定.md` を参照。

本タブは顧客詳細ページ内の編集状態であり、独立したページではない。左側ナビゲーションや一覧から別途2つ目の「顧客権限編集ページ」を開いてはならない。KASIKA 連携モジュールは `概要` タブでのみ表示し、本タブでは KASIKA の紐付け関係の編集、変更、同期、再試行操作は提供しない。

## 2. ページ目標

- 既存の顧客詳細編集 UI とコンテンツ選択方式を可能な限り踏襲し、既存業務への影響を最小限に抑える。
- 管理者が同一タブで「基本情報編集 → 顧客タグ調整 → コンテンツ権限選択 → 個人権限追加 → 保存」を完了できるようにする。
- 顧客の最終アクセス権限はタグ権限テンプレートによって駆動され、少数の顧客単位の例外調整をサポートする。
- 最終権限の保存時は VISTA 側のタグと権限のみを更新し、KASIKA の顧客同期はトリガーしない。
- KASIKA の紐付け関係は本ページでは編集しない。連携顧客と非連携顧客の VISTA タグおよび権限編集機能は同一とする。

## 3. ページ構成

ページは現在の顧客詳細ページのスタイルを維持し、顧客詳細ページの2つ目のタブとする。独立した KASIKA ブロックは追加しない。

### 3.1 基本情報編集エリア

基本情報編集エリアは、現在の HOME VISTA 顧客編集フォームを踏襲し、VISTA ローカルの顧客情報の編集のみを担う。

編集可能なフィールドは既存ページを踏襲し、以下を含む（これらに限らない）：

- 顧客名。
- フリガナ。
- メールアドレス。
- 電話番号。
- 流入経路。
- 共有メモ。

表示ルール：

1. VISTA ローカル顧客情報のみを編集する。
2. KASIKA に連携済みの顧客の場合、メールアドレスフィールドは読み取り専用の無効状態で表示し、編集、クリア、保存インターフェースによる上書きは許可しない。
3. KASIKA に未連携の VISTA 顧客の場合、メールアドレスは既存の HOME VISTA ルールに従って編集および検証する。
4. KASIKA の `cid` / `customer_id`、KASIKA メールアドレス、`customer_status`、連携状態、直近の同期結果または失敗理由は表示・編集しない。これらの内容は `概要` タブの KASIKA 連携モジュールでのみ表示する。
5. 基本情報の編集では KASIKA API を呼び出さない。

### 3.2 タグ編集エリア

タグ編集は本ページの中心的な操作エリアである。

表示内容：

- 現在の顧客が保有するタグ。
- 選択可能な VISTA タグ一覧。
- タグの検索またはフィルタリング機能。既存コンポーネントの機能をそのまま使用すればよい。

動作ルール：

1. ユーザーはタグチップの選択モードで顧客タグを選択または解除する。
2. ページ表示および編集時は、タグの由来やタグ種別を区別しない。すべての VISTA タグを同等に扱う。
3. `customer_status` 同名タグがシステムによって顧客タグ関係に補完されている場合、本ページでは通常の VISTA タグとしてのみ表示し、自動由来は表示しない。
4. ユーザーは本ページで `customer_status` 同名タグを解除できる。この操作は VISTA ローカル顧客タグのみを変更し、KASIKA に書き戻さず、KASIKA の `customer_status` も変更しない。
5. `customer_status` の状態権限自動更新スイッチが有効な場合、その後の KASIKA 同期処理で当該顧客を処理する際に、現在の `customer_status` に基づいて同名タグを再調整する。同名タグが存在する場合はタグを補完し、同名タグが存在しない場合は自動で作成せずスキップを記録する。
6. タグ変更後、ページは設定済み権限テンプレートのタグにヒットする権限テンプレートの和集合をリアルタイムで再計算する。
7. タグ変更が保存される前は、ページのドラフト状態として扱い、C 端の最終アクセス権限には即時影響しない。

### 3.3 コンテンツ権限選択エリア

コンテンツ選択エリアは、VISTA 既存の顧客権限設定ページのコンテンツ選択方式とコンテンツカードスタイルを踏襲し、既存のアクセス可能なコンテンツオブジェクト（間取り図、モデルルーム、外観、資料集、ナビゲーションメニューなど）をカバーする。

表示ルール：

1. テンプレートが付与したコンテンツはデフォルトでチェックされ、テンプレート由来とマークされる。
2. テンプレートが付与していないがユーザーが手動でチェックしたコンテンツは、個人権限追加として保存される。
3. テンプレートが付与したコンテンツはチェック状態とテンプレート由来の表示を許可するが、今期は顧客権限ページで当該テンプレート権限を単独で削除または解除することはサポートしない。
4. ユーザーがテンプレート付与済みコンテンツを解除しようとした場合、システムは当該項目のチェックを維持し、操作者に toast で通知する：この権限はタグ権限テンプレートに由来するため、顧客権限ページで単独で解除することはできません。解除する必要がある場合は、顧客タグまたは対応するタグ権限テンプレートを調整してください。
5. 「現在の権限合成結果」サマリーパネルは表示しない。
6. ページ上部にタグ、テンプレート、テンプレート由来数、個人追加数、最終アクセス可能コンテンツ数を追加表示しない。
7. コンテンツ選択エリアは、既存のコンテンツ選択カードのビジュアルスタイルを必ず保持すること。デザイン案が「今期はコンテンツ権限選択が不要」と表現しないようにする。
8. コンテンツ選択エリアは、ファーストビューで既存コンテンツをすべて展開する必要はないが、正式な実装では既存の権限コンテンツツリーまたはグループ選択機能を踏襲すること。
9. 既存のコンテンツ権限選択における関連ロジックは必ず保持すること。例えば、間取り図とモデルルームの親子連動、コンテンツ権限とナビゲーションメニュー表示の連動など。これらの連動は既存の VISTA 権限選択ルールに従って実行され、タグ権限テンプレート由来であることを理由に解除されない。

#### 3.3.1 テンプレートベースラインと個人追加

顧客権限編集は、まず現在の顧客タグがヒットする権限テンプレートの和集合をベースラインとし、その上で管理者が個人権限を追加できるようにしなければならない。テンプレート権限を自由に増減できる顧客単位の権限リストにコピーしてはならない。

1. 1つ以上の現在のタグテンプレートによってヒットした権限は、すべて保護された有効権限である。同じコンテンツが複数のテンプレートに同時にヒットする場合でも、いずれかのテンプレートが引き続きヒットする限り、当該コンテンツを解除してはならない。
2. テンプレートがヒットしたチェックはテンプレート由来とマークできるが、具体的なタグ由来は表示してはならない。また、チェック解除、親階層の選択解除、一括解除、その他の同等操作によって有効権限を減らしてはならない。
3. 管理者がテンプレートによる権限を減らす必要がある場合、タグ編集エリアで該当顧客の対応タグを解除し、そのタグテンプレートが当該顧客の権限計算に参加しないようにするしかない。顧客権限ページでタグテンプレート自体を削除、変更、無効化することはできない。
4. テンプレートがヒットしていないコンテンツのみ、管理者が単独でチェックできる。そのチェックは個人権限追加として保存される。個人権限追加は既存のコンテンツ選択ルールに従って解除できる。
5. タグのドラフトが変更された場合、ページはまずテンプレートベースラインを再計算し、その上でどのチェックが個人権限追加操作として扱えるかを判定する。保存前は、もはやテンプレートにヒットしていない過去の状態を誤って解除不可と判定してはならない。

#### 3.3.2 ファイル・フォルダ共有のアップグレード制限

ファイルおよびフォルダ共有も「テンプレートベースラインは増やすことはできても減らすことはできない」という原則に従う。

1. いずれかのヒットしたタグテンプレートがフォルダの共有権限を付与している場合、そのフォルダ共有はテンプレートベースラインである。管理者は顧客権限ページでこれを配下のファイルのみの共有に変更したり、フォルダの解除、親階層の選択解除、一括操作によってファイル共有に縮小したりしてはならない。
2. タグテンプレートが1つ以上のファイルの共有権限のみを付与している場合、管理者はその所在フォルダの共有権限を追加でチェックし、当該顧客をフォルダ共有にアップグレードできる。この操作は個人権限追加に該当し、タグテンプレートの既存のファイル共有設定は変更しない。
3. フォルダ共有にアップグレードした後、管理者はこの個人追加のフォルダ共有を解除できる。ただし、テンプレートがヒットしたファイル共有は保持されなければならず、最終権限はタグテンプレートのファイル共有範囲に戻る。
4. フォルダ共有によってアクセス可能と表示される配下ファイルは、テンプレートがヒットしたファイルを逆に解除できると解釈してはならない。ページおよび保存ロジックは、最終的な有効権限とその由来に基づいて解除が許可されるかどうかを判定する。

### 3.4 保存エリア

保存前に今回の変更サマリーを表示する：

- タグの追加 / 解除数。
- 個人権限追加の変更。

保存ルール：

1. 保存後、当該顧客の VISTA 基本情報、タグ関係、個人権限追加を更新する。
2. 保存では KASIKA API を呼び出さない。
3. 保存では KASIKA 顧客フィールド、タグ、アクセスフィールドに書き戻さない。
4. 保存成功後、C 端のアクセス権限インターフェースは最新結果を返す。

## 4. 権限計算ルール

1. 顧客は複数の VISTA タグを保有できる。
2. 今期の最終権限 = タグ権限テンプレートの和集合 + 個人権限追加。
3. タグ権限テンプレートの和集合には、現在の顧客が保有するタグのうち権限テンプレートが設定済みのもののみを含む。
4. 個人権限追加は、個別の顧客がアクセスする必要があるがタグテンプレートがカバーしていないコンテンツを補完するために使用する。
5. 今期は「顧客単位の除外 / タグテンプレート権限の単独削除」機能を提供しない。テンプレートがヒットしたコンテンツは、顧客権限ページのタグ編集エリアで対応する顧客タグを解除するか、タグ権限テンプレート管理でテンプレート設定を変更することによってのみ変更できる。コンテンツのチェック、親子連動、一括操作、フォルダ／ファイル階層の切り替えによってテンプレートが付与した権限を減らすことはできない。
6. タグ権限テンプレートが新規作成または編集された後、権限インターフェースは最新のテンプレート設定に基づいてリアルタイムで計算結果を返す。管理者が別途一括適用タスクを実行する必要はない。
7. 顧客権限ページが保存するのは顧客タグ関係と個人追加項目であり、静的テンプレート権限スナップショットを最終権限としてコピーすることはない。
8. 間取り図、モデルルーム、ナビゲーションなどの既存の関連ルールは、最終権限集合の上で引き続き有効となる。例えば、モデルルームが対応する間取り図に依存する場合、モデルルームが個人追加に由来するとしても、対応する間取り図がアクセス可能でなければならない。ナビゲーションメニューを表示するかどうかは、既存のコンテンツとナビゲーションの関連ルールに従って判定される。

## 5. 旧来の例外項目の処理

タグやテンプレートの変更により、過去の個人追加項目が直感的でなくなった場合でも、今期は自動的なカスケード削除は行わない。管理者が過去に設定した顧客単位の例外を誤って削除することを防ぐためである。

1. 過去の個人追加項目は引き続き保持する。
2. 過去データに単独除外項目がすでに存在する場合、今期のページでは除外項目の新規追加や編集を提供しない。開発はマイグレーションまたは互換処理でテンプレート権限に対するその減算効果を無視するか、バックエンドのデータガバナンス方針に従って別途クリーンアップできるが、フロントエンドでは操作可能な機能として表現しない。
3. コンテンツオブジェクトが削除済みまたは利用不可の場合、既存のコンテンツ権限ページのルールに従って利用不可表示または自動無視とする。本ページに KASIKA の特別なロジックを追加しない。

## 6. 連動異常の境界

1. KASIKA 連動異常または API KEY 不完全の場合でも、タグ編集と `権限` タブはグレーアウトしない。
2. 顧客権限ページは VISTA ローカル機能であり、KASIKA API のリアルタイム利用可能性に依存しない。
3. 権限ページの保存では KASIKA API を呼び出さない。
4. 権限ページの保存では KASIKA 顧客フィールド、タグ、アクセスフィールドに書き戻さない。
5. 権限変更が `customer_status` 同名タグ設定に由来する場合、同期ログは `04-统一顾客联动同步流程.md`、`07-同步日志与追溯.md` に従って記録する。権限ページは最終的な VISTA タグと権限結果のみを表示する。
6. 本ページは KASIKA 関連モジュールを表示せず、KASIKA の紐付け関係の編集、変更、同期、再試行エントリを提供しない。

## 7. 受け入れ基準

1. 顧客詳細ページには `概要` と `権限` / `編集` の2つのタブのみを保持する。`連動履歴`、`履歴` は詳細ページに表示せず、関連情報は同期ログまたは概要フィールドに含める。
2. 顧客詳細ページから権限編集エントリをクリックすると `権限` タブに切り替えられる。
3. `権限` タブには、KASIKA 連携モジュール、KASIKA フィールド、紐付け関係の操作ボタン、変更ボタン、同期ボタン、再試行ボタンを表示しない。
4. `権限` タブには基本情報編集フォームを表示する。KASIKA 連携済み顧客のメールアドレスは読み取り専用とする。
5. `権限` タブで現在の顧客タグを表示および変更できる。
6. `権限` タブで顧客タグを変更でき、コンテンツ選択状態はタグテンプレートのルールに従って更新される。
7. `権限` タブでテンプレートが付与していないコンテンツに個人権限追加を設定できる。
8. ページに「現在の権限合成結果」サマリーパネルを表示しない。
9. 保存後に戻るまたはページをリフレッシュしても、当該顧客の基本情報、タグ、コンテンツ権限の変更を確認できる。
10. 権限の保存で KASIKA 顧客同期はトリガーしない。
11. KASIKA 連動異常または API KEY 不完全の場合でも、基本情報、タグ編集、権限編集は利用可能である。
12. 権限ページには、タグの由来、自動タグ／手動タグの区別、`customer_status` 設定由来を表示しない。ただし、KASIKA 同期によって取得された構造化された `customer_status` は、その後の同期キャリブレーションに引き続き使用される。
13. タグテンプレートが付与したコンテンツを解除しようとした場合、ページはチェックを維持し toast 通知を表示し、単独除外として保存しない。
14. 間取り図とモデルルーム、コンテンツとナビゲーションの間の既存の関連ロジックは、顧客権限ページでも引き続き有効である。
15. タグテンプレートがフォルダ共有を付与している場合、顧客権限ページでファイル共有に降格させてはならない。タグテンプレートがファイル共有のみを付与している場合、管理者が個人権限追加によってフォルダ共有にアップグレードすることを許可する。

## 8. ユーザー用例

### 用例 1：顧客権限ページでタグを追加・削除する
- 前提：営業または管理者が顧客詳細ページの `権限` タブに入る。
- 操作：VISTA タグをチェックまたは解除する。
- 期待結果：
  - ページは設定済み権限テンプレートのタグがヒットする権限テンプレートの和集合をリアルタイムで再計算する。
  - システムは当該顧客のアクセス権限がタグ権限テンプレートに基づいて再計算されることを通知する。
  - タグの由来やタグ種別を区別しない。
  - KASIKA 顧客同期はトリガーしない。

### 用例 2：タグによる権限を確認する
- 前提：顧客が1つ以上のタグを保有している。
- 操作：ユーザーが `権限` タブに入る。
- 期待結果：
  - ページは現在の顧客タグを表示する。
  - ページは「現在の権限合成結果」サマリーパネルを表示しない。
  - テンプレートが設定されていないタグは権限を追加しない。

### 用例 3：権限タブでタグを変更する
- 前提：管理者が顧客詳細ページの `権限` タブにいる。
- 操作：顧客タグをチェックまたは解除して保存する。
- 期待結果：
  - ページは顧客タグ関係を保存する。
  - C 端のアクセス権限は最新のタグテンプレート結果に基づいて計算される。
  - 保存で KASIKA API は呼び出されない。

### 用例 4：権限タブでコンテンツを個別に調整する
- 前提：管理者が顧客詳細ページの `権限` タブにいる。
- 操作：テンプレートが付与していないコンテンツを1つチェックするか、テンプレートが付与済みのコンテンツを解除しようとする。
- 期待結果：
  - 前者は個人権限追加として保存される。
  - 後者は解除できず、ページはチェックを維持し toast 通知を表示する。
  - 最終権限は「タグ権限テンプレートの和集合 + 個人権限追加」に基づいて計算される。

### 用例 5：連動異常時の権限編集
- 前提：プロジェクトの API KEY が不完全、または KASIKA 接続に異常がある。
- 操作：ユーザーが顧客の `権限` タブに入り、タグまたは個別権限を変更して保存する。
- 期待結果：
  - タグ編集と権限編集は引き続き操作できる。
  - 保存は VISTA ローカル権限のみを更新する。
  - KASIKA API を呼び出さず、KASIKA 顧客フィールドにも書き戻さない。
  - ページに KASIKA の紐付け関係操作、同期、再試行エントリは表示されない。

### 用例 6：`customer_status` 補完タグ後の権限表示
- 前提：KASIKA → VISTA 同期、紐付け、または KASIKA エントリページのフローが `customer_status` を読み取り別途保存した後、同名タグ設定によって顧客に VISTA タグが補完された。
- 操作：ユーザーが顧客の `権限` タブに入る。
- 期待結果：
  - ページは顧客の現在の VISTA タグと対応する権限テンプレートを表示する。
  - 当該タグが `customer_status` の自動設定に由来するかどうかを表示しない。
  - 自動設定の由来を表示しない。
  - 最終権限は現在のタグとテンプレートに基づいてリアルタイムで計算される。

### 用例 7：テンプレート権限の解除がブロックされる
- 前提：顧客が保有する1つ以上のタグ権限テンプレートがコンテンツ A を付与している。
- 操作：ユーザーが `権限` タブでコンテンツ A のチェックを解除する、親階層の選択解除で解除する、または一括操作でコンテンツ A を削除する。
- 期待結果：
  - コンテンツ A は有効なチェックを維持する。複数のテンプレートが同時にヒットする場合、ヒットするタグが1つでも残っている限り、コンテンツ A を解除してはならない。
  - ページは toast で、この権限はタグ権限テンプレートに由来するため顧客権限ページで単独で解除できないことを通知する。
  - 保存後も単独除外や上書き項目は生成されない。権限を減らす必要がある場合は、タグ編集エリアでコンテンツ A をヒットさせているタグを解除するしかない。

### 用例 8：既存の関連ロジックを保持する
- 前提：B モデルルームが B 間取り図に依存する。特定のナビゲーションメニューが対応するコンテンツのアクセス可否に依存する。
- 操作：ユーザーが `権限` タブでタグまたは個人追加コンテンツを調整する。
- 期待結果：
  - B 間取り図がアクセス可能でない場合、B モデルルームは単独で選択できない。
  - 対応するコンテンツがアクセス可能でない場合、関連ナビゲーションは表示されないか選択不可のままである。
  - これらの連動は、権限の由来がタグテンプレートか個人追加かに影響されない。

### 用例 9：テンプレートのフォルダ共有は降格できない
- 前提：顧客がタグ A を保有し、タグ A の権限テンプレートがフォルダ F を共有済みである。
- 操作：管理者がフォルダ F を解除しようとするか、配下のファイル f1 のみを残そうとする。
- 期待結果：
  - フォルダ F の共有は有効なまま維持され、ページはこの権限がタグ権限テンプレートに由来するため、顧客権限ページで単独で解除または降格できないことを通知する。
  - ファイル f1 のみを共有する顧客単位の除外や上書き記録は生成されない。
  - フォルダ F の共有を解除する必要がある場合、タグ編集エリアでタグ A を解除するか、タグ権限テンプレート管理でテンプレートを変更するしかない。

### 用例 10：テンプレートのファイル共有をフォルダ共有にアップグレードできる
- 前提：顧客がタグ B を保有し、タグ B の権限テンプレートがファイル f1 のみを共有している。
- 操作：管理者が顧客権限ページで f1 の所在フォルダ F を追加でチェックする。
- 期待結果：
  - フォルダ F の共有は個人権限追加として保存され、顧客はフォルダ F のアクセス権限を獲得する。
  - タグ B のテンプレート設定は変更されず、テンプレートの既存ファイル f1 共有は引き続き保護される。
  - その後、個人追加のフォルダ F 共有を解除しても、顧客はテンプレートが付与したファイル f1 の共有を引き続き保有する。

## 9. 改訂履歴

| 日付 | 改訂内容 |
| --- | --- |
| 2026-07-13 | 顧客権限は現在のタグテンプレートがヒットする権限の和集合を減らせないベースラインとし、個人権限の追加のみを許可することを明確化。テンプレートがヒットしたコンテンツは、チェック解除、親子連動、一括操作、フォルダ／ファイル階層の切り替えによって逆に削除してはならないことを明記し、既存のユーザー用例を複数テンプレート同時ヒットと一括操作のカバレッジで補強。ファイル・フォルダ共有の単方向ルールを追加：テンプレートのフォルダ共有はファイル共有に降格できず、テンプレートのファイル共有は個人権限追加によってフォルダ共有にアップグレード可能。アップグレード解除後もテンプレートのファイル共有は保持される。 |