利用者（ユーザー）についての情報。権限情報（鍵側）の集まりでしかない。
ユースケースクラスでの権限判定に使われるくらい。
実体は利用者を表すページ。それをラッピングしたのが利用者クラス。このページを作れば利用者登録になるし、SisterWikiなどで参照可能になったユーザーはログイン可能。→ X/User[?]

と、利用者の役に立つような機能のためのデータ集。
と、ページの作成者としての役目。
と、代表見解と投票に関わるもの。
→ :i/利用者クラスの高い依存性[?]

利用者と権限を結び付ける際、引数の形式を考えるのが面倒なので、利用者をVisitorとしてページに渡す（コントロールクラスが）。で、ページから利用者を参照、利用者をたらい回し。

みんな最初はゲスト（お客様）。ゲストが認証（ログイン）を経て特定の利用者インスタンスと結び付く。

  1. ログイン／認証
    1. :i/ビルトインユーザー
  2. グループ／ロール
    1. :/アカウントにロールは要らない
    2. :i/利用者をグループでまとめる[?]
    3. :i/利用者のロールといえば
    4. :i/ロールと権限の違い
    5. :/ロールを作れるロール[?]
  3. 権限（鍵）
  4. 利用者情報を必要とする機能
    1. :i/検索履歴
    2. :Done/ユーザーページではなくワークスペース
  5. 未分類
    1. :i/ユーザーを個別化するには
    2. :i/管理アカウントは一般アカウント
    3. :i/メンテナンス要員
    4. :i/管理者は誰かという定義をページで
    5. :i/情報はページに
    6. :i/ページのauthor属性
    7. :i/投稿時の自動署名はない
    8. :i/ページ/属性/作成者
    9. :i/追加のみと書き換えの権限を分ける
    10. :i/著作権に基づいた権限設定
    11. :i/自分のサイトへトラックバック送信
    12. :i/利用者ページの見られ方
    13. :i/利用者名はニックネーム
    14. :i/利用者ページに書くこと
    15. :i/ロール別のビュー
    16. :i/利用者を何と結び付けるか
    17. :i/利用者をグループでまとめる[?]
    18. :i/オープン認証ではユーザーIDにサイトドメイン追加
    19. :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
    20. :i/アンケートは自分のページに回答を書く
    21. :i/アカウント削除予約[?]
    22. :i/おかえりなさいメール
    23. :i/Wiki構築には2つの側面がある
  6. 利用者/

ログイン／認証 † Edit

:i/ビルトインユーザー † Edit

グループ／ロール † Edit

:/アカウントにロールは要らない † Edit

利用者を上位ページでまとめればロールにあたる仕組みが不要。

:i/利用者をグループでまとめる[?] † Edit

ページ/属性/継承を使ってグループ内メンバー全員の権限を設定。

:i/利用者のロールといえば † Edit

（デフォルトで用意する）グループの候補に。

:i/ロールと権限の違い † Edit

（デフォルトで用意する）グループの候補に。

:/ロールを作れるロール[?] † Edit

Wikiを構築するために。運用でロール作成。

権限（鍵） † Edit

利用者情報を必要とする機能 † Edit

要するにカスタマイズ。

:i/検索履歴 † Edit

:Done/ユーザーページではなくワークスペース † Edit

  1. 利用者が自分用に使うページ群（下位ページ含めて）ということ
  2. これを作ることが参加／ユーザー登録になるということ

…を明確に表現する呼び方は？

未分類 † Edit

:i/ユーザーを個別化するには † Edit

アクティビティの収集など。個別化は自動的なカスタマイズにもなる。利便性向上に。

:i/管理アカウントは一般アカウント † Edit

多重ログイン。複数セッション。
Atlassian Confluenceはこうなっている。

:i/メンテナンス要員 † Edit

詳しい人を招いたときのロール。

:i/管理者は誰かという定義をページで † Edit

最初の管理者はどう決めるか。管理者というより所有者（オーナー）を定義。

:i/情報はページに † Edit

ページはデータベース。利用者もページ/要素と同じ方法で情報を記録。ページ/要素は要素間連携と同じ方法で利用者情報を参照できることになる。

:i/ページのauthor属性 † Edit

