ユーザの管理

# 見て頂きたいものについて(私信)
自分の注意不足などで、このPRはかなり量が膨らんでしまいました。
そのため、以下のものだけ見て頂ければ十分かと思っています。
* [app/controllers/admin/items_controller.rb](https://github.com/onionSoup/tea/blob/admin_user/app/controllers/admin/items_controller.rb)
* [app/controllers/admin/order_details_controller.rb](https://github.com/onionSoup/tea/blob/admin_user/app/controllers/admin/order_details_controller.rb)
* [app/controllers/admin/users_controller.rb](https://github.com/onionSoup/tea/blob/admin_user/app/controllers/admin/users_controller.rb)
* [app/controllers/order_details_controller.rb](https://github.com/onionSoup/tea/blob/admin_user/app/controllers/admin/order_details_controller.rb)
* [config/locales/ja.yml](https://github.com/onionSoup/tea/blob/admin_user/config/locales/ja.yml)
* [app/models/user.rb](https://github.com/onionSoup/tea/blob/admin_user/app/models/user.rb)

この他は、以下のような作業でした。これらは見て頂かなくても大丈夫かと思います。
* CSSを整理する。（SCSSのネストを使っていなかったのを使う）
* ビューを整理する。（文言の統一、長すぎる行の改行、`dom_id`の使用など）
* テスト
* 空白や、式と戻り値の`()`の区別などミスの修正

## UI について
[heroku](http://calm-lowlands-7932.herokuapp.com/) に上げました。
今回は[ユーザー管理ページ](http://calm-lowlands-7932.herokuapp.com/admin/users)を作りました。（ログインが必要です。）

# このPRで特に何をするか
* 管理者がユーザーの管理をできるようにします。
  * ユーザーの削除
  * ユーザーの名前変更
  * ユーザーの注文状況の確認
  * ユーザーの注文明細追加、消去 

 以上を管理者ができるようにします。

ユーザーの注文状況確認は、「ネスレ入力用ページ」「発送待ち商品の確認」の２つのページのUIを変更することで対応します。

# 前回PRではできなかったこと
前回までは、上記の機能がありませんでした。
特にユーザーの注文状況の確認ができないのは大きな欠陥でした。

つまり、どのユーザーが何を注文したかを確認する方法が（お茶が届いたとシステムに知らせるまで）ありませんでした。例えば、
* 「急な出張でお茶を注文したくなくなったであろう人がお茶を注文しているかどうか、管理者として知りたい」
* 「ユーザーとして、お茶の注文を取り消したくなったが、忙しいので管理者にやっていてほしい」

というような事態に対応できませんでした。

# 終了条件（どうしたらWIPが取れるか）
  * [x] 管理者として、ユーザーの削除ができる
  * [x] 管理者として、ユーザーの名前の変更ができる
  * [x] 管理者として、ユーザーごとの注文状況を見ることができる
  * [x] 管理者として、ユーザーの注文明細追加、削除 ができる
  * [x] 以上の機能がテストされてる
  * [x] 読みやすいコードになっている （特にパーシャルを使ったテンプレートの整理とCSSの整理）

# やらないこと
以下は次回のPRでやります。
* すべてのテンプレートを`Haml`に書き直す。
* 商品管理ページのバリデーション表示を修正する。

ここまで念入りに書かないといけないのであれば、「orderのコールバックafter_destroy :create_another_order」をコールバックじゃなくすると良いのでは。

結局、コールバックを実行するときとしない時、2種類(以上)の文脈で消されることがあるってことだよね。で、一方の文脈に過剰適応したせいで、他の文脈で大変になっているように思える。じつは`create_anothoer_order`することは、削除することそれ自体と結びつくわけではないのではないか、と思うのでした。