園児全員に紐づくアカウントの停止に関する調査
この文書は改修前の調査記録です。調査後、2026-09-23に停止・再開を認証管理へ一本化して本番反映しました。現在の操作は 実装記録 を参照してください。以下にある旧版の編集画面・再開コードの説明は、調査当時の動作です。
申告と確認結果
当初の申告は「園児全員と紐づけしたアカウントを無効にしようとしても無効にならない」。操作を確認したところ、アカウントの状態変更ではなく、「所属家族」または「家族プロフィールの保護者」の紐づけ解除だった。
現在の実装は、家族プロフィールとの連携、明示的な園児閲覧許可、アカウントの有効状態を別々に管理する。家族との紐づけ解除によって、園児閲覧許可やログインを停止する処理はない。家族の解除が保存されても園児を閲覧できる動作を、架空の98園児を使って再現した。
| 操作 | 家族プロフィールとの連携 | 園児の閲覧許可 | ログイン |
|---|---|---|---|
| 「家族プロフィールの保護者」を「紐付けなし」へ変更 | 解除 | 98人分を保持 | 継続 |
| 上記に加えて「所属家族」を「未設定」へ変更 | 解除・所属も解除 | 98人分を保持 | 継続 |
| 「閲覧を許可する園児」のチェックをすべて解除 | 保持 | 0人・園児へのアクセス拒否 | 継続 |
| 「状態」を「停止中」へ変更 | 保持 | 紐づけは保持 | 停止・既存セッションも失効 |
アカウント全体の利用を止める操作は「編集」→「状態：停止中」→「更新する」。紐づけを98人分外す必要はない。
今回の条件では、保存した家族の解除が戻る不具合や、「停止中」の保存が失敗する不具合は再現していない。「家族の紐づけ解除＝閲覧・ログイン停止」と受け取られ得る点は、画面の説明を検討する余地がある。UIの変更仕様や新しい解除動作を確定したものではない。
検証範囲
- SSHによる読み取りで、稼働版が
15b13a9dd1eb6ae1b4d171186cb12c1dcc33326cであることを照合した。 - 同版の固定ソース
.local-dev/truenas-initial-ledger-20260922/sourceで、上記4シナリオと既存の保護者認証・プロフィール同期テストを実行し、24件成功した。 - 追加した再現テストは
test_parent_account_access_controls.py。インメモリDB、架空園児、架空のログインセッションだけを利用する。HTTPで保存した後、再表示のチェック状態、家族連携、園児アクセス、セッションの有効性を確認した。 - 作業中の開発版でも、追加した4シナリオはすべて成功した。
- 初回調査では対象の本番アカウントのDB状態は未取得。DBへの読み取り権限がなく、sudoには対話認証が必要だった。その後、ユーザーの管理者ログインを受けて本番画面から確認した結果は次節に記録する。DBへ直接接続しての検査は行っていない。
- 本番アカウントの設定変更、DB更新、アプリコード変更、配備は行っていない。
本番画面での確認（2026-09-23）
ユーザーの「本番でも確認しよう」という依頼と管理者ログイン後、アカウントID 4の編集画面・一覧・認証管理を読み取りで確認した。
| 確認項目 | 本番画面の現在値 |
|---|---|
| 家族プロフィールの保護者 | 紐付けなし |
| 所属家族 | 未設定 |
| アカウント状態 | 有効 |
| 園児の閲覧許可 | 表示対象100人のうち98人にチェックあり |
| 認証状態 | 利用中 |
| 有効セッション | 2件と表示 |
家族側の紐づけがない状態でも、園児98人の明示的な閲覧許可とアカウント・認証の有効状態が残っていることを、本番画面でも確認できた。「家族の解除が反映されずに戻っている」という表示ではない。
本番で「更新する」「資格情報を停止」などの保存操作は実行していない。実際の停止処理・保護者ログイン拒否の本番動作試験とは区別する。認証管理画面には「ログイン中の端末と通知登録も無効になります」と説明された「資格情報を停止」操作がある。
停止後に「有効」へ戻してもログインできない件
ユーザーが停止操作を行った後、「編集で『有効』に戻したがログインできない」と申告した。本番の編集画面は「有効」、認証管理は「停止中」、有効セッションは0件だった。ここまでの本番確認は読み取りのみ。
原因は台帳状態と認証資格情報の停止が別管理であること。update_parent_account は inactive の保存時に suspend_parent_authentication を実行するが、active の保存では資格情報の disabled_at を解除しない。再開には本人確認・再開コードによるパスワード設定が必要で、既存の認証仕様・運用手順にも記載されている。台帳状態の保存が失敗しているわけではないが、編集画面で「有効」だけに戻せば利用できると受け取られる点に説明上の問題がある。
現行の再開手順：
- 台帳の状態を「有効」に戻す（今回の本番では完了済み）。
- 認証管理の「初期設定・利用再開」で発行理由を入力し、再開コードのメールを送信する。
- 受信者がコード入力とパスワード設定を完了する。コードは発行から24時間・1回限り。
- 設定したパスワードでログインする。停止前のセッションは復活させない。
配備版の固定ソースで、「停止→有効へ変更だけでは旧パスワードでログイン拒否→再開コード交換→パスワード設定→ログイン成功」を追加検証し、調査用テスト5件が成功した。98人の閲覧リンク保持と旧セッションが失効したままであることも確認した。コードは架空データ・インメモリDBで発行し、外部へメールは送信していない。
本番でのコード送信は、登録先へのメール送信を伴うためユーザーの明示的な送信指示を待つ。アプリの動作変更や配備は行っていない。