セマンティックなWikiのために。TwitterCardsをURIあたり1つしか付けられないのなら、最優秀功労者を決めないと。その方法は？

→共著も表現できるはず。

:i/投稿時の自動署名はない † Edit

投稿時のコメント欄（MediaWikiのような）があれば自動署名もあり。

:i/ページ/属性/作成者 † Edit

利用者IDはページに記録される。どのページのどの版にも1つ。

:i/追加のみと書き換えの権限を分ける † Edit

権限は雑多。重複がある。個別に考えなければならないし、判定は個別のコードで行なわないと。

:i/著作権に基づいた権限設定 † Edit

権限のコンセプト。権限とはドキュメントに関する権利を守るためのもの。

:i/自分のサイトへトラックバック送信 † Edit

利用者情報に「トラックバック先」。他にもTwitterアカウントとかあってもいいかも。
Twitterとの連携でリプライの連鎖をwikiに取り込むTogetterクローンみたいな機能を使えるなら、発言はTwitter側でもwiki側でもいいことになる。

:i/利用者ページの見られ方 † Edit

見られ方=見解。利用者の見られ方（側面、インターフェイス）といえばロール。利用者は複数のロールに属せるし、ロールは周囲から期待される役目のこと。利用者ページの見られ方=見解として良さそう。
でも見解は他の見解を隠すためのもの。汎用性がない。→「他を隠す」というより「代表的なものがある」と考えると問題ない。

側面は見る側が選ぶというのは星。
多くの人か選んだ見解がゲスト向けのデフォルト見解になるというのも星。

見解ごとにそのロールで役立つような機能やフォーム（管理者なら連絡用フォームとか）を用意しておけば有意義。

:i/利用者名はニックネーム † Edit

利用者情報に「利用者名」または「ニックネーム」を設けて。Twitterでのdisplay_nameになるのはニックネーム？ID？IDは認証に使ったサイト名を含んでいる。
†:i/OAuth+ID+表示名

→重複していいので利用者自身が自由に設定。一部でもシステムが決めるのなら非公開に。本人が決めたものではないので。

:i/利用者ページに書くこと † Edit

設計のコンセプト。利用者ページのページ/裏のほうはシステムが書き込むものなので設定項目用かも。

:i/ロール別のビュー † Edit

利用者を分けたときの一番の効果。モード変更なので、他のロールと切り替えて（例えば閲覧者と編集者）使用できないと。切り替えするのは利用者自身。

実装方法は…
†:i/二重ログイン可能[?]
†:i/パスワードを複数設定
ログイン／ログアウトだけ？切り替えUIは不要？

→ログイン後のログインで。途中のログアウトは不要。

:i/利用者を何と結び付けるか † Edit

認証方法の考え方。既存の所有権と関連付けることが認証。

:i/利用者をグループでまとめる[?] † Edit

†:i/ロールと権限の違い
†:i/利用者のロールといえば
†:/ロールをページ化、利用者を下位ページ化

まとめて管理。まとめて権限設定。設定時に権限を要するがまとめておけば利用者ページごとの権限判定にはならない。判定対象はグループページと管理者の間だけ。
†:Done/属性継承時の権限判定は？

:i/オープン認証ではユーザーIDにサイトドメイン追加 † Edit

アカウントの区別に。IDをグローバルなものにする。
このグローバルなIDは何度アカウントを作り直しても再利用できなければならない。WikiでのIDは使い捨て（再利用しようとすると二世になる）。ここにずれは生じないか？

†:i/アカウント削除予約[?]

:i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク † Edit

フレームワークを分けてはいけない例。基礎は使われて当然なので、フレームワーク/WikiEngine側とみなしていいかも。

:i/アンケートは自分のページに回答を書く † Edit

利用法。他人のための権限設定とページ名。大勢を対象にしてそれを行うには？権限設定とページ名はかみ合ってなくてはならない。

:i/アカウント削除予約[?] † Edit

ページの削除と同じ。ページが消えれば利用者情報も消える。

:i/おかえりなさいメール † Edit

「たまには来てよねメール」も。メールアドレスの登録が残っていることを警告しながら存在確認。

:i/Wiki構築には2つの側面がある † Edit

管理者向けの説明にはコンテンツに応じたシステムの使い方を。

利用者/ † Edit