# 06_permission/06_01_permission_design.md

版：v3.1　実装の状況は `work_order_db_migration.md`（作業書）を見る

## 1. 権限設計の基本方針

### 1.1 大前提
- **権限は全て個人に付与する**
- 職務ポジションの初期権限は「デフォルト値の参考」に過ぎない（`01_07` 4節）
- 同じ職務ポジションでも個人ごとに権限が異なる
- 権限情報は `employee_permissions` テーブル（従事者ごと・権限キーごとに1行）で一元管理する
- ログイン時は `employee_permissions` から権限を取得する
- ダッシュボードの統計情報は、選択中の会社（会社切替プルダウン）に連動して表示を切り替える
- アクセス可能な会社が2つ以上ある場合、統計情報は会社ごとに集計して表示する

### 1.2 権限の対象範囲

| 範囲コード | 説明 | 例 |
|------------|------|-----|
| self | 自分のデータのみ | 自分の経費 |
| team | 同じ案件グループ | 同じ案件のメンバー |
| branch | 同じ拠点全体 | 本社の全案件 |
| all | 全社（全拠点） | 全てのデータ |

### 1.3 権限のレベル

| レベル | 名称 | 動作 |
|--------|------|------|
| 0 | なし | メニュー非表示 |
| 1 | 閲覧のみ | 画面表示、編集不可 |
| 2 | 編集可 | 編集可能 |
| 3 | 承認可 | 承認操作可能 |

※ レベルは権限の整理・表示用の区分であり、レベル間の自動連鎖（例：編集権限を付与すれば閲覧権限も自動付与）は行わない。付与のペアリングは各権限カテゴリの付与ルールに従う（会社アクセス権限については 2.6.3 節参照）。

### 1.4 権限の付与フロー

- 権限の付与・変更・剥奪は `employees/edit.html` のチェックボックスから行う
- 保存すると、`employee_permissions` の該当の行を更新する（変更は、確認者の承認後に反映。1.5節）
- `login.php` / `get_session.php` は `employee_permissions` を読んで、権限をセッションに入れる
- 権限マスタ（`permissions` テーブル）は、権限キー、表示名、説明文の定義。`employees/edit.html` のチェックボックス生成に使用する。チェックボックスの横には、説明文（何ができる権限か）を表示する
- 権限は、カテゴリ（ページ）ごとにまとめて表示する。職務ポジションの初期権限の設定（`01_07` 4節）も、同じ部品を使う

### 1.5 権限変更の即時反映
- `employees/edit.html` で権限を変更・保存した場合、対象ユーザーのPHPセッションを強制破棄する
- 対象者は次のリクエスト時に再ログインを求められ、新しい権限が即時反映される
- 詳細は `00_overview/00_03_login_session.md` 6節参照
- ただし、**権限フィールドの変更は、確認者の承認後に反映する**（`00_10_change_history.md` 4節 区分 B）。保存した時点では「承認待ち」とし、セッションの強制破棄は、承認が済んで権限が実際に変わった時点で行う。`supreme_access` を持つ人の変更は、単独で確定できる（「単独許可」として記録）。新規登録時の初期権限（8節の職務別デフォルト）の扱いは未決（案：職務別デフォルトは登録と同時に付与し、それ以外の追加は承認待ち）

---

## 2. 権限一覧

### 2.1 経費関連権限

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| expense_view_self | 自分の経費を閲覧する | self | 1 |
| expense_edit_self | 自分の経費を編集する | self | 2 |
| expense_approve_self | 自分の経費を承認する | self | 3 |
| expense_view_team | チームの経費を閲覧する | team | 1 |
| expense_edit_team | チームの経費を編集する | team | 2 |
| expense_approve_team | チームの経費を承認する | team | 3 |
| expense_view_branch | 自拠点の経費を閲覧する | branch | 1 |
| expense_edit_branch | 自拠点の経費を編集する | branch | 2 |
| expense_approve_branch | 自拠点の経費を承認する | branch | 3 |
| expense_view_all | 全経費を閲覧する | all | 1 |
| expense_edit_all | 全経費を編集する | all | 2 |
| expense_approve_all | 全経費を承認する | all | 3 |

### 2.2 案件関連権限

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| case_view_self | 自分の案件を閲覧する | self | 1 |
| case_edit_self | 自分の案件を編集する | self | 2 |
| case_view_team | チームの案件を閲覧する | team | 1 |
| case_edit_team | チームの案件を編集する | team | 2 |
| case_view_branch | 自拠点の案件を閲覧する | branch | 1 |
| case_edit_branch | 自拠点の案件を編集する | branch | 2 |
| case_view_all | 全案件を閲覧する | all | 1 |
| case_edit_all | 全案件を編集する | all | 2 |
| case_delete | 案件を削除する | all | 2 |
| investigator_add | 調査員を追加する | team | 2 |

