【v2.0.0要件定義・設計】アカウント機能

[smctrl]

STJJ.AICのアカウント機能についてです。
当初は別のディスカで話し合われていましたが、大きな機能になりそうなためディスカを分けました。

[smctrl]

アカウント機能に必要な機能要件

• アカウント作成（メアド+ユーザー名+パスワードで作成可能）
  • STJJ.AIC側からメール飛ばす必要がある（gmailになるはず）
• アカウント管理（PMやアカウント削除用）
• PM
• アカウント削除
  • 後述のBANとは異なる、いわゆる「退会」
• メアド変更
• ユーザー名変更
• パスワードリセット（メアド登録の場合）
• アカウント一覧（管理者）
• BAN（管理者）
• 権限設定（管理者）

[smctrl]

アカウント作成時

アカウント作成時についてです。大まかなフローについてはこちらから転載↓

1. 新規ユーザーがメアドとユーザー名を入力する
2. STJJ.AICが新規ユーザーの入力したメアドに確認用URL付きの確認メール（）を送る
3. 新規ユーザーが確認メールに付いている確認用URLを踏む
4. STJJ.AICは確認用URLが踏まれたら新規ユーザーにパスワード登録画面を表示する
5. 新規ユーザーはパスワードを登録する
6. アカウント作成が正式に終了

[kerochan]

アカウント作成後はログイン画面に遷移させますか？それとも、自動でログインしログイン画面にアクセスする直前の画面に遷移させますか？

[smctrl]

利便性を考えて後者がいいと思います

[kerochan]

既に存在するユーザー名及びメールアドレスを使用した登録はできないようにしますか？

[smctrl]

はい。既存のユーザー名やメアドでの登録は不可にしたいです。

[kerochan]

・アカウント作成用確認メール送信画面

・アカウント作成用パスワード入力画面

[kerochan]

ログイン時

[kerochan]

ログイン画面への遷移方法は、ヘッダーに「ログイン」のようなタブを作ってそれをクリックすることで遷移、という形になりますかね。

[smctrl]

そのような形になると思います。

[smctrl]

ユーザー名については「アルファベット大文字小文字、数字、アンダーバー（いずれも半角）」のみ許可でよろしいでしょうか？

[smctrl]

また、ユーザー名については今後システムで使うかもしれないワードの場合は弾くようにしたいですが、いかがでしょうか？とりあえずは以下のURLにあるものを一括で禁止するのが手っ取り早いと思います。 https://github.com/worthmine/YAML-username-ban/blob/master/ban.yaml

[kerochan]

上記２つの案、共に賛成します。

[kerochan]

パスワード再登録時

[smctrl]

大まかな流れ

1. ログイン画面で「パスワードリセット」押下→パスワードリセット対象メアド入力画面（仮）に遷移
2. パスワードリセット対象メアド入力画面でメアド入力
3. パスワードリセット対象メアド入力画面で「送信」（仮）押下→STJJ.AICが対象メアド宛てにパスワードリセット用URLを書いたメールを送信
4. ユーザーが3のURLを踏む→パスワードリセット画面（仮）を表示
5. パスワードリセット画面で新しいパスワードを入力
6. パスワードリセット画面で「送信」（仮）押下→STJJ.AICがパスワードをリセットしたうえでログイン直前のURLに遷移
7. スナックバーで「パスワードのリセットが完了しました」（仮）を表示

こんな感じでどうでしょうか？

[kerochan]

大概のサービスで同様の流れなので、これで良いと思います。

[kerochan]

アカウント作成と同じ質問ですが、こちらもリセット後はログイン画面に遷移させますか？それとも、更新後のパスワードで自動でログインしログイン画面にアクセスする直前の画面に遷移させますか？

[smctrl]

一貫性と利便性を取って後者がいいと思います。

[kerochan]

・パスワードリセット対象メールアドレス入力画面

・パスワード再入力画面

[kerochan]

アカウント管理

[kerochan]

PMの方は、アカウント機能と分けるのであれば、上のレイアウトで示す画面とは別の画面を作成してそこで送るという感じになりますかね。

[kerochan]

[kerochan]

PMが無ければこんな感じで1画面で完結できますかね。

[kerochan]

デザインの変更

[kerochan]

とりあえずアクションをば

■	アカウント情報表示
(1)	アカウント表示画面の表示
・	「アカウント情報」ボタンをクリックする。
-	Aが表示される。

■	メールアドレス変更
(1)	メールアドレス変更画面の表示
・	「メールアドレス変更」ボタンをクリックする。
-	Bが表示される。
(2)	メールアドレス入力
・	「新しいメールアドレス」テキストボックスに新しいメールアドレスを入力する。
(3)	メールアドレス変更
・	「保存」ボタンをクリックする。
-	ユーザーの新しいメールアドレスに確認用URLを飛ばす。

