概要

• サロン側の管理画面にある、"予約時間管理"のページを作成する

関連

#26

内容

• pathを/reserve_managementとして/admin/salon配下に設定
• admin/salons_controller.rb内にactionとしてreserve_managementを追加
• def reserve_managementで予約可能時間として登録したデータの呼び出しができるようにする
• /reserve_managementで予約可能時間を登録する用のフォームを置く
• viewを整える

概要

• サロン側の管理画面にある、"予約一覧"のページを作成する

関連

#26

内容

• pathを/reserve_indexとして/admin/salon配下に設定
• admin/salons_controller.rb内にactionとしてreserve_indexを追加
• def reserve_indexで予約済みのデータの呼び出しができるようにする
• テーブルを使って予約データを表示するほか、各予約の詳細ページへのリンクを設置する
• viewを整える

やること

• htmlの記述方法をslimに変更する方法を調べる(まとめる)
• slimを使う方法へ移行

とりあえず参考

• 【爆速で習得】Railsでslimを使う方法から基本文法まで
• テンプレートエンジンSlimでRails開発を効率化しよう
  

備考

• Customerの登録機能の実装のPR終了後に取り組む

概要

• Stylistが提供できるメニューを登録する

内容

• メニュー名、メニュー内容、価格、施術時間, 備考を登録できる
• Userの予約時にメニューを選択できる

概要

• スタイリストが予約受付できる時間/情報の登録ができる機能の実装

関連Issue

#15
#16

登録する内容(2019/06/19現在)

• 予約可能な日時(例: 2019/07/01 12:00 ~ 2019/07/01 13:00 )
• 施術可能地域(例: 渋谷区道玄坂)
• 利用可能メニュー
• 備考

備考