### 2.3 従事者関連権限

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| profile_view_self | 自分のプロフィールを閲覧する | self | 1 |
| profile_edit_self | 自分のプロフィールを編集する | self | 2 |
| profile_view_branch | 自拠点の従事者を閲覧する | branch | 1 |
| profile_edit_branch | 自拠点の従事者を編集する | branch | 2 |
| profile_view_all | 全従事者を閲覧する | all | 1 |
| profile_edit_all | 全従事者を編集する | all | 2 |
| permission_assign | 権限を付与する | all | 2 |

### 2.4 会計関連権限

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| accounting_view | 会計データを閲覧する | all | 1 |
| accounting_edit | 会計データを編集する | all | 2 |
| accounting_export | 会計データを出力する | all | 2 |
| accounting_approve | 会計データを承認する | all | 3 |

### 2.5 拠点間権限

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| branch_cross_view | 他拠点のデータを閲覧する | all | 1 |
| branch_cross_edit | 他拠点のデータを編集する | all | 2 |
| branch_cross_approve | 他拠点のデータを承認する | all | 3 |

### 2.6 会社アクセス権限

#### 2.6.1 権限キー一覧

| 権限ID | 説明（日本語） | 対象範囲 | レベル | 備考 |
|--------|----------------|----------|--------|------|
| company_access_sps | 個人事業（SPS）にアクセスできる | all | 1 | 閲覧のみ |
| company_access_sps_edit | 個人事業（SPS）を編集できる | all | 2 | 編集可 |
| company_access_scsps | 法人（SCSPS）にアクセスできる | all | 1 | 閲覧のみ |
| company_access_scsps_edit | 法人（SCSPS）を編集できる | all | 2 | 編集可 |

#### 2.6.2 アクセス制御モデル

`company_access_*` は、SPS（個人事業）とSCSPS（法人）のデータ領域を分離し、所属会社に応じたデータアクセスを制御するための基本権限である。本権限は **すべての業務機能の前提条件（ゲート）** であり、これを持たないユーザーは当該会社のデータに一切アクセスできない。

本権限は粗いゲート（アクセス可否）であり、その上で各機能固有の権限（`case_list_view` / `case_detail_view_*` / `case_edit_*` など）が **AND条件** で評価される。

```
アクセス可否 = company_access_<会社>  AND  機能固有権限
```

例：SPS案件の一覧表示には `company_access_sps` **かつ** いずれかの `case_*_view` が必要。

#### 2.6.3 読み取り・編集の関係

`company_access_<会社>` と `company_access_<会社>_edit` は **別個の権限** であり、独立して付与する。編集権限は閲覧権限を構造的に含まない（レベル階層は整理上の区分であり、付与の自動連鎖は行わない）。

| 操作 | 必要な権限 |
|------|-----------|
| 当該会社のデータ閲覧 | `company_access_<会社>` |
| 当該会社のデータ編集 | `company_access_<会社>` **かつ** `company_access_<会社>_edit` |

**付与ルール**：編集権限（`_edit`）を付与する際は、必ず基本閲覧権限（`company_access_<会社>`）も同時に付与すること。`employees/edit.html` のチェックボックスUIで `_edit` を選択した場合は、対応する基本権限を自動的にONにし、OFFにはできないようにする（実装時の要件）。逆に、編集権限のみを剥奪して閲覧権限を残す（読み取り専用への降格）ことは許可する。

#### 2.6.4 サーバー側でのチェック義務

- **サーバー側必須チェック**：`company` パラメータを受け取る全APIは、冒頭で `company_access_<会社>` を検証すること。画面側だけのチェックでは不十分。
- **画面側チェック**：表示前に `window.spsUser.permissions.company_access_<会社>` を確認し、未保有時は「アクセス権限がありません」を表示。`alert()` は使用せず、画面内にインライン表示する（`04_01_08_case_permission.md` 10節準拠）。
- **`company` パラメータ改ざん対策**：クライアントから受け取った `company` は必ず `in_array($company, ['SPS', 'SCSPS'], true)` で正規化したうえで権限照合する。
- **書き込み系APIの追加チェック**：データを更新するAPI（`save_case.php` 等）は、読み取り用の `company_access_<会社>` に加えて `company_access_<会社>_edit` も検証すること。

#### 2.6.5 所属・選択中の会社との関係

本システムでは、ユーザーの会社アクセスは以下の3つの概念で管理する。

| 概念 | 保存場所 | 役割 |
|------|---------|------|
| 所属 | `employee_companies`（会社ごとに1行）と `employees.primary_company` | ユーザーが所属する会社（マスタ情報）。付与のデフォルト決定に使用。契約・職務ポジション・拠点は会社ごと（`02_01`） |
| 会社アクセス権限 | `employee_permissions` の `company_access_*` | 実際のアクセス可否（権限チェックの正）。API・画面はこちらを参照 |
| 選択中の会社 | セッション（`window.spsUser.contractCode` / `primary_company`） | 現在のセッションで選択中の会社。会社切替プルダウンの選択結果 |

