---

曲作りが完全に暗澹に乗り上げてるので、とりあえず仕事としてのプログラムは早いとこ作ったほうがいいと思うので、作り始めることにしましょう。はやく完成して悪いことはないですし。
半分自分の脳内整理のための記事なんで、読みづらくても許して下さいね。まあ誰も読まないと思うけど(笑)


今回も例によってあんまりちゃんと設計せずに作り始めようかなあと思う昨今ですけど、昨日述べた通り、僕が思い描いてるシステムは今のとこビジネスロジックが不明瞭な部分がありますので、今回はそこを詰めていこうかな、って思います。


具体的にはメールアドレスの変更作業ですね。この時に発生しうる問題に対するビジネスフローを策定しておかなくてはなりません。
まず、考えられる場合として(1)「管理者」の入力ミス、(2)ユーザー側からの変更要請の2パターンが発生し得ます。
それぞれの場合に於いて最適解となるようなビジネスフローを考えなくてはいけませんね。

※そういやこれを書いている間に思いつきましたが「公募型」という形、つまり団体に参加したい人が自分でメールアドレスを入力して登録する、という形をとる場合もありますね。そしてそれが「承認制」であっても良いわけで。
ここから、Googleフォームのようなアンケートの開発もした方が良さそうだ、ということがわかりますが、ユーザー主導の場合はメールアドレス確認のためのトークンを送信すればいいだけの話ですし、それを変更する場合のフローは共通なので、特に例外として考えないことにしよう･･････。


まず、「管理者」がメールアドレスを誤入力した場合、前提条件として誤ったデータが最初に登録されるということですね。
この誤りの発見方法は3通りあります。(1)デーモンメールが返ってくる、(2)アドレスのコピペミス、(3)メンバーの重複登録(メールアドレスが同じ)
ただ、(3)に関しては登録段階でリジェクトできそうですね。もうちょっとややこしい問題になると、あべこべに登録してしまった場合がクソ面倒になるんですけど、マージさせると問題が出てくるので、解決策はデータ削除からの再登録ということで誤魔化すことにしましょう。半分自分宛てメモになってますね。


メールアドレスが間違っているということが通知されたら、「メンバー」のアドレスの変更を管理者が手動で行うことになります。デーモンや、苦情通知トークンにアクセスされた場合、管理者アカウントに警告が飛ばされ、該当するメンバーにフラグを立てることでその仕組みは実装できます。
そこから先の連絡手段がない場合、こちらといては打つ手がないのでそのメンバーを削除してもらうしかないですね。


(2)のユーザー側からの変更要請に関しては、ユーザー側から、「このメールアドレスに変更になりましたので登録お願いします」という類のメールを管理者から受け取るパターンしか想定しないことにします。
ここで考えなくてはいけないのがイタズラの可能性なんですよね･･････。別にユーザー側で金銭が絡むことはないので、イタズラが発生し得ることはないんですけど、変なアドレスをマージさせてしまうヒューマンエラーも起こりうるので、それに対抗するフローが必要になりそうではある･･････。


さて、どうするのが一番安全安心なのか。
一般的に、メールアドレスが使えなくなった場合でも、IDとパスワードがあればログインできますね。で、それを紛失した状態でメールアドレスも使用できなくなったら、基本的にサポート対象外になりますね。
ただ、オケ団体を想定した場合、連絡不能になると非常に困っちゃいますね。

まずは「本人であると確認できる場合」というのを考えてみましょう。
ひとつはID・PASSの組み合わせが登録されているというケースです。これは自分で自分のメールアドレスを書き換えてもらえれば、全ての団体に於いて情報を更新することができますね。
ただ、前にも言った通りユーザーに基本的に作業をさせないシステム＝「ID登録は必須ではない」というシステムを想定しています。ログインは基本的にメール内に埋め込まれたトークン、および保存されたクッキーにて行う想定です。まぁこのへんのセキュリティに関しても、ちょっと実装がめんどくさそうなとこがありますね。
話が逸れましたが、IDの組み合わせは登録されてない場合が殆ど、と考えます。

つぎにシングルサインオンとしてSNSアカウントが登録されている場合です。
このへんの技術的な話はLivvonを試作したときに触れてるので、なんとかなると思います。もちろん、そのへんのビジネスフローに関してはちょっと一考の余地があるのですぐには実装しないんですけど･･････
というのも、例えばFacebookアカウントを用いてログインしたとき、メールアドレスの情報も一緒に持ってこれるんですよね。これを「普段使っているメールアドレス」と同期させるべきか否か、みたいな話もあります。まぁ、そんな小難しく考えなくても、SNSアカウントの情報はIDとトークンだけ保存しておけばいいかな、とは思うんですけどね。別に使ってるメールアドレスが一緒である必要性まったくないですね･･････僕も捨てアドで登録してるし･･････(笑)

というか、そもそもの話として管理するのが面倒というか、IDとパスワードなんてこっち側でユニークに持っておく必要なんてぶっちゃけないし、SNSログインに統一しちゃうのってアリではって思うんだが･･････。
ぶっちゃけログインページも作るのめんどいから全部外野に丸投げしたい･･････。基本的にエラー処理が発生し得るページ遷移って作るのほんっっっっっっとにめんどいんですよ！手を抜こうと思えば抜けるけど、ユーザビリティがその分下がるんですよ･･････つまりクソシステムになっていく(笑)


そういや、LINEとかもシングルサインオンとして使えるっぽいんですけど、LINEのAPIが使えると便利そーですよね･･････
ただ、無料だとpush送信が50人までしか使えないんですよね･･････この人数は一団体の人数すら許容できないので、無理ですね。
フリーだと応答型のAPIなら無制限に使えるみたいなんですけど、こちらからbotに問い合わせることってあるんですかね？ただ、シングルサインオンは実装する価値あんのかな。うまいことLaravelに対応したライブラリあるとめっちゃ嬉しいんだけど･･････。Laravelの公式サポートはないし、LINEアカウントを使ったログインは実装したことがないのでちょっと沼になりそうですね。まあ最初は実装しないことにしますが、実装したら喜ばれそうね。


で、この２つの条件が「ユーザーの身元保証ができる」＝ログインさせて自力で変更できるという場合です。
これに当てはまらない場合のフローを考えてから作らないとマズいことになります。


ただ、基本的にわけわからん人のイタズラで他の団体が迷惑を被ってはいけないという思想のもとで作らねばまずいですね。
ということで、このビジネスフローの中では不用意にデータをマージさせないというのを頭の片隅においておかなくてはいけませんね。

ってなわけで、方針としては「管理者」に個人的に連絡してもらい、ユーザーデータを更新してもらうというフローになりますね。つまり、この時点ですべての責任は管理者にあるということです。

まあ、ただ単にメールアドレスを変更するだけであれば、新しいユーザーデータを1つ作ればいいだけの話ではあります。
変なデータが登録されたとして、間違いが発覚したらその都度修正すればいいんですかね？あ、いや、だめだ、そうなるとなりすましだった場合他団体のデータが丸見えになるから、基本的に新規登録として扱うってことをしなくてはいけないですね。


あーなんか思考がまとまらなくなってきた。紙に書こう。



ということで、今紙にいろいろ書いてるんですが、これだけで一日分の記事になりそうなので続きは次回にまわします。結構大掛かりなDB構造になりそうですね(笑)