■	ユーザー名変更
(1)	ユーザー名変更画面の表示
・	「ユーザー名変更」ボタンをクリックする。
-	Dが表示される。
(2)	ユーザー名入力
・	「ユーザー名」テキストボックスに新しいユーザー名を入力する。
(3)	ユーザー名変更
・	「保存」ボタンをクリックする。
-	ユーザーのメールアドレスに確認用URLを飛ばす。

■	パスワード変更
(1)	パスワード変更画面の表示
・	「パスワード変更」ボタンをクリックする。
-	Cが表示される。
(2)	パスワード入力
・	「古いパスワード」、「新しいパスワード」テキストボックスにそれぞれ現在のパスワード、新しいパスワード入力する。
(3)	パスワード保存
・	「保存」ボタンをクリックする。
-	ユーザーのメールアドレスに確認用URLを飛ばす。

■	アカウント削除
(1)	アカウント削除画面の表示
・	「アカウント削除」ボタンをクリックする。
-	Eが表示される。
(2)	パスワードの入力
・	「パスワード」テキストボックスに現在のパスワードを入力する。
(3)	アカウント削除
・	「削除」ボタンをクリックする。
-	アカウントが削除される。

[kerochan]

パスワード・メールアドレス・ユーザー名の変更

[kerochan]

大まかな流れ

1. 「アカウント管理画面」の「アカウント情報変更」を押下し、「アカウント情報変更画面」に遷移。
2. 「アカウント情報変更画面」の「ユーザー名変更」「メールアドレス変更」「パスワード変更」のいずれかのボタンを押下。
3. 押下したボタンに対応するテキストボックスとボタンを「アカウント情報変更画面」に表示する。
4. 変更前と変更後のユーザー名/メールアドレス/パスワードを入力。
5. 「変更」ボタンを押下し変更。変更をアカウントのメールアドレス(メアド変更時は変更後のメアド)に通知？

[kerochan]

• 画面レイアウト
  

[smctrl]

「変更」ボタンを押下し変更。変更をアカウントのメールアドレス(メアド変更時は変更後のメアド)に通知？

これについては、「変更」ボタンを押下した場合すぐに変更されるのではなく、変更後のメアドに確認URLをつけたメールを飛ばして、ユーザーに確認URLを踏んでもらい、その時点をもって正式に変更するという想定でいます（アカウント作成時と同じ感じです）。

[kerochan]

・アカウント情報変更確認画面のレイアウト図

[kerochan]

アカウント機能の設計が終了したら、PM機能やカードホルダー機能等別の機能の設計を行いますか？それとも、アカウント機能の実装を先にしてしまいますか？

[smctrl]

アカウント機能の実装を先にしたいです。PMやカードホルダーなどではアカウント機能を使うので、アカウント機能が既に出来てしまっていた方がプロトタイプなどの試行錯誤が捗るのではないかと思います。

[kerochan]

管理者用画面

[smctrl]

保存を押下する前に誰の権限/BANを編集したのかを確認できるダイアログ、もしくはリストみたいな項目が欲しいです。
おそらく、保存して即反映みたいなのではなく「これを編集するけど本当にいい？」のようにワンテンポ置けるようにダイアログがいいと思いますが、いかがでしょうか？

[kerochan]

なるほど。確かにそれは欲しいですね。
では、下図のような変更内容が表示されたアラートボックスを出すというのはどうでしょうか。

[smctrl]

上記のボックスを出すので賛成です

[smctrl]

管理者用画面で「最初」「前」「次」「最後」のボタンがありますが、変更保存前にこれを操作することは可能ですか？

[kerochan]

はい。可能である想定です。

[kerochan]

アカウントDB

[smctrl]

#4 (comment)
に暫定案を書きました。抜け漏れなどツッコミあったら修正しますのでご指摘お願いします。

[kerochan]

プログラム設計

[smctrl]

NodeからPythonへの乗り換えについて

PythonをFANDOMからの取り込みにのみ使うかそれ以外でも使っていくかという話があったと思いますが、httpsで接続するのに必要な443ポートは既にNodeが使ってしまっているため不可能とまではいきませんが混在は難しいと思っています。
プログラム設計上あまりごちゃごちゃと技術要素を増やすのもよろしくないですし、今以上にPythonも使うのであればサーバー側のNodeは撤廃すべきだと思いますが、いかがでしょうか？
サーバー側にTypeScriptを選んだ理由は「財団職員ならJS使ったことある人が多そうなのでJSに近い言語にしたい」でした。
しかしながら、twitterを見た感じPython使いも多いようなので、Pythonでもいい気がしています。
もしNodeを捨てるのであれば、早い方がいいです。
もし乗り換えを検討するのであれば、日曜までに今のSTJJ.AICのサーバー側をPythonに移植できないか試してみようと思います（DBはとりあえず現状と一番近いMongoDBで試してみます）。

[kerochan]

乗り換えは必要ないと考えています。FANDOMとのやり取りはPythonだけでなくJavaScript(TypeScript)でも書けるので、現在までに構築した部分をPythonで再構築する必要は無いと思います。