目次 † Edit
  1. 目次
  2. 関連
  3. 利用者周辺のタグ
  4. 利用者
    1. ログイン／認証
    2. アカウント/ユーザーグループ
      1. :i/ビルトインユーザー
    3. グループ／ロール
      1. :/アカウントにロールは要らない
      2. :i/利用者をグループでまとめる[?]
      3. :i/利用者のロールといえば
    4. アカウント/有効期限
      1. :i/ロールと権限の違い
      2. :i/下位ロールを作れるロール[?]
    5. 権限（鍵）
    6. 利用者情報を必要とする機能
    7. 利用者/グループ
      1. :i/検索履歴
      2. :Done/ユーザーページではなくワークスペース
    8. 未分類
      1. :i/ユーザーを個別化するには
      2. :i/管理アカウントは一般アカウント
    9. 見られ方
      1. :i/メンテナンス要員
  5. 思い付き
    1. :i/管理者は誰かという定義をページで
    1. 利用者名にはIDから得たハッシュ値を付ける
    2. 投稿時の自動署名はない
    3. 権限設定で、追加のみと既存部分を書き換えられるのを分ける。
      1. :i/情報はページに
      2. :i/ページのauthor属性
    4. 「あなたと似ている利用者は…」
  6. 実装
    1. :i/投稿時の自動署名はない
    1. 情報はページに
      1. :i/ページ/属性/作成者
      2. :i/追加のみと書き換えの権限を分ける
    2. 管理者定義
      1. :i/著作権に基づいた権限設定
    3. 高い依存性
      1. :i/自分のサイトへトラックバック送信
      2. :i/利用者ページの見られ方
    4. アカウント
      1. 定義の書き方
      2. :i/利用者名はニックネーム
      3. :i/利用者ページに書くこと
      4. :i/ロール別のビュー
      5. 有効期間
      6. 利用者の属性
      7. :i/利用者を何と結び付けるか
      8. :i/利用者をグループでまとめる[?]
      9. 非公開編集
      10. :i/オープン認証ではユーザーIDにサイトドメイン追加
      11. :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
  7. 設計
    1. :i/アンケートは自分のページに回答を書く
    2. :i/アカウント削除予約
    3. :i/おかえりなさいメール
    4. :i/Wiki構築には2つの側面がある
    1. 利用者/
 
 
利用者（ユーザー）についての情報。権限情報（鍵側）の集まりでしかない。
ユースケースクラスでの権限判定に使われるくらい。
実体は利用者を表すページ。それをラッピングしたのが利用者クラス。このページを作れば利用者登録になるし、SisterWikiなどで参照可能になったユーザーはログイン可能。→ X/User[?]

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

利用者周辺のタグ † Edit

 Array
 
利用者と権限を結び付ける際、引数の形式を考えるのが面倒なので、利用者をVisitorとしてページに渡す（コントロールクラスが）。で、ページから利用者を参照、利用者をたらい回し。
みんな最初はゲスト（お客様）。ゲストが認証（ログイン）を経て特定の利用者インスタンスと結び付く。

利用者 † Edit
  1. 目次
  2. 関連
  3. 利用者周辺のタグ
  4. 利用者
    1. ログイン／認証
    2. アカウント/ユーザーグループ
      1. :i/ビルトインユーザー
    3. グループ／ロール
      1. :/アカウントにロールは要らない
      2. :i/利用者をグループでまとめる[?]
      3. :i/利用者のロールといえば
    4. アカウント/有効期限
      1. :i/ロールと権限の違い
      2. :i/下位ロールを作れるロール[?]
    5. 権限（鍵）
    6. 利用者情報を必要とする機能
    7. 利用者/グループ
      1. :i/検索履歴
      2. :Done/ユーザーページではなくワークスペース
    8. 未分類
      1. :i/ユーザーを個別化するには
      2. :i/管理アカウントは一般アカウント
    9. 見られ方
      1. :i/メンテナンス要員
  5. 思い付き
    1. :i/管理者は誰かという定義をページで
    1. 利用者名にはIDから得たハッシュ値を付ける
    2. 投稿時の自動署名はない
    3. 権限設定で、追加のみと既存部分を書き換えられるのを分ける。
      1. :i/情報はページに
      2. :i/ページのauthor属性
    4. 「あなたと似ている利用者は…」
  6. 実装
    1. :i/投稿時の自動署名はない
    1. 情報はページに
      1. :i/ページ/属性/作成者
      2. :i/追加のみと書き換えの権限を分ける
    2. 管理者定義
      1. :i/著作権に基づいた権限設定
    3. 高い依存性
      1. :i/自分のサイトへトラックバック送信
      2. :i/利用者ページの見られ方
    4. アカウント
      1. 定義の書き方
      2. :i/利用者名はニックネーム
      3. :i/利用者ページに書くこと
      4. :i/ロール別のビュー
      5. 有効期間
      6. 利用者の属性
      7. :i/利用者を何と結び付けるか
      8. :i/利用者をグループでまとめる[?]
      9. 非公開編集
      10. :i/オープン認証ではユーザーIDにサイトドメイン追加
      11. :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
  7. 設計
    1. :i/アンケートは自分のページに回答を書く
    2. :i/アカウント削除予約
    3. :i/おかえりなさいメール
    4. :i/Wiki構築には2つの側面がある
    1. 利用者/