**関係性**：
- 所属は「デフォルトでどの会社の権限を付与するか」を決める（新規従事者登録時、所属に応じて `company_access_*` を自動付与）
- 管理者は所属に関わらず `company_access_*` を追加付与・剥奪できる（例：SCSPS所属だがSPSの経理も担当する場合、`company_access_sps` を追加付与）
- API・画面の権限チェックは **常に `company_access_*` を正** とし、所属は参照しない
- セッション開始時、アクセス可能な会社（`company_access_*` を持つ会社）を列挙し、1つなら自動選択、2つ以上なら会社切替プルダウンを表示する（2.9節参照）

#### 2.6.6 エラーレスポンス

`company` パラメータを受け取るAPIは、以下のエラーレスポンスを返すこと。

| HTTPステータス | 条件 | レスポンス例 |
|---|---|---|
| 401 | 未ログイン | `{"success":false,"message":"未ログイン"}` |
| 400 | `company` パラメータ不正 | `{"success":false,"message":"companyはSPSまたはSCSPSで指定してください"}` |
| 403 | 会社アクセス権限なし | `{"success":false,"message":"この会社の案件へのアクセス権限がありません"}` |

画面側は403受信時、インラインで「アクセス権限がありません」と表示する（即時リダイレクトは行わない）。

#### 2.6.7 命名規則

- 形式：`company_access_<会社コード小文字>`
- 会社コード：`sps`、`scsps`
- 編集権限のサフィックス：`_edit`
- 将来の会社追加時は同規則でキーを追加（例：`company_access_xxx`、`company_access_xxx_edit`）

#### 2.6.8 監査

- `company_access_*` の付与・剥奪は **必ず監査ログに記録** する（`audit_logs`。`00_07_database.md` 5.6節）。
- 一括付与（新入社員・異動）時の整合性担保のため、所属マスタと `company_access_*` の突合チェックを月次で実施する。
- 編集権限（`_edit`）の付与は基本閲覧権限（`company_access_<会社>`）を伴うことを自動検証し、不整合があればログに警告を記録する。

### 2.7 事業者情報関連権限

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| company_info_view | 事業者情報を閲覧する | all | 1 |
| company_info_edit | 事業者情報を編集する | all | 2 |

### 2.8 労務関連権限

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| labor_view | 労務情報を閲覧する | all | 1 |
| labor_social_insurance_export | 社会保険CSVを出力する | all | 2 |
| labor_year_end_adjustment | 年末調整を行う | all | 2 |

### 2.9 ログイン時TOPページ振り分けルール
- ユーザーの「選択中の会社」と付与された会社アクセス権限に基づき、ログイン後のTOPページを決定する（2.6.5節参照）
- アクセス可能な会社が1つの場合は、その会社のTOPページを直接表示（会社切替なし）
- アクセス可能な会社が2つの場合は、会社切替プルダウン付きTOPページを表示
- アクセス可能な会社がない場合は、エラーページを表示

### 2.10 顧客関連権限

`02_data_definition/02_02_client_table.md`で定義する顧客マスタへのアクセス権限。
区別の基準は「SPS案件かSCSPS案件か」ではなく「情報の主体が組織か個人か」。

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| client_view | 顧客マスタ（組織情報）を閲覧する | all | 1 |
| client_edit | 顧客マスタ（組織情報）を編集する | all | 2 |
| client_view_cross | 顧客マスタの個人識別情報を閲覧する | all | 1 |
| client_edit_cross | 顧客マスタの個人識別情報を編集する | all | 2 |

- `client_view`はSPS/SCSPS共通。組織レコード（`members[].visibility: "open"`）までが対象
- `client_view_cross`・`client_edit_cross`は事業主および指定された権限者のみ。個人識別情報（`members[].visibility: "restricted"`）が対象
- 職責・職務ポジションは判定に使用しない

### 2.11 システム管理権限（全権キー）

| 権限ID | 説明（日本語） | 対象範囲 | レベル | 備考 |
|--------|----------------|----------|--------|------|
| supreme_access | マスター権限（全画面の権限チェックを通過する） | all | 3 | `emergency_override`（3節）とは独立したキー。詳細は 3.4 節参照 |

- 旧名は `master_access`（`00_03_login_session.md` 1.4節）。
- `supreme_access: true` を持つユーザーは、**全画面の権限チェックを通過したものとして扱う**。会社アクセス権限（`company_access_*`）を含む全権限を保有したものとみなす。
- 本キーは緊急用の `emergency_override`（3節）とは**完全に独立**している。`emergency_override` は `supreme_access` の代替にならず、`supreme_access` も `emergency_override` の効力（稼働状況スキップ・退職者詳細の閲覧編集）には影響しない。
- `supreme_access` は、通常の権限としては登録せず、権限マスタには載せない（2.14節）。付与の方法は 3.4 節と `00_03_login_session.md` 4.3節による。
- `supreme_access` による操作はアクセスログに記録する（3.2節の `emergency_override` と同様の扱い）。

