家庭は可視性を求めます。学校に必要なのは、説明できる一つの答えです。
保護者に見えるのは、自分が見守る人と、その一人ひとりについて誰かが許可したデータカテゴリだけです。権限そのものが検証済みの関係であり、読み取りのたびにデータベースで確認されます。誤って配られたロールではありません。
Lurno における保護者アクセスのしくみ
Lurno では、保護者のアクセスはロールからではなく、一つの組織内の二人のあいだの検証済みの関係から生まれます。管理者がそれを作成するか、成人の学習者が自分のデータについて許可を与えます。関係は保留状態に置かれ、検証する権限を持つ人がキューの中で、添付された監護に関する書類とともに審査するまでそのままです。検証の際に、どのデータカテゴリを持たせるかも決まります。以後の読み取りはすべて、その関係に照らしてデータベースで確認されます。検証済みであること、取り消されていないこと、期限切れでないこと、そしてそのデータが属するカテゴリが許可されていること。学業を許可された保護者には、概要、活動、コンピテンシー、修了証が見えます。スケジュールだけを許可された保護者に見えるのは時間割です。ほかのタブは、表示されて空になるのではなく、ページから存在しません。
- データカテゴリによるスコープ
- 人ごとではなく、関係ごと・データの種類ごとに与えられるアクセスです。Lurno は七つのカテゴリのレジストリを備えています — 学業、出欠、スケジュール、行動、医療、財務、コミュニケーション — そして保護者関係は、許可されたカテゴリごとに 1 行を保持します。確認は SQL 関数 `is_active_guardian_scoped(guardian, learner, organisation, category)` で行われ、学習者のデータを返すポリシーがこれを評価します。同じ子どもの二人の保護者が、異なるカテゴリを持つこともできます。別居後にはむしろ普通のことです。
この設計の要はキューです。申請は家族関係についての主張であり、数か月後に誰かが、誰がいつ、どの書類に基づいて承認し、何に絞り込んだのかを説明しなければなりません。その四つはすべて記録され、変更のたびにハッシュ連鎖の監査ログへ追記されます。保護者関係は検証された組織にも属するので、学校グループの中でも隣の学校に及ぶことはありません。
保護者に実際に見えるもの
見守る相手と、それぞれの進み具合
一人につき一枚のカード。関係の種類、検証された日付、許可された各カテゴリのチップ、修了件数が並びます。審査中の申請も、保留として表示されます。
- 職員ロールを持たない保護者のサイドバーは、項目が一つだけです。プログラムもライブラリもなく、迷い込む先がありません。
タブは許可から導かれる
概要、活動、コンピテンシー、修了証、時間割。どれが存在するかは、関係に付いたカテゴリから計算されます。最初の四つは学業から、最後の一つはスケジュールからです。許可されていないタブは無効化されるのではなく存在せず、確認はサーバー側でも再度行われるため、手書きのリクエストには何も返りません。
- すべて読み取り専用です。保護者は自分の関係を終了できますが、評点も、時間割も、受講登録も変更できません。
教師が見ているのと同じ数字
保護者向けの進捗は、職員と学習者が読むのと同じ認定済みのレポーティングビューを読み、サーバー側で一人の学習者に限定されます。その学習者の識別子は、信用されるのではなく検証されます。修了率をめぐって親と担任が言い争うとしても、少なくとも同じ数字について言い争っていることになります。レポーティングは組織ごとに有効化します。
レポーティング層成人は自分で、書面で決める
18 歳以上の学習者は一度確認に同意したうえで、親、パートナー、メンターに、自分のデータへの範囲を限ったアクセスを、任意で期限を付けて与えます。同意した文面はそのまま保存されるため、後から画面の文言を書き換えても、同意した内容が書き換わることはありません。招待は使い捨てのリンクで、7 日後に失効します。
保護者関係の始まりと、終わり
- 01
管理者が申請を起こす
学習者の記録から、または保護者関係のキューから起こします。すでにプラットフォームにいる人を選ぶか、まだいないメールアドレスを招待します。招待された保護者は、承諾してサインインした時点で紐づきます。
- 02
キューで待つ
保護者、学習者、関係の種類、監護に関する書類の添付有無、申請日時が並びます。作成と検証は別の権限なので、受付が申請を起こし、承認は教務課に残す運用ができます。
- 03
検証がカテゴリを決める
ウィザードは推奨される組み合わせをあらかじめ選択し、審査者が絞り込めるようにします。共同監護はサポートチケットではなく、ここで解決します。一方の親は学業とスケジュールを持って、もう一方は学業だけを持って終わります。
- 04
アクセスが始まり、条件付きのまま続く
セッションやトークンに焼き込まれるものはありません。読み取りのたびに関係が再評価されるため、取り消しは次のサインインではなく、次のクエリで効きます。
- 05
どちらの側からでも終了できる
保護者も学習者も、誰の許可も得ずに終了でき、管理者も終了できます。理由とともに記録され、相手方には通知されないことをダイアログがはっきり伝えます。
データカテゴリは七つ。画面があるのは、今のところ二つ。
許可できるのは、動く画面が裏にある二つだけです。親に何も見せないチェックボックスは、していないことをしたと管理者に思わせてしまいます。
| Capability | カテゴリが含むもの | 保護者に見えるもの | 現時点で許可できるか |
|---|---|---|---|
| 学業概要には受講登録と修了の状態が表示されます。アセスメントごとの評点の内訳は、まだポータルにはありません。 | 評点、アセスメント、その裏付けとなる課題 | 概要、活動、コンピテンシー、修了証 | Yes |
| スケジュール | 時間割と今後の予定 | 時間割 | Yes |
| 出欠 | 日々の出欠、遅刻、欠席 | — | No |
| 行動 | 指導記録、インシデント報告 | — | No |
| 医療 | 健康調査票、アレルギー、緊急連絡先 | — | No |
| 財務 | 請求書、支払履歴、費用 | — | No |
| コミュニケーション | 学校と保護者のあいだのメッセージ | — | No |
残る五つも実在する行で、データベース側の述語も実装済みです。追加はスキーマの変更ではなく、画面を作る作業になります。
機関が手放さないもの
どの判断にも名前が付く
誰がいつ、どの書類に基づいて検証し、何に絞り込んだのか — 誰かの受信箱ではなく、関係そのものに記録されます。
申請と承認は別の権限
カタログ上は二つの異なる権限で、どちらも構造上のブランチで付与でき、そのブランチの配下にだけ継承されます。
痕跡なしに変わるものはない
作成、検証、絞り込み、取り消し、期限切れは、いずれも決まったアクション名で監査ログに追記されます。行は追記されるだけで、更新されることはありません。
御社の呼び方で
メンターやケアギバーと呼ぶ組織は、用語を言い換えればポータルもそれに従います — 複数の言語（右から左を含む）で、WCAG 2.1 AA に準拠して。
記録上のマネージャーとスポンサー
企業側の関係も同じ形でモデル化されています。スポンサーの読み取りは、その人の学習履歴全体ではなく、自ら費用を負担した受講登録に従います。