:i/ロールは管理者とゲストのみによって、権限は不要になった。もういい。
「できないこと」を下位に強要する継承ルール。
できないこと以外を鍵として表示。利用者には「錠と鍵」に見えるように。
錠と鍵は同じ名前 † 
錠と鍵は同じ名前。でも鍵のほうは「できないこと」。同じ鍵が揃うと「できない」ということになる。
最上位の管理者は鍵をひとつも持たないので、なんでもできる。
システム上でこれからやろうとしていることによって錠が決まる。そのうちひとつにでも対応する鍵を持っている人は、その操作をできない。
ロール間で権限/継承。利用者間では継承不可 †
権限/継承は特定の属性について行なわれるので、いろいろな情報がある利用者ページ間でも問題なし。
ロールページでなければならない理由はない。
元になる上位ロール／上位利用者を変更するときに問題。これが利用者だと複数のロールを束ねたりできるので変更しづらくなる。→ 運用の問題
権限/継承には元が必要。それも1つだけ。複数だと多重継承になるので継承処理に問題。継承をロール間だけに限定して継承処理を簡素にする。→ 多重継承は難しくない
多重継承 †
継承元（上位）が複数ある場合は多重継承になる。属性/継承とは違って権限/継承は順不同。全ての継承元が持っている権限だけを継承することになる。
→ 属性/継承と同じでいい。
継承されるところ †
ページ/属性とは異なる権限/継承を特定属性に限るか／特定ページ名に限るのか／特定ページ型に限るのか。
この仕様はどのクラスが定義するものなのか。
→ 権限関係は独立した属性領域（ページ/裏だけでなくページ/属性も複数）に書くので、この属性領域を特別にするといい。ロールページの属性領域／利用者ページの属性領域。各ページの権限領域（ページ/属性領域のひとつ）。ここも実装はページで、ページ/型は「属性」。
→ 禁止されていないことは許可で、禁止事項を継承する仕組みにすれば、ページ/属性/継承と同じルールでいい。錠と鍵ではなく、錠と禁止事項になる。
継承した権限の与え方 †
→ :i/ロールの適用方法
利用者ページの属性領域「ロール」の項目に複数書く。
その権限領域の編集権限は…上位の管理者しか持っていないので書けない。
下位の管理者が誰かに権限を与えるのならそのための権限領域（その2）や弱い権限が必要。だけど、そこは権限判定で参照されない。
（権限判定では元々の管理者だけが変更可能な信頼できる領域しか使わないので、これは当然）
錠を書いて新しい権限を定義。鍵を書いて、それを与えない者を指定。
下位の管理者ロールを作っても、誰にも権限を与えることはできない。
解決策は…
参照する側を対応させない限り無理。その対応とは、下位の管理者のために作られた権限領域を元の属性領域と同じように扱うこと。信頼する領域を増やす。
元々の管理者が追加指定するとそこも権限領域扱いになる。
→ :/下位の管理者の作り方
却下 †
これは下位管理者用の権限領域を用意する案。特定の利用者にだけそれを継承させるために、対象となる利用者を継承対象になる位置に移動させなければならないけど、利用者を示すページを移動させるのはよくない。元々の継承関係も崩れてしまう。
この案は却下。