### 2.12 人事メニュー関連権限

`employees/menu.html`（05_01）、`employees/admin_menu.html`（05_09）の各ボックスに対応する権限。権限マスタに登録済み。

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| employee_directory_view | 担当者一覧を閲覧する（連絡先を含む） | all | 1 |
| employee_audit_view | 従事者名簿を閲覧する | all | 1 |
| hr_evaluation_manage | 人事考課を管理する | all | 2 |
| hr_transfer_history_view | 人事異動履歴を閲覧する | all | 1 |
| employee_id_card_issue | 身分証を発行する | all | 2 |

- パスワード運用の権限（`password_pending_view`、`password_document_issue`、`password_reissue`）は、`00_03_login_session.md` 11.7節に定める。

### 2.13 変更履歴関連権限

`00_10_change_history.md` に定める。権限マスタに登録済み。

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| change_history_view | 変更履歴を閲覧する | all | 1 |
| change_history_view_sensitive | 機密性の高い項目（氏名・賞罰・権限）の変更履歴を閲覧する | all | 1 |
| change_history_review | 変更履歴を確認する（変更／訂正／却下を決める） | all | 2 |

- 自分が修正した記録は、自分で確認できない。`supreme_access` を持つ人は、単独で決められる（「単独許可」として記録）。

### 2.14 アカウント停止権限

| 権限ID | 説明（日本語） | 対象範囲 | レベル |
|--------|----------------|----------|--------|
| account_suspend | アカウントの停止・解除を申請・承認する（2名承認） | all | 2 |

- 旧名は「緊急ロック」。停止・解除は、`account_suspend` を持つ人2名の承認で実行する（申請者と承認者は別人）。`supreme_access` を持つ人は、単独で実行できる。仕様の詳細（申請、承認、却下、有効期限、記録、画面とAPI）は `00_03_login_session.md` 6節に定める。
- `supreme_access`、`emergency_override`、`admin_flag_assign` は、チェックボックスで付与する通常の権限としては扱わない（権限マスタには登録しない）。付与の方法は、`00_03_login_session.md` 4.3節および別途決める（未決）。

---

## 3. 緊急用フラグ（emergency_override。旧名 isAdmin）

### 3.1 概要
旧名は `isAdmin`（`00_03_login_session.md` 1.4節）。

管理者フラグは通常業務権限（権限マスタ `permissions`）とは**別枠の特別権限**。
業務上の役割に応じて変動する通常権限と異なり、システム管理者としての資格を表す。

| 区分 | 管理場所 | 用途 |
|------|---------|------|
| 通常業務権限 | `permissions`（定義）/ `employee_permissions`（付与状態） | 業務上の操作権限 |
| 管理者フラグ | `users` の `emergency_override` 列 | 緊急時・システム管理用 |

### 3.2 emergency_override: true の効力
- `employees` の稼働状況チェックをスキップしてログイン可能
- アカウント停止中・退職・解雇状態でもシステムに入れる
- アカウント停止中・退職者の従事者詳細を閲覧・編集可能（アクセスログに記録）
- 初期状態では、初期の全権保持者（オーナー）のみ `emergency_override: true`

※ emergency_override は会社アクセス権限（`company_access_*`）を代替しない。管理者であっても、所属会社以外にアクセスするには `company_access_<会社>` の付与が必要（2.6.5節参照）。

### 3.3 admin_flag_assign 権限
- `emergency_override` の付与・剥奪ができる権限
- `employees/edit.html` の専用セクションから操作（通常の権限チェックボックスとは分離）
- 初期状態では、初期の全権保持者（オーナー）のみ保有

### 3.4 supreme_access と emergency_override の分離
`supreme_access`（2.11節）と `emergency_override`（3.1〜3.3節）は、目的・効力・管理場所が異なる**独立したキー**である。混同してはならない。

| 項目 | `supreme_access`（全権キー） | `emergency_override`（緊急用フラグ） |
|------|--------------------------------|---------------------------|
| 目的 | 全画面の権限チェックの素通り（全権付与） | 緊急時・退職者対応のための特別ログイン |
| 効力 | 全画面の権限チェックを通過（`company_access_*` を含む） | 稼働状況チェックのスキップ、退職者・アカウント停止者詳細の閲覧編集 |
| 会社アクセス権限の代替 | **代替する**（全権限保有とみなす） | **代替しない**（3.2節の注記どおり） |
| 管理場所 | `employee_permissions` の行 | `users` の `emergency_override` 列 |
| 付与権限 | `permission_assign`（権限マスタ完成後はマスター権限として個別付与） | `admin_flag_assign` |