• 利用可能メニューは別途Menu modelのような形で登録させていたものからselectで複数選択できる(#15 )
• 施術可能地域は今後の検索機能実装も考慮して、事前に登録させていたデータから選択できる形式にしたい(別途city及びaddressのような形でデータ登録させて、そこから選択させる形を検討)
• 予約可能な日程は、15分間隔で登録できる
• 利用可能メニューで、複数登録できるようにする方法の検討
• 登録可能な利用可能メニューは、予約可能な日時以内のものだけに制限

概要

• ログイン後の画面遷移の判定処理を書いたメソッドで、レビューも参考に、今後のtype増加等に備え対応方法を検討する

問題

• ログイン後のtypeの判定処理を以下のように記述しているが、typeが増えた場合などに処理速度が遅くなるetc

以下は今後の話として何となくみてもらえればいいと思います（今やらなくて大丈夫です）。
欲を言うと、これ毎回resourceのclassを判定しているので冗長なのと、ログインしたいユーザーのタイプが増えるたびに行が増えていきます。
ので、できれば各Modelで書くか、Decorator層で各クラスごとにメソッドを作ると冗長さが無くなってより良くなると思います。
*パスの話なので、viewに関することなのでmodelに書くかは微妙なところ（まぁ今のフェーズであればModelで書くのでも良さそうかな）
例えばこんな感じ

# app/controllers/application_controller.rb
# resourceはCustomerクラスであり、もっと言うとSalonなどのSubclassなので、わざわざ場合分けしなくとも、SalonなどのModel側でメソッドを作って、それを呼んでやれば良さそう
def after_sign_in_path_for(resource)
    resource.after_sign_in_path_for
end

# app/models/customer.rb
# 子クラスで定義し忘れていた際に例外を出したい
def after_sign_in_path_for
  raise NotImplementedError.new("You must implement #{self.class}##{__method__}")
end

# app/models/customers/stylist.rb
def after_sign_in_path_for
  admin_stylist_path
end

# app/models/customers/salon.rb
def after_sign_in_path_for
  admin_salon_path
end

# app/models/customers/user.rb
def after_sign_in_path_for
  user_path(self)
end

Originally posted by @yu-croco in #2

参考

継承する際に、親でraise出す考え方は下記が参考になるかもです。
メソッドの override を強制する

Originally posted by @yu-croco in #2

やること

• enumを使う場合とenumerize gemを使う場合の比較
• enumを使えるようにcustomer modelのmigrationで、typeのデータ型をintegerに変更
• typeのdefault値はUserになるように設定
• Customer登録時のtype選択フォームで使用するenumをmodels/customer.rbに定義する
• Customerモデルで定義したenumをCustomerの登録フォームで呼び出し

参考

• ActiveRecord::Enum
• Ruby on Rails:ModelのプロパティにEnumを使う※おまけ：ラジオボタンでEnumを扱う
• ActiveRecordのenumで気をつけたい３つのポイント

概要

• サロン側の管理画面にある、"顧客管理"のページを作成する

関連

#26

内容

• pathを/crmとして/admin/salon配下に設定
• admin/salons_controller.rb内にactionとしてcrmを追加
• def crmでサロンを利用した顧客のデータを読み込めるように
• 顧客ごとのデータなど各種条件による検索ができるように
• viewを整える

概要

• スタイリストの管理画面を完成形がイメージしやすい形に整える

内容

• サイドバーの設置
• サイドバーを管理画面に関わる全ページで表示
• 管理画面側で閲覧/操作できるページへのリンクを貼る
• 管理画面のトップページに、当日の予約件数と予約一覧を表示させる
• 予約一覧には各予約の詳細ページへ飛ぶリンクを貼る
• 当日の予約のみを扱うためのメソッドを作成し、管理画面のトップで使用する

概要

• Userがサロン/スタイリストを予約する機能を実装する
• 予約の手順は3パターン(場所から、日時から、美容師から)

予約手順イメージ

Aパターン(場所ベース)

1. 施術を受けたい地域(都道府県単位)を選ぶ
2. 詳細地域(市区町村単位)を選ぶ
3. 施術できる美容師一覧表示&選択
4. 選択した美容師の提供メニュー一覧表示&選択
5. 選択したメニューを施術できる美容師の時間一覧表示&選択
6. 施術できる美容室の一覧表示&選択
7. 予約内容の確認&予約確定
8. /mypageのトップ部分に予約済み情報を表示

Bパターン(日時ベース)

1. 施術を受けたい地域(都道府県単位)を選ぶ
2. 施術開始の日時から選ぶ
3. 施術開始時間に会う美容師一覧表示&選択
4. 選択した美容師の提供メニュー一覧表示&選択
5. 時間とメニューに合う美容室の一覧表示&選択
6. 予約内容の確認&予約確定
7. /mypageのトップ部分に予約済み情報を表示

Cパターン(美容師ベース)

1. 施術を受けたい地域(都道府県単位)を選ぶ
2. 施術できる美容師一覧表示&選択
3. 選択した美容師の提供メニュー一覧表示&選択
4. 選択した美容師とメニューが施術できる時間の一覧表示&選択
5. 施術できる美容室の一覧表示&選択
6. 予約内容の確認&予約確定
7. /mypageのトップ部分に予約済み情報を表示

備考

• 予約手順のイメージはホットペッパービューティ
• SalonとStylistの予約可能時間が異なる場合には予約できないようにする
• Salonと施術可能時間 > Stylistの施術時間の場合には予約できないようにする
• Stylistが事前に提供するメニューを登録しておき、そこからメニュー選択するようにする?

概要

• ある程度の完成形をイメージしたデザインに整える

内容

• サイドバーを設定
• 管理画面のトップでその日の予約件数と予約一覧を表示
• 予約一覧には各予約の詳細を表示するページのリンクを置く
• サイドバーは管理画面側の全てのページで表示する
• 当日の予約情報を管理画面のトップで使用するためのメソッドを作成

概要

• ログイン機能で実装した部分のテストを実装

対応箇所

• spec/models/配下のmodel spec
• 各コントローラに対応するrequest spec
• 各Customer及び非ログインCustomerのログイン時の挙動テスト

やること

• db/fixtures/prefecture.rbをseedsディレクトリ配下に移行
• db/fixtures/category.rbをseedsディレクトリ配下に移行

参考

Railsでfixtureとseedの違いについて教えてください

rails db:fixtures:load を使おう

概要

• 現在1つしかない登録フォームを3つに分割して、登録時にそれぞれ最低限必要なデータを登録させられるようにする

現状

• deviseで生成されるregistrationsディレクトリ配下のnewファイルで全てのtypeを登録できる

やること

• 現在は/registrations/newで一括登録するものを、どのように分割できるのかの調査
• 分割できる場合、どのような構成にするかの検討
• それぞれに応じたテストの実装

概要

• サロンがスタイリスト/ユーザーを受付できる時間やメニューなどの情報を登録する

登録する内容(2019/06/19現在)

• 予約可能な日程(月/日/時/分)
• 施術可能な時間(分)
• 利用可能メニュー(カットやカラーなど、大枠なメニュー)
• 使用可能機材
• 備考

備考

• 利用メニューは別途Menu modelで登録させていたものからselectで複数選択できる
• 使用可能機材は別途equipment modelで登録させていたものからselectで複数選択できる　
• 予約可能な日程と施術可能な時間は、15分間隔で登録できる

概要

• Stylistが提供できるメニューを登録する機能の実装

関連Issue

#14

登録内容

• メニュー名
• 価格
• 施術内容
• 施術予定時間
• 備考

概要

• すでに予約された時間帯の予約可能時間を予約不可の状態にする
  • DBレベルでレコードを登録できないようにする
  • 予約選択時に予約済みのレコードを表示させないようにする
  • 予約済みのになっていないかを判定するメソッドを作成する?

実装

• Reservationテーブルに対してにindexをunique: trueオプションをつけて追加する
• Salons::ReservationおよびStylists::ReservationとReservationをhas_one関連付け

概要

• サロン側の管理画面にある、"売上管理"のページを作成する

関連

#26

内容

• pathを/salesとして/admin/salon配下に設定
• admin/salons_controller.rb内にactionとしてsalesを追加
• 過去の売上情報を呼び出せるようにする
• 過去の売上を、期間に応じたチャートで表示する
• 取引のあるスタイリストごとの売上チャートも表示できるように
• viewを整える

概要

• Reservationに関わる各種テストを作成する

内容

• spec/factories/reservation.rbに10件分のテストデータを作成する
• spec/models/reservation_spec.rbにテスト作成
• Reservationに関わるfeature_specを作成

概要

• Customer登録に合わせたバリデーションを設定する

問題

• Customer modelでバリデーションが設定されておらず、Customer登録時の入力制限など登録内容に合わせた制限が必要

対策

• Customer登録に絡むモデルで、バリデーションが必要な箇所のリスト化
• バリデーションの内容と実装方法を検討
• 各モデルでバリデーションを実装
• バリデーションが行えているかはRSpecでテストを書き確認する

概要

• 予約可能時間から2時間を切った情報を非表示にする

対象

• 予約可能時間の表示がされる全てのページ

理由

• 直近すぎる時間への予約は対応できないと想定し、予約できないように表示させない

概要

予約機能周りのmodel_spec、feature_spec, request_specを実装する

やること

• Customerモデルを継承するモデルの階層をmodels/customers配下となるように変更

理由

• salon.rb、stylist.rb、user.rbはそれぞれcustomer.rbを継承しており、こうすることで継承関係がより明確化される

やること

• app/controllers/application_controller.rbでdeviseを使ったログイン完了後の画面遷移で使うafter_sign_in_pathを、caseを使わない方法で修正

概要

• スタイリストが予約可能時間の登録時に指定する地域で利用するCityとAddressデータを登録させる
• とりあえずCityは東京23区、Addressは渋谷区に対応するデータのみ登録

関連Issue

#14

内容

• City modelを作成し、Cityデータを登録できるようにする
• db/fixture/city.rbを作成し、Prefectureに対応するCityデータを登録
• Address modelを作成し、Addressデータを登録できるようにする
• db/fixture/address.rbを作成し、Prefectureに対応するAddressデータを登録

• 現時点での最終的に目指すところの機能を列挙しています。
• まずは予約機能の実装完了を目指します。
• 転職用PFというよりも、しっかりと1つのサービスとして形にするのを目標にしています

優先順位

1. 予約機能など必要な機能の実装
2. フロントエンドをReact.jsで実装(RailsをAPIサーバー化)
3. AWS使ったデプロイ

サービス概要

• ユーザーがサロンとスタイリストを任意の時間で選択し予約できるサービス
• サービス上での決済機能検討中

実装予定

共通

• 都道府県用モデル
• カテゴリーモデル(e.g. ヘア/ネイル...etc)

テスト

• RSpecを使ってテストを実装
• Controller specではなく、Request specを使う

サロン

• サロン登録(サロン名/カテゴリー/住所/TEL/Email/座席数)
• ログイン後、管理画面に遷移(/admin/salon)
• 予約可能時間の登録(空き日時/提供可能時間/貸出可能器具を登録)
• 予約管理(日時/予約済のユーザー名/スタイリスト名/利用メニュー/価格を表示)
• 完了済取引管理(日時/ユーザー名/スタイリスト名/利用メニュー/価格を表示)
• 売上管理(過去特定期間での売上/対応人数を表示->チャート使って比較
• 取引スタイリスト管理(自サロン利用したスタイリストを表示&備考欄等で特徴記録/ブラックリスト登録できるようにする)
• 所属スタイリスト管理(自サロン所属のスタイリストを紐付け)
• ユーザー用クーポン発券/管理機能

スタイリスト

• スタイリスト登録(スタイリスト名/カテゴリー/所属サロン/Email/TEL/基本活動範囲/スタイリスト歴)
• ログイン後、管理画面に遷移(/admin/stylist)
• 提供可能メニューの登録(メニュー名/内容/施術予定時間/価格)
• 予約可能時間の登録(空き日時/施術可能時間/提供可能メニュー/施術可能場所)
• 予約管理(日時/予約済のユーザー名/サロン名/サロン住所/利用メニュー/価格を表示)
• 完了済取引管理(日時/ユーザー名/サロン名/サロン住所/利用メニュー/価格を表示)
• 売上管理(過去特定期間での売上/対応人数を表示->チャート使って比較)
• 取引サロン管理(利用したサロンを表示&備考欄等で特徴記録/ブラックリスト登録できるようにする)
• 施術したユーザーのカルテ登録(過去の利用履歴一覧表示+備考記入機能、施術画像登録)
• スタイリストの発信用ブログ
• スタイリストの発信用SNS
• ユーザー用クーポン発券/管理機能

ユーザー

• ユーザー登録(ユーザー名/TEL/Email/住所(都道府県)/性別/生年/)
• 予約機能(サロンとスタイリスト、メニューを選択して予約)
• 過去の予約履歴閲覧
• お気に入りサロン/スタイリスト登録機能
• ブログ/SNSのコメント&フォロー機能
• 利用したサロンへのレビュー機能
• 利用したスタイリストへのレビュー機能

概要

• サロン側の管理画面にある、"取引管理"のページを作成する

関連

#26

内容

• pathを/track_recordとして/admin/salon配下に設定
• admin/salons_controller.rb内にactionとしてtrack_recordを追加
• def track_recordで予約管理で"完了済み"にしたデータを表示する
• 月ごとや週ごとなどでデータの絞り込みができるようにする
• viewを整える

やること

• Salon/Stylistともに、判定処理を1つのメソッド内でするか単一責任に基づき2つに分けるかの検討
• app/controllers/admin/salons_controller.rb のset_current_salonメソッドの判定処理をモデルに移行する
• app/controllers/admin/stylists_controller.rb のset_current_stylistメソッドの判定処理をモデルに移行する
• ログイン状態の判定処理を共通化する場合の方法の検討

参考

#2 (comment)