ログイン／認証 † Edit

アカウント/ユーザーグループ † Edit
  • 読む人
    ブックマークしてるリピーターの人、検索サイトから来た飛び入り参加の人など。書く人の相手。
  • 書く人
    コンテンツに詳しい人。サイトの原動力。
  • 構築する人
    WikiEngineに詳しい人。プラグインを利用して、Wikiをより活用しやすくする人。Wikiを改造する人。
  • 管理する人
    サイトの管理者。責任者。お金を出す人。何かあると怒られる人。管理者設定をする人。

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

グループ／ロール † Edit

:/アカウントにロールは要らない † Edit
利用者を上位ページでまとめればロールにあたる仕組みが不要。

:i/利用者をグループでまとめる[?] † Edit
ページ/属性/継承を使ってグループ内メンバー全員の権限を設定。

:i/利用者のロールといえば † Edit
（デフォルトで用意する）グループの候補に。
また、アカウントをまとめて扱いたいときにも利用。
読む人1と読む人2を用意して、権限は同じでも有効期限が違うとか。

アカウント/有効期限 † Edit
ログイン状態が続く時間。

:i/ロールと権限の違い † Edit
（デフォルトで用意する）グループの候補に。

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


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

権限（鍵） † Edit
…に時間を設定。

利用者情報を必要とする機能 † Edit
要するにカスタマイズ。

利用者/グループ † Edit
利用者権限をまとめて操作。
管理用ページ＞グループ名＞ユーザー名
管理用ページ＞ユーザー名　（グループに属さないユーザー）
…のどちらも有効に。
ユーザーグループ一覧のページ。あるいは全ユーザーの集約ページ。
ユーザーグループ名 - 権限 のリストに○。
名前読み書き
みんな○○

:i/検索履歴 † Edit

:Done/ユーザーページではなくワークスペース † Edit
  1. 利用者が自分用に使うページ群（下位ページ含めて）ということ
  2. これを作ることが参加／ユーザー登録になるということ

グループ名はリンク。グループを表すページへ。
…を明確に表現する呼び方は？
ユーザーグループのページ。
ユーザー名 - 権限 のリストに○。
空欄はグループの権限を継承するという意味。
名前読み書き
Aさん○

未分類 † Edit


対象ページはどう指定するか？
:t/？[?]

:i/ユーザーを個別化するには † Edit
アクティビティの収集など。個別化は自動的なカスタマイズにもなる。利便性向上に。

:i/管理アカウントは一般アカウント † Edit
多重ログイン。複数セッション。
Atlassian Confluenceはこうなっている。

見られ方 † Edit
見解を利用していろいろな人向けの利用者ページを作成できるように。
元は個人のページ、別見解でグループ内での役割を元にした自分のページも作る、というように。
どの見解からも共通する項目（万人共通の客観的な情報）は埋め込みリンクにしておけばいい。自分宛の連絡（コメント）は元のページか独立したページにすれば連絡を取りこぼしたりしない。

:i/メンテナンス要員 † Edit
詳しい人を招いたときのロール。
見解は見る側が選択するので、十分な数だけ作っておける。見る側の邪魔にならない。
最もよく使われている見解が新規利用者やゲストの見解になるのも適切。

思い付き † Edit

:i/管理者は誰かという定義をページで † Edit
最初の管理者はどう決めるか。管理者というより所有者（オーナー）を定義。

利用者名にはIDから得たハッシュ値を付ける † Edit
IDを公開してもいいならIDをそのまま付けてもいい。
で…
  • 同じニックネームがあってもいいように
  • いつでもニックネームを変えられるように

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


名前は自分で書くこと。

権限設定で、追加のみと既存部分を書き換えられるのを分ける。 † Edit
これらは包含関係。(編集>追加のみ)

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

:i/ページのauthor属性 † Edit
セマンティックなWikiのために。TwitterCardsをURIあたり1つしか付けられないのなら、最優秀功労者を決めないと。その方法は？

「あなたと似ている利用者は…」 † Edit

実装 † Edit
→共著も表現できるはず。

:i/投稿時の自動署名はない † Edit
投稿時のコメント欄（MediaWikiのような）があれば自動署名もあり。