- `supreme_access` は `emergency_override` の代替にならない。`emergency_override: true` でも `supreme_access` がなければ全画面の権限チェックは素通りしない。
- `emergency_override: true` でも `supreme_access` がなければ、通常の権限チェック（`permissions`）に従う。
- 両キーを同時に保有することは可能だが、それぞれ独立して判定する。

---

## 4. 権限の追加・修正方法

### 4.1 新規権限追加の流れ

1. 管理者が「権限マスタ管理画面」を開く
2. 「新規権限追加」ボタンをクリック
3. 以下の項目を入力
   - 権限ID（半角英数、例: expense_approve_team）
   - 表示名（日本語）
   - 対象範囲（self/team/branch/all）
   - レベル（1/2/3）
   - 説明（任意）
4. 「追加」をクリック
5. 権限マスタに自動追加
6. 従事者入力画面のチェックボックス一覧に表示される

### 4.2 権限修正の流れ

- 表示名の変更は可能
- 権限IDは変更しない（履歴保存のため）
- 削除は「論理削除」（active: false）

### 4.3 権限マスタ（`permissions` テーブル）

| 列 | 内容 |
|---|---|
| permission_key | 権限キー（例：expense_approve_team）。主キー（旧称：id） |
| name | 表示名（日本語） |
| scope | 対象範囲（self/team/branch/all） |
| level | レベル（1/2/3） |
| active | 有効（論理削除は偽） |
| created_at、created_by | 作成日、作成者 |
| description | 説明文。権限の付与画面で、チェックボックスの横に表示する（必須） |
| sort_order | 付与画面での表示順 |

### 4.4 権限と画面の部品の対応（`permission_ui_targets`）

権限が、どのページのどの部品に効くかを持つ。

| 列 | 内容 |
|---|---|
| permission_key | 権限キー |
| page | ページ（例：accounting/journal.html） |
| element_type | page（ページ全体）/ box / button / link のどれか |
| element_id | 部品のID（HTMLの要素のID） |
| label | 表示名 |

- ページを開くときに、ログインしている人の権限と、この対応表を照らし合わせて、権限がなければ、部品を非表示にするか、無効にする。
- 部品の非表示は、見た目の制御に過ぎない。API 側でも、これまでどおり権限を必ず確認する（直接 API を呼ばれても実行できないようにする）。
- 新しい権限を追加するとき（4.1節）、この対応表にも行を足す。

---

## 5. 従事者マスタでの権限管理

### 5.1 チェックボックス形式（日本語表示）

```
【従事者権限設定】 SPS01-99999 テスト太郎

■ 経費関連
□ 自分の経費を閲覧する
□ 自分の経費を編集する
...（以下略）

■ 管理者設定（admin_flag_assign保有者のみ表示）
□ 管理者フラグ（emergency_override）
```

### 5.1.1 職務ポジションの初期権限
職務ポジションを選んだとき、そのポジションの初期権限（`position_default_permissions`）を、従事者の権限に入れられる（`01_07` 4節）。入れたあとの権限は、個人ごとに増減できる。権限の最終的な付与先は、個人のまま。

### 5.2 保存形式

`employee_permissions`（`sps_id`、`permission_key`、`granted`）に、権限キーごとに1行を持つ。

APIがセッションに返す形（JSON）は、キー＝権限ID、値＝boolean のオブジェクト：

```json
{
  "SPS_ID": "SPS01-99999",
  "氏名": "テスト 太郎",
  "権限": {
    "expense_view_self": true,
    "company_info_view": true,
    "permission_assign": true,
    "supreme_access": true
  }
}
```

- 空の権限の場合、`login.php` / `get_session.php` は `permissions` として `{}`（空オブジェクト）を返す。配列 `[]` は返さない（クライアント側のオブジェクト参照との型整合のため）。
- 全権付与用のキー `supreme_access` も、`employee_permissions` に持つ（2.11節参照）。

### 5.3 クライアント側共通判定関数（`common/js/session.js`）

各画面の権限チェックは、`common/js/session.js` が提供する共通関数 `window.hasPermission(permId)` を経由する。画面ごとに個別実装してはならない（判定漏れ防止のため）。

**仕様**：
- `window.hasPermission(permId)` は以下の順で判定する。
  1. `window.spsUser.permissions.supreme_access === true` なら常に `true` を返す（2.11節）。
  2. それ以外は `window.spsUser.permissions[permId] === true` を返す。
- `emergency_override` は本関数の判定に含めない（3節の緊急用であり、全画面権限の素通りとは目的が異なるため）。
- `permissions` が未定義・空オブジェクトの場合は `false` を返す（例外を投げない）。
- 本関数は `spsSessionReady` イベント発火後に利用可能となる。各画面は `window.addEventListener('spsSessionReady', ...)` 内で権限チェックを行うこと。

**利用例**：
```javascript
window.addEventListener('spsSessionReady', function () {
    if (window.hasPermission('permission_assign')) {
        document.getElementById('cardGrid').style.display = 'grid';
    } else {
        window.location.href = '/index.html';
    }
});
```

