利用者（ユーザー）についての情報。権限情報（鍵側）の集まりでしかない。
ユースケースクラスでの権限判定に使われるくらい。
実体は利用者を表すページ。それをラッピングしたのが利用者クラス。このページを作れば利用者登録になるし、SisterWikiなどで参照可能になったユーザーはログイン可能。→ X/User[?]
利用者（ユーザー）についての情報。データ。
ページの編集などを許可・制限するときに参照するデータの集合。
と、利用者の役に立つような機能のためのデータ集。
と、ページの作成者としての役目。
と、代表見解と投票に関わるもの。
→ :i/利用者クラスの高い依存性[?]
みんな最初はゲスト（お客様）。ゲストが認証（ログイン）を経て特定の利用者インスタンスと結び付く。
- -
- ログイン／認証
- グループ／ロール
- 権限（鍵）
- 利用者情報を必要とする機能
- 何と結び付けるか
- 未分類
- 要求権限の設定は複数
- いろいろな権限
- :i/ユーザーを個別化するには
- :i/管理アカウントは一般アカウント
- :i/メンテナンス要員
- :i/管理者は誰かという定義をページで
- Tikiの場合
- :i/情報はページに
- :i/ページのauthor属性
- :i/投稿時の自動署名はない
- :i/ページ/属性/作成者
- :i/追加のみと書き換えの権限を分ける
- :i/著作権に基づいた権限設定
- :i/自分のサイトへトラックバック送信
- :i/利用者ページの見られ方
- :i/利用者名はニックネーム
- :i/利用者ページに書くこと
- :i/ロール別のビュー
- :i/利用者を何と結び付けるか
- :i/利用者をグループでまとめる[?]
- :i/オープン認証ではユーザーIDにサイトドメイン追加
- 情報はページに
- 管理者定義
- 高い依存性
- アカウント
- 利用者/
ログイン／認証 † 
:i/ビルトインユーザー †
グループ／ロール †
:/アカウントにロールは要らない †
利用者を上位ページでまとめればロールにあたる仕組みが不要。
:i/利用者をグループでまとめる[?] †
ページ/属性/継承を使ってグループ内メンバー全員の権限を設定。
:i/利用者のロールといえば †
（デフォルトで用意する）グループの候補に。
:i/ロールと権限の違い †
（デフォルトで用意する）グループの候補に。
:i/下位ロールを作れるロール[?] †
Wikiを構築するために。運用でロール作成。
権限（鍵） †
利用者情報を必要とする機能 †
要するにカスタマイズ。
:i/検索履歴 †
:Done/ユーザーページではなくワークスペース †
何と結び付けるか †
システム側の利用者データをシステム外のどんな情報と結び付けるか。
- メールアドレス
- OpenID
- Twitterアカウント
OAuth - ドメイン
組織を1つのアカウントに。 - なぞなぞの正解者
例えばはてなのような。でもID指定は必要。IDを利用者ページアクセスにすれば手間が省けてはてな式に近くなる。
パスワードでなくリマインダーのようなもの。
ID指定（または利用者ページにアクセス）→問い、答え入力→認証 - 複数のOpenID、OAuth
複数登録、全てで認証されないといけない。順序は登録されている順序、認証処理によってどこを登録しているかばれるのは構わない。なぞなぞなどを組み合わせてもいい。
…を明確に表現する呼び方は？
未分類 †
要求権限の設定は複数 †
ページの編集権限などは
(条件1 AND 条件2) OR (管理者向け条件)
のように複数条件をOR結合。
いろいろな権限 †
:i/ユーザーを個別化するには †
アクティビティの収集など。個別化は自動的なカスタマイズにもなる。利便性向上に。
権限は基本は3つで十分。
:i/管理アカウントは一般アカウント †
多重ログイン。複数セッション。
Atlassian Confluenceはこうなっている。
ページの種類との組み合わせで…
- システムの一部になってるページの…読み、書き1、書き2
:i/メンテナンス要員 †
詳しい人を招いたときのロール。
これらを特定ユーザー、特定ユーザーグループに与える。
:i/管理者は誰かという定義をページで †
最初の管理者はどう決めるか。管理者というより所有者（オーナー）を定義。
※ページの種類というものは無くてあるページとその下位ページに読み書き条件を付けるということ。ページグループ×ユーザーグループ×3種の権限
Tikiの場合 †
Tikiの権限設定がすごいことになっているので参考に。
ほとんどどうでもいい項目。
:i/情報はページに †
ページはデータベース。利用者もページ/要素と同じ方法で情報を記録。ページ/要素は要素間連携と同じ方法で利用者情報を参照できることになる。
-閲覧
Can view page/pages (tiki_p_view)
-テンプレート使用
Can use the page as a tracker template (tiki_p_use_as_template)
-画像のアップロード
Can upload pictures to wiki pages (tiki_p_upload_picture)
-リバート
Can rollback pages (tiki_p_rollback)
-閲覧/バックリンク
View page backlinks (tiki_p_view_backlink)
-閲覧/履歴
Can view wiki history (tiki_p_wiki_view_history)
-閲覧/WikiTextソース
Can view source of wiki pages (tiki_p_wiki_view_source)
-閲覧/類似ページ
Can view similar wiki pages (tiki_p_wiki_view_similar)
-閲覧/ページの参照？をモジュールやフィードで
Can view in module and feed the wiki pages reference (tiki_p_wiki_view_ref)
-ページ名の変更
Can rename pages (tiki_p_rename)
-削除
Can remove (tiki_p_remove)
-凍結
Can lock pages (tiki_p_lock)
Can edit dynamic variables (tiki_p_edit_dynvar)
Can edit pages (tiki_p_edit)
Can assign perms to wiki pages (tiki_p_assign_perm_wiki_page)
Can save as minor edit (tiki_p_minor)
-閲覧/会話
Can view contributions to a page (tiki_p_page_contribution_view)
-閲覧/許可されていない機能
Can view unapproved plugin details (tiki_p_plugin_viewdetail)
-許可されていない機能の実行
Can execute unapproved plugin (tiki_p_plugin_preview)
-許可されている機能の実行
Can approve plugin execution (tiki_p_plugin_approve)
-Wikiの管理
Can admin the wiki (tiki_p_admin_wiki)
:i/ページのauthor属性 †
セマンティックなWikiのために。TwitterCardsをURIあたり1つしか付けられないのなら、最優秀功労者を決めないと。その方法は？
- -----
→共著も表現できるはず。
:i/投稿時の自動署名はない †
投稿時のコメント欄（MediaWikiのような）があれば自動署名もあり。
Can admin comments (tiki_p_admin_comments)
-コメント投稿
Can post new comments (tiki_p_post_comments)
-コメント削除
Can delete comments (tiki_p_remove_comments)
Can edit all comments (tiki_p_edit_comments)
Can vote comments (tiki_p_vote_comments)
-閲覧/コメント
Can read comments (tiki_p_read_comments)
:i/ページ/属性/作成者 †
利用者IDはページに記録される。どのページのどの版にも1つ。
:i/追加のみと書き換えの権限を分ける †
権限は雑多。重複がある。個別に考えなければならないし、判定は個別のコードで行なわないと。
:i/著作権に基づいた権限設定 †
権限のコンセプト。権限とはドキュメントに関する権利を守るためのもの。
-DB 任意のクエリー実行？
Can execute arbitrary queries on a given DSN (tiki_p_dsn_query)
:i/自分のサイトへトラックバック送信 †
利用者情報に「トラックバック先」。他にもTwitterアカウントとかあってもいいかも。
Twitterとの連携でリプライの連鎖をwikiに取り込むTogetterクローンみたいな機能を使えるなら、発言はTwitter側でもwiki側でもいいことになる。
:i/利用者ページの見られ方 †
見られ方=見解。利用者の見られ方（側面、インターフェイス）といえばロール。利用者は複数のロールに属せるし、ロールは周囲から期待される役目のこと。利用者ページの見られ方=見解として良さそう。
でも見解は他の見解を隠すためのもの。
Can assign perms to file gallery (tiki_p_assign_perm_file_gallery)
-Directory Batch Load使用
Can use Directory Batch Load (tiki_p_batch_upload_file_dir)
-ダウンロード
Can download files (tiki_p_download_files)
Can edit a gallery file (tiki_p_edit_gallery_file)
-ZIPアップロード
Can upload zip files with files (tiki_p_batch_upload_files)
-添付ファイル一覧
Can list file galleries (tiki_p_list_file_galleries)
Can admin file galleries (tiki_p_admin_file_galleries)
-閲覧/添付ファイル一覧？
Can view file galleries explorer (tiki_p_view_fgal_explorer)
-添付ファイルのパス閲覧？
Can view file galleries path (tiki_p_view_fgal_path)
-閲覧/添付ファイル
Can view file galleries (tiki_p_view_file_gallery)
-アップロード
Can upload files (tiki_p_upload_files)
-添付ファイルのギャラリー作成
Can create file galleries (tiki_p_create_file_galleries)
側面は見る側が選ぶというのは星。
多くの人か選んだ見解がゲスト向けのデフォルト見解になるというのも星。
見解ごとにそのロールで役立つような機能やフォーム（管理者なら連絡用フォームとか）を用意しておけば有意義。
:i/利用者名はニックネーム †
利用者情報に「利用者名」または「ニックネーム」を設けて。Twitterでのdisplay_nameになるのはニックネーム？ID？IDは認証に使ったサイト名を含んでいる。
†:i/OAuth+ID+表示名
Can join or leave the group (tiki_p_group_join)
-グループにメンバー追加
Can add group members (tiki_p_group_add_member)
-閲覧/グループ
Can view the group (tiki_p_group_view)
-グループからメンバー削除
Can remove group members (tiki_p_group_remove_member)
-閲覧/グループメンバー
Can view the group members (tiki_p_group_view_members)
→重複していいので利用者自身が自由に設定。一部でもシステムが決めるのなら非公開に。本人が決めたものではないので。
:i/利用者ページに書くこと †
設計のコンセプト。利用者ページのページ/裏のほうはシステムが書き込むものなので設定項目用かも。
:i/ロール別のビュー †
利用者を分けたときの一番の効果。モード変更なので、他のロールと切り替えて（例えば閲覧者と編集者）使用できないと。切り替えするのは利用者自身。
User can administer modules (tiki_p_admin_modules)
ユーザがモジュールを管理する
Can admin mail-in accounts (tiki_p_admin_mailin)
Can delete his/her own account (tiki_p_delete_account)
自分のアカウントを削除できる
自分のアカウントは自分のものなので当たり前。アカウント作成者が異なっても削除できるということ？
Can admin integrator repositories and rules (tiki_p_admin_integrator)
レポジトリとルールの統合を管理？
Administrator, can admin banners (tiki_p_admin_banners)
Can view integrated repositories (tiki_p_view_integrator)
統合されたレポジトリを見ることができる。
Can change the categories of the object (tiki_p_modify_object_categories)
オブジェクトのカテゴリー変更ができる。
実装方法は…
†:i/二重ログイン可能[?]
†:i/パスワードを複数設定
ログイン／ログアウトだけ？切り替えUIは不要？
Can view site stats (tiki_p_view_stats)
サイトの統計情報を見ることができる。
Can view referrer stats (tiki_p_view_referer_stats)
リファラー情報を見ることができる。
→ログイン後のログインで。途中のログアウトは不要。
:i/利用者を何と結び付けるか †
認証方法の考え方。既存の所有権と関連付けることが認証。
Can ban users or ips (tiki_p_admin_banning)
Can admin the dynamic content system (tiki_p_admin_dynamic)
動的コンテンツの管理
Trust all user inputs including plugins (no security checks) (tiki_p_trust_input)
権限の話？
Can use the importer (tiki_p_admin_importer)
インポーター？を使える
Can view action log for users of his own groups (tiki_p_view_actionlog_owngroups)
自身が所属するグループのアクションログ（アクティビティログ？）を見ることができる。
Can use HTML in pages (tiki_p_use_HTML)
HTMLを使える。エスケープされない。
Can send a link to a friend (tiki_p_tell_a_friend)
フレンドにリンクを送ることができる。エスケープされない。
Can subscribe to groups (tiki_p_subscribe_groups)
グループの購読ができる。フィードを受け取れる？アクティビティログは自分のグループで、他のグループについてはこっち？
Can search (tiki_p_search)
検索を使える。
Can share a page (email, twitter, facebook, message, forums) (tiki_p_share)
ページの共有機能が使える。
パーマリンクを参照できるということ？それともクリックだけでいいようなI/Fが使えるだけ？
Can report a link to the webmaster (tiki_p_site_report)
Can view action log (tiki_p_view_actionlog)
アクションログ？（自分の？）を見ることができる。
Can view site templates (tiki_p_view_templates)
サイトテンプレートを見ることができる。（使うことは？）
Can edit translations and create new languages (tiki_p_edit_languages)
翻訳を編集したり新しい言語の翻訳を追加できる
Administrator, can manage users groups and permissions, and all features (tiki_p_admin)
管理者が（？）ユーザーグループやその権限や全機能を管理できる。
当たり前。
Can edit menu option (tiki_p_edit_menu_option)
メニューオプション（メニューに載せる項目？）を編集できる。
Can admin cookies (tiki_p_edit_cookies)
Cookieを管理（システムがやることでは）
Can clean cache (tiki_p_clean_cache)
キャッシュの消去（システムがやることでは）
Can remove association between two pages in a translation set (tiki_p_detach_translation)
2言語間の関連付けを削除できる（翻訳がどう使われるかの制御？）
Can create new css suffixed with -user (tiki_p_create_css)
-user付きのCSSを作れる。独自クラスを作れる？適用先はどう設定？
Can edit site templates (tiki_p_edit_templates)
Can edit menu (tiki_p_edit_menu)
メニューの編集（重複？）
Can access site when closed (tiki_p_access_closed_site)
クローズドサイトにアクセス可能
Can invite user to my groups (tiki_p_invite_to_my_groups)
Can admin mail notifications (tiki_p_admin_notifications)
Can admin users (tiki_p_admin_users)
Can edit object permissions (tiki_p_admin_objects)
オブジェクト（ページや添付ファイル？）のアクセス制限状況を変更
Can admin external feeds (tiki_p_admin_rssmodules)
外部フィード（RSSとか？）を管理
Can admin toolbars (tiki_p_admin_toolbars)
:i/利用者をグループでまとめる[?] †
†:i/ロールと権限の違い
†:i/利用者のロールといえば
†:/ロールをページ化、利用者を下位ページ化
まとめて管理。まとめて権限設定。設定時に権限を要するがまとめておけば利用者ページごとの権限判定にはならない。判定対象はグループページと管理者の間だけ。
†:Done/属性継承時の権限判定は？
:i/オープン認証ではユーザーIDにサイトドメイン追加 †
アカウントの区別に。IDをグローバルなものにする。
このグローバルなIDは何度アカウントを作り直しても再利用できなければならない。WikiでのIDは使い捨て（再利用しようとすると二世になる）。ここにずれは生じないか？
View page backlinks (tiki_p_view_backlink)
Can view wiki history (tiki_p_wiki_view_history)
Can view similar wiki pages (tiki_p_wiki_view_similar)
Can view source of wiki pages (tiki_p_wiki_view_source)
Can view in module and feed the wiki pages reference (tiki_p_wiki_view_ref)
Can remove (tiki_p_remove)
Can lock pages (tiki_p_lock)
Can save as minor edit (tiki_p_minor)
Can admin the wiki (tiki_p_admin_wiki)
Can edit dynamic variables (tiki_p_edit_dynvar)
Can edit pages (tiki_p_edit)
Can assign perms to wiki pages (tiki_p_assign_perm_wiki_page)
Can view contributions to a page (tiki_p_page_contribution_view)
Can approve plugin execution (tiki_p_plugin_approve)
Can upload pictures to wiki pages (tiki_p_upload_picture)
Can use the page as a tracker template (tiki_p_use_as_template)
Can rollback pages (tiki_p_rollback)
Can rename pages (tiki_p_rename)
Can execute unapproved plugin (tiki_p_plugin_preview)
Can view unapproved plugin details (tiki_p_plugin_viewdetail)
Can view page/pages (tiki_p_view)
情報はページに †
利用者は独立したオブジェクト。でも関連する情報はページに記録。
自分のページにある情報がそのアカウントの情報。
†:i/アカウント削除予約
エクスポート/インポートが容易になる。
管理者定義 †
:i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク †
フレームワークを分けてはいけない例。基礎は使われて当然なので、フレームワーク/WikiEngine側とみなしていいかも。
キーワード:OpenID
高い依存性 †
ページや派閥と関係が深い。
利用者についてはこれらを考えてから。
:i/アンケートは自分のページに回答を書く †
利用法。他人のための権限設定とページ名。大勢を対象にしてそれを行うには？権限設定とページ名はかみ合ってなくてはならない。
:i/アカウント削除予約 †
ページの削除と同じ。ページが消えれば利用者情報も消える。
:i/おかえりなさいメール †
「たまには来てよねメール」も。メールアドレスの登録が残っていることを警告しながら存在確認。
アカウント †
利用者ごとのアカウントを。
特定のページに記述することが利用者登録になるように。
さらにグループ名を表すページを使って、そのグループに属する利用者を登録できるように。
:i/Wiki構築には2つの側面がある †
管理者向けの説明にはコンテンツに応じたシステムの使い方を。
利用者/ †
定義の書き方 †
文字列（利用者の属性名とその値に適合するRegExp）→アクセス権定義
アクセス権定義は定義の対象になるページ（ページ/属性）に書く？
そのページのアクセス権を管理者だけ編集可能にすれば、管理者がアクセス権定義をすることになる。
もしアクセス権定義ページを分けてサブディレクトリごとに用意できるようにするなら、ページがあるディレクトリとサブディレクトリについてのみ定義できるように。
有効期間 †
有効であり続ける条件
- 最終使用時刻（最後にアカウント情報が参照された時刻）からの時間が有効期限内
アカウント情報を使わないような操作が続くと無効になる？→別にいい？ - 同一端末を使っている
同じIPアドレス。同じUAかどうかは不要。
はてなでもやっている？
これがあると不便？PCで編集しながら携帯での見え方をチェックすることができない。
無効になる条件
利用者の属性 †
利用者に関する情報で文字列で表せるもの全て。
Googleさんだけ個別化して、特定のページを見せるなら属性「User-Agent」に/googlebot/があることを調べる。
非公開編集 †
アカウントを持っている人がゲストとして書き込むのもいい。
編集履歴に自分のアカウントが記録されないので、「隠れた編集」や「非公開編集」とも言える。
†
利用者と権限を結び付ける際、引数の形式を考えるのが面倒なので、利用者をVisitorとしてページに渡す（コントロールクラスが）。
で、ページから利用者を参照、利用者をたらい回し。
リクエスト、ログ読み（未読） †
人気ページは「充実させてほしい」というリクエストの表れ。
編集者が自分が編集するペースで（というか、前回アクセスから今までの期間で）人気のあるページを調べられれば、
「次に編集すべきページ」「期待されているページ」というものが分かる。
掲示板での「ログ読み」「未読」をWikiでやるならば、前回アクセス以降の差分（全ページ分）閲覧と、前回アクセス以降の人気ページを知ることになるのでは。