情報はページに † Edit
利用者は独立したオブジェクト。でも関連する情報はページに記録。
自分のページにある情報がそのアカウントの情報。

:i/ページ/属性/作成者 † Edit
利用者IDはページに記録される。どのページのどの版にも1つ。

:i/追加のみと書き換えの権限を分ける † Edit
権限は雑多。重複がある。個別に考えなければならないし、判定は個別のコードで行なわないと。
エクスポート/インポートが容易になる。

管理者定義 † Edit

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


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

高い依存性 † Edit
ページや派閥と関係が深い。
利用者についてはこれらを考えてから。

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

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

アカウント † Edit
利用者ごとのアカウントを。
特定のページに記述することが利用者登録になるように。
さらにグループ名を表すページを使って、そのグループに属する利用者を登録できるように。
側面は見る側が選ぶというのは星。
多くの人か選んだ見解がゲスト向けのデフォルト見解になるというのも星。

定義の書き方 † Edit

 
文字列（利用者の属性名とその値に適合するRegExp）→アクセス権定義

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

:i/利用者名はニックネーム † Edit
利用者情報に「利用者名」または「ニックネーム」を設けて。Twitterでのdisplay_nameになるのはニックネーム？ID？IDは認証に使ったサイト名を含んでいる。
†:i/OAuth+ID+表示名
アクセス権定義は定義の対象になるページ（ページ/属性）に書く？
→重複していいので利用者自身が自由に設定。一部でもシステムが決めるのなら非公開に。本人が決めたものではないので。

:i/利用者ページに書くこと † Edit
設計のコンセプト。利用者ページのページ/裏のほうはシステムが書き込むものなので設定項目用かも。
そのページのアクセス権を管理者だけ編集可能にすれば、管理者がアクセス権定義をすることになる。

:i/ロール別のビュー † Edit
利用者を分けたときの一番の効果。モード変更なので、他のロールと切り替えて（例えば閲覧者と編集者）使用できないと。切り替えするのは利用者自身。
もしアクセス権定義ページを分けてサブディレクトリごとに用意できるようにするなら、ページがあるディレクトリとサブディレクトリについてのみ定義できるように。

有効期間 † Edit
有効であり続ける条件
  • 最終使用時刻（最後にアカウント情報が参照された時刻）からの時間が有効期限内
    アカウント情報を使わないような操作が続くと無効になる？→別にいい？
  • 同一端末を使っている
    同じIPアドレス。同じUAかどうかは不要。
    はてなでもやっている？
    これがあると不便？PCで編集しながら携帯での見え方をチェックすることができない。
    実装方法は…
    †:i/二重ログイン可能[?]
    †:i/パスワードを複数設定
    ログイン／ログアウトだけ？切り替えUIは不要？

無効になる条件

利用者の属性 † Edit


利用者に関する情報で文字列で表せるもの全て。
Googleさんだけ個別化して、特定のページを見せるなら属性「User-Agent」に/googlebot/があることを調べる。
→ログイン後のログインで。途中のログアウトは不要。

:i/利用者を何と結び付けるか † Edit
認証方法の考え方。既存の所有権と関連付けることが認証。

:i/利用者をグループでまとめる[?] † Edit
†:i/ロールと権限の違い
†:i/利用者のロールといえば
†:/ロールをページ化、利用者を下位ページ化

非公開編集 † Edit
アカウントを持っている人がゲストとして書き込むのもいい。
編集履歴に自分のアカウントが記録されないので、「隠れた編集」や「非公開編集」とも言える。
まとめて管理。まとめて権限設定。設定時に権限を要するがまとめておけば利用者ページごとの権限判定にはならない。判定対象はグループページと管理者の間だけ。
†:Done/属性継承時の権限判定は？

:i/オープン認証ではユーザーIDにサイトドメイン追加 † Edit
アカウントの区別に。IDをグローバルなものにする。
このグローバルなIDは何度アカウントを作り直しても再利用できなければならない。WikiでのIDは使い捨て（再利用しようとすると二世になる）。ここにずれは生じないか？
†:i/アカウント削除予約

:i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク † Edit
フレームワークを分けてはいけない例。基礎は使われて当然なので、フレームワーク/WikiEngine側とみなしていいかも。

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

:i/アンケートは自分のページに回答を書く † Edit
利用法。他人のための権限設定とページ名。大勢を対象にしてそれを行うには？権限設定とページ名はかみ合ってなくてはならない。

:i/アカウント削除予約 † Edit
ページの削除と同じ。ページが消えれば利用者情報も消える。

:i/おかえりなさいメール † Edit
「たまには来てよねメール」も。メールアドレスの登録が残っていることを警告しながら存在確認。

:i/Wiki構築には2つの側面がある † Edit
管理者向けの説明にはコンテンツに応じたシステムの使い方を。

利用者/ † Edit