- 画面の権限チェックは、`permissions.<permId> === true` の直接参照ではなく、`window.hasPermission('<permId>')` を使う。

---

## 6. 運用開始後の考え方

- **完璧を目指さない**
- 運用しながら現場の声を聞く
- 必要に応じて権限を追加・修正
- 使わない権限は無効化（削除しない）

---

## 7. 今後の拡張

- 新しい機能ができたら権限IDを追加
- 既存の権限IDは削除せず無効化
- 履歴を残す

---

## 8. 職務別デフォルト権限セット

### 8.1 概要
- 新規従事者登録時の初期権限を、職務コードに応じて自動設定する
- デフォルト権限セットは、職務マスタ（`positions` テーブル）の `default_permissions` で管理する
- 設定後は個人単位で権限の追加・削除が可能

### 8.2 デフォルト権限セットの例（`positions` の内容を、JSONで示す）

```json
{
  "positions": [
    {
      "code": "P001",
      "name": "代表取締役",
      "category": "役員",
      "default_permissions": [
        "company_access_sps",
        "company_access_sps_edit",
        "company_access_scsps",
        "company_access_scsps_edit",
        "case_view_all",
        "case_edit_all",
        "accounting_view",
        "accounting_edit",
        "permission_assign",
        "company_info_view",
        "company_info_edit",
        "labor_view",
        "labor_social_insurance_export"
      ]
    },
    {
      "code": "P014",
      "name": "初級調査員",
      "category": "調査職",
      "default_permissions": [
        "case_view_self",
        "expense_view_self",
        "expense_edit_self"
      ]
    }
  ]
}
```

---

## 9. 兼任者の権限

- 複数の会社に所属する従事者は、それぞれの会社に対する権限を個別に付与する（2.6.5節参照）
- 例：法人では経理権限、個人事業では案件閲覧権限など
- ログイン時は従事者マスタの「所属」フィールドに基づいてデフォルトの付与対象を決定し、実アクセスは `company_access_*` の付与状態を正とする（2.6.5節参照）
- 所属と `company_access_*` の突合は月次監査で確認する（2.6.8節参照）

---

## 10. 従事者管理API仕様

従事者管理機能（`employees/index.html`, `employees/edit.html`）が利用するAPIの仕様を定義する。認証はすべてPHPセッション（`session_start()`）を用い、未ログイン時は401を返す。


### 10.1 従事者一覧取得API
- **エンドポイント**: `GET /employees/api/load_employee_list.php`
- **権限要件**: `profile_view_self` / `profile_view_branch` / `profile_view_all` / `permission_assign` のいずれか
- **クエリパラメータ**: なし
- **レスポンス**: `{"success": true, "employees": [{"SPS_ID": "SPS01-99999", "氏名": "テスト 太郎", "所属": [{"会社": "SPS", "契約CD": "C06", "職務ポジションCD": "P013", "管轄拠点": null, "サテライト": "S01"}], "稼働状況": "常勤", "メール": "test@example.com"}, ...]}`
- **動作**: セッションユーザーの権限に応じ、閲覧可能な従事者のみを抽出して返す。

### 10.2 従事者単体取得API
- **エンドポイント**: `GET /employees/api/load_employee.php`
- **権限要件**: `profile_view_self` / `profile_view_branch` / `profile_view_all` / `permission_assign` のいずれか
- **クエリパラメータ**: `sps_id`（必須）
- **レスポンス**: `{"success": true, "employee": {"SPS_ID": "SPS01-99999", "氏名": "テスト 太郎", "所属": ["SPS", "SCSPS"], "権限": {"company_access_sps": true, ...}}}`
- **エラー**: 401（未ログイン）、403（閲覧権限なし）、404（対象不在）

### 10.3 従事者保存API
- **エンドポイント**: `POST /employees/api/save_employee.php`
- **リクエストボディ**: `{"employee": { ... }}`（更新者情報はクライアントから受け取らず、セッションから取得）
- **権限要件**:
  - 新規登録：`profile_edit_all` または `permission_assign`
  - 更新：自分自身は `profile_edit_self`、他人は `profile_edit_branch`（同一拠点）または `profile_edit_all`
  - 権限フィールドの変更：`permission_assign` 必須
- **バリデーション**:
  - 存在する権限コード（権限マスタ `permissions` の `active` が真）のみ許可。
  - 会社アクセスペアリング（`_edit` があるなら基本権限も必須）。
  - 新規追加権限がある場合は `permission_assign` 必須。
- **変更履歴（`00_10_change_history.md`）**:
  - 権限・契約・氏名・所属会社の変更は、区分 B（承認待ち）。賞罰、昇進・降格は、出来事として登録する（職務CDを直接書き換えない）。他の項目の変更は、自動で履歴に記録される。
  - 更新と履歴の記録は、同じトランザクションで行う。
- **セッション破棄**:
  - 権限フィールドが変更された場合、または稼働状況が「退職」「契約終了」「契約解除」「解雇」「緊急ロック」（値の名称の変更は未決。`00_03` 1.4節）に変更された場合、対象ユーザーのPHPセッションを強制破棄する。
  - 強制破棄の実装は `active_sessions` からセッションIDを取得し、PHPセッションファイルを削除する。

---

## 11. データ保存場所一覧

| データ | 保存先（テーブル） | 内容 |
|---------|---------|------|
| 従事者マスタ | `employees`、`employee_companies` | 従事者情報、所属 |
| 権限の付与状態 | `employee_permissions` | 従事者ID、権限キー、付与の有無 |
| 権限マスタ | `permissions` | 権限定義一覧 |
| ログインユーザー | `users` | パスワード情報 + emergency_override |
| アクティブセッション | `active_sessions` | セッションID管理（強制破棄用） |

テーブルの定義は `00_07_database.md` 5.2節。

---

## 12. 改訂履歴

| 日付 | 版 | 担当 | 内容 | 理由・影響範囲 |
|------|----|------|------|--------------|
| 2026-03-11 | 1.0 | 全体管理者 | 初版作成 | |
| 2026-04-04 | 1.1 | マスタ管理担当（2代目） | 1.4節追加（権限付与フロー・移行フェーズ）、1.5節追加（権限変更の即時反映）、3節新設（emergency_override・admin_flag_assign）、5.1節に管理者設定セクション追記、10節にactive_sessions.json追加 | 打ち合わせ確定事項の反映：権限付与フロー・emergency_override・admin_flag_assign・即時反映 |
| 2026-08-06 | 1.2 | マスタ管理担当（4代目） | 10節のパスを修正（v2.6対応：employees.json・users.jsonをdata/employees/に変更） | フォルダ構成v2.6のファイル移動完了に伴う反映 |
| 2026-09-26 | 1.3 | 営業管理担当（初代） | 2.10節「顧客関連権限」を新設。client_view・client_edit・client_view_cross・client_edit_crossを追加 | 全体管理者2026-09-26指示（顧客マスタのアクセス制御方針確定）に基づく。`02_data_definition/02_02_client_table.md`で参照する権限キーを正式に権限マスタ側へ反映 |
| 2026-09-26 | 1.4 | 全体管理者（12代目） | 「2.10 顧客関連権限」と「2.9 ログイン時TOPページ振り分けルール」の記載順が逆転していたため、節番号の並び順どおりに入れ替え | 文書内の節番号の整合性確保。内容・権限定義への変更なし |
| 2026-10-08 | 1.5 | 全体管理者（12代目） | ファイル名規則を「フォルダ番号＋ファイル番号」形式に変更したことに伴い、参照名と保存先表記を機械的に置換（内容の変更なし） | ファイル名規則変更（2026-10-08）。影響範囲：他設計書への参照名・保存先表記のみ |
| 2026-10-23 | 1.6 | Deepseek | 2.6節「会社アクセス権限」を2.6.1〜2.6.8に拡張し、アクセス制御モデル（ゲート方式・AND条件）、読み取り／編集の関係（別個の権限・付与ペアリング）、サーバー側チェック義務、所属／現在契約CD／`company_access_*` の三概念関係、エラーレスポンス規約、命名規則、監査要件を明文化。あわせて1.3節にレベル階層の非連鎖注記、2.9節・3.2節・9節に2.6.5節への参照を追加 | `load_case_list.php` 実装（2026-10-23 案件管理担当）に伴い、API・画面で共通利用する会社アクセス制御のセマンティクスを仕様として確定。これまで2.6節はキー一覧のみで、ゲート方式・編集権限のペアリング・サーバー側チェック義務が未定義だったため、実装ごとに解釈がぶれるリスクを解消。影響範囲：`04_01_08_case_permission.md` 8節、`01_folder_structure.md` の `master/api/`、会社アクセス権限を扱う全API（`load_case_list.php`、`save_case.php`、`load_case.php` 等） |
| 2026-10-23 | 1.7 | Deepseek | 10節「従事者管理API仕様」を新設。`load_employee_list.php`、`load_employee.php`、`save_employee.php` のエンドポイント、権限要件、リクエスト/レスポンス、バリデーション、セッション破棄の仕様を定義。これに伴いデータ保存場所一覧を11節、改訂履歴を12節に繰り下げ | 従事者管理画面の実装に先立ち、API仕様を確定させるため。影響範囲：`master/api/` の従事者関連API、`employees/index.html`、`employees/edit.html` |
| 2026-10-25 | 1.8 | Deepseek | 2.4節の会計関連権限を、テーブルごとの個別ルールからログイン時付与の権限（`permissions`）による一括判定方式へ変更。あわせて2.6.2節のAND条件評価の記述を現行実装に合わせて明確化 | 会計システムは特殊扱いとし、テーブルごとの権限キーを廃止。ログイン時に付与される権限で一括制御する方針確定に伴う反映。影響範囲：`common/accounting/` 配下の全画面、会計関連API |
| 2026-10-25 | 1.9 | Deepseek | 2.11節「システム管理権限（全権キー）」を新設し、`supreme_access` を追加。3.4節「supreme_access と emergency_override の分離」を新設し、両キーの目的・効力・管理場所の差異を明記。5.2節に `permissions` の空時は `{}` を返す旨と `supreme_access` の格納位置を追記。5.3節「クライアント側共通判定関数（`common/js/session.js`）」を新設し、`window.hasPermission(permId)` の仕様（`supreme_access` 優先判定、`emergency_override` を含めない）を定義 | 全権付託ユーザーの権限チェック素通りを、緊急用 `emergency_override` と分離して実現するため。`emergency_override` の効力（稼働状況スキップ・退職者詳細の閲覧編集）は現行どおり維持。影響範囲：`common/js/session.js`、各画面の権限チェック、`employees.json` の `権限`、`login.php` / `get_session.php` の返却値 |
| 2026-10-26 | 2.0 | 全体管理者（13代目） | 10節の従事者管理APIのエンドポイントを `/master/api/…` から `/employees/api/…` に変更（10.1〜10.3）。10節冒頭に実装状況の注記を追加。5.2節の従事者マスタの保存場所を `/master/employees.json` から `/data/employees/employees.json` に訂正（11節の記載と一致させる） | 従事者系APIは人事担当の管理のため `employees/` 配下に集約する（`01_folder_structure.md` の置き場ルール）。10.3の `save_employee.php` は `master/api/` に実装済みで移設を要し、10.1・10.2は未実装。影響範囲：`03_02_master_management.md` 11節、`02_01_employee_table.md` 保存API仕様、`01_folder_structure.md`。影響しない：`05_02`〜`05_05`・`05_08`（もとから `/employees/api/`）、`session.js`（`get_session.php`・`logout.php` は `master/api/` のまま） |
| 2026-10-29 | 2.1 | 全体管理者（14代目） | ①権限キーの改名を反映（master_access→supreme_access、isAdmin→emergency_override、緊急ロック→account_suspend。旧名は移行期間中のみ併読）。②2.12節（人事メニュー関連権限）、2.13節（変更履歴関連権限）、2.14節（アカウント停止権限）を新設。③1.5節、10.3節に、権限・契約・氏名・所属会社の変更は承認後に反映する旨（00_10 区分B）を追記。④11節にDB移行後の保存先を追記。⑤例の人名・ID・メールをテスト用に差し替え、初期の全権保持者の記述を「オーナー」に言い換え（公開サイトに実名を出さないため） | 差し戻し指示2.5節の#1、変更履歴仕様（00_10 v1.0）の承認。影響範囲：`05_01`、`05_09`、`02_01`、`03_02`、`permissions.json`、`login.php`、`get_session.php`、`session.js`、`save_employee.php`（コード側の切り替えは、全仕様の承認後に一括） |
| 2026-10-29 | 2.2 | 全体管理者（14代目） | 画面名 employee_edit.html を employees/edit.html に統一（本文のみ。履歴の記載は変更しない） | 権限キー・画面名の改名（真柴さん決定）に伴う整合。内容の変更なし |
| 2026-10-29 | 3.0 | 全体管理者（14代目） | DB前提に書き直し。1.4節（移行フェーズ）を権限の付与の流れに。保存先を `employee_permissions`・`permissions`・`users`・`active_sessions` に（4.3節、5.2節、11節）。`isAdmin`・`master_access` の併読の記述、10節冒頭の実装状況の注記を削除。権限マスタ登録済みの記述を整理 | 仕様書をDB前提に統一（作業書 J-02）。コードの名称切り替えは作業書 B-11 |
| 2026-10-30 | 3.1 | 全体管理者（14代目） | 1.4節に説明文つきチェックボックスと、職務ポジションの初期権限の部品共通化を追記。2.6.5節の「現在契約CD」を「選択中の会社」に、所属は会社ごとに1行と明記。4.3節の列名を `permission_key` に、`description` を必須に、`sort_order` を追加。4.4節（`permission_ui_targets`）を新設。5.1.1節（初期権限）を新設 | 真柴さんの指示（権限と画面の部品の対応、説明文つきチェックボックス、職務ポジションの初期権限）。影響範囲：`01_07`、`schema_master.sql`、`employees/edit.html`、`login.php` |
| 2026-10-30 | - | 全体管理者（14代目） | 用語の統一（役職→職務ポジション、現在契約CD→選択中の会社）と、一覧の応答例を会社ごとの所属に変更 | `02_01` v2.1、`01_07` に合わせた更新 |

| 2026-10-31 | - | 全体管理者（14代目） | 152行：`04_01_08` の参照先を、新しい節番号（10節）に修正（内容の変更なし） |