# キャンペーンリスト相互確認機能

###### tags: `設計`

## 現状のプロセス

運用メンバー->運用メンバー: 1. リストをスクレイピングなどで収集して作成
運用メンバー->お客様: 2. リスト作成の完了メールを送信
お客様->お客様: 3. リスト確認
お客様->運用メンバー: 4. リストが全然ダメな場合は修正依頼を運用メンバーへ\n1からやり直し
お客様->運用メンバー: または、\n5. リスト確定

この運用をシステム化して工数削減をしたい

## システム化後のプロセス

共通リストにリストが十分にある前提です。

運用メンバー->Kaitak: 1. 共通リストから選択し、\nキャンペーンを作成
運用メンバー->Kaitak: 2. キャンペーンリストを確認し、\n提示するリストを確定
Kaitak->お客様: 3. リスト作成の完了メールを自動送信\n （KaitakへのログインURLが書かれている）
お客様->お客様: 4. Katiakへログインし、\nリスト一覧画面を確認
お客様->Kaitak: 5. リスト一覧で修正を行う\n（選択して、削除など）
お客様->Kaitak: 6. リストが全然ダメな場合は、\nリスト修正依頼をKaitak上から行う
Kaitak->運用メンバー: 7. リスト再修正メールを自動送信\n
お客様->Kaitak: 7. リスト確定
運用メンバー->Kaitak: 8. リスト再作成

Kaitak->運用メンバー: 8. リスト確定メールを自動送信

## 一般ユーザーのキャンペーンリスト確認画面 （確認、削除）

### API

campaignsテーブルのlist_statusを作成する

- list_status（enum）
- unedited: 0
- admin_draft: 10
- admin_complete: 20
- admin_update: 30
- admin_update_complete: 40
- user_complete: 50

1. メンバーが未作成 unedited
2. メンバーがリストを作成中 admin_draft → admin_complete
3. メンバーがリストを作成 admin_complete →　user_complete（作成完了メールをお客様に）
4. お客様が確認中
5. お客様が確定 user_completeに更新 メール送信

1. お客様が修正依頼 admin_updateに更新 メール送信
2. メンバーが修正中 admin_update
3. メンバーが修正完了 admin_update_complete

> 課題

statusを更新する時のメール送信処理が散乱したり、条件分岐が多くてコードから意図をよみづらい

> 解決策1

ValueObjectを採用

campaignsがもつlist_status

class ListStatus
    def get()
    end
    
    def set(status)
        # メール送信処理
        if admin_update_complete
        
        end 
    end
end

> 解決策２

https://github.com/aasm/aasm
を使う

もし、enum自体にevent発火処理があればgemが不要

#### API

##### お客様に対して、キャンペーンが1-1で運用する為、画面もそうする

customer 1-N campaign
campaign 1-1 targets（リスト）

今後

customer 1-N campaign
campaign 1-1 targets（リスト）

処理で1-1を作ってる
customerIDで紐づくfirst Campaignのtargetをとってくる

- get campaigns/:customer_id/targets
- get customer/:id/targets
- delete api/v1/campaigns/:id/targets
- （改修）
- 配列でも削除ができるようにする （all: false）
- paramsでallプロパティを定義。デフォルトでtrueにする

params do
    optional :all, type: Integer, default true
end

#### front

- キャンペーン一覧画面がある
- 左メニューに「キャンペーンリスト確認」を追加
- キャンペーンリスト確認画面
- デフォルトで「確定」ボタンがある
- １つでもチェックが入っていると「削除」ボタンに変わる
- キャンペーンリストにページネーションをつける
- 共通リストを参考に。10件でよい
- ページネーションが変わってもチェックが保持されるようにする

## 一般ユーザーのキャンペーンリスト確認画面 (修正依頼）

#### API

- tableを作る
- list_modifying_detail
- campaign_id
- content
- post api/v1/list_modifying_details
- campaignsのlist_statusをadmin_updateにする
- 管理者に修正依頼メール送信

#### front

- 修正依頼ボタンを確定ボタンの横に作成
- 削除時は非表示
- クリックするとモーダルが表示されて、修正内容を書いて送信できるようにする
- 修正依頼後は「修正依頼中です。完了するまでしばらくお待ちください。」と文言を表示させる

# 再設計

## [管理者としてキャンペーンリスト確認画面を閲覧できる #390](https://github.com/imejin-dev/form-sales-bot/issues/390)

### 受入条件
- [ ] キャンペーン詳細画面のタブ
- [ ] 「キャンペーンリスト」タブが存在すること　
- [ ] 初期タブであること
- [ ] 「爆撃ターゲット一覧」という文言が「爆撃」に変わっていること
- [ ] キャンペーンリスト画面
- [ ] 全リストが表示されていること
- [ ] リスト確定ボタンが存在すること
- [ ] リスト全削除ボタンが存在すること
- [ ] 削除用のチェックボックスがリスト左側に存在すること
- [ ] １つでもチェックボックスにチェックが入っている場合「リスト確定」ボタンと「リスト全削除」ボタンが非表示になり、「選択リスト削除」ボタンが表示されること

### API

- カラム追加
- campaignsテーブル
- list_status
- Enum型
1. unedited: 0　（デフォルト）
2. admin_draft: 10
3. admin_complete: 20
4. admin_update: 30
5. admin_update_complete: 40
6. user_complete: 50
- 使用するAPI
- 既に存在する
- ターゲット一覧（リスト一覧）取得
- GET api/v1/targets（params campaign_id）
- ページネーションを追加する必要があるかも？
- 追加するのであれば１つのAPIの中で、is_ページネーションのような命名のパラメータでページネーションを返すか、全て返すか分けたい。
-　paramsでoptionalにすればパラメータ必須かどうかは任意にできる。かつ、デフォルトを設定できるのでデフォルトでfalseにすれば、既存の処理に影響を与えずに改修できると思う。
- リスト全削除（既に存在する）
- DELETE api/v1/campaigns/:id/targets
- 作成が必要
- リスト確定
- PUT api/v1/campaigns/:id/list_status
- list_statusをadmin_completeに変更する
- 変更処理はafter_updateか、modelメソッドにしたい
- 選択リスト削除
- DELETE api/v1/targets？

### Front

- キャンペーン詳細画面のタブ
- 爆撃ターゲット一覧タブの文言を、爆撃に変える
- 「キャンペーンリスト」タブを追加
- キャンペーンリスト
- リスト確定ボタンを追加
- リスト全削除ボタンを追加
- リスト左側に削除用チェックボックスを追加
- １つでもチェックが入っている場合は、リスト確定ボタンとリスト全削除ボタンを非表示にし、選択リスト削除ボタンを表示させる。チェックが入っていない場合は逆。
- 10件ごとにページネーションが有効になっていること

### その他

管理者（１）のとこ

https://docs.google.com/presentation/d/13K9s-hn7yqHrVXyDDQZa2BQaqes1az-G9bRNQp1wi60/edit#slide=id.gaf521cea61_0_31

## [管理者としてキャンペーンリスト作成メールを送信したい #391](https://github.com/imejin-dev/form-sales-bot/issues/391)

### 受入条件
- [ ] 管理者がキャンペーンリスト画面で、リスト確定ボタンを押下したらお客様にリスト作成メールが送信されること

### API

- リスト確定
- PUT api/v1/campaigns/:id/list_status
- メールを送る条件
- Gem、AASMを利用してlist_statusが変わったらEventを発火
- admin_completeに変わる。かつ、変わる前のステータスがuneditedまたはadmin_draftであればメール送信
- メールのtoはお客様（Customer）
- メールのccはENVで設定できるようにしたい
- 将来的に文案等の通知メールもCCをENV管理にしたいので抽象的な命名にしたい
- notification_email_ccがよい？

### その他

## [お客様へのアカウント設定メールの送信プロセスを変更したい #400](https://github.com/imejin-dev/form-sales-bot/issues/400)

### API

- post api/v1/customer （既存）
- メール送信処理を追加
- 内容はwiki参照
- put api/v1/drafts/:campaign_id/campaign （既存）
- メール文面の内容を変更
- ファイル app/view/notification_mailer/campaign_draft_notification_mail.erb
- 内容はcampaign_draft_update_complete_notification_mail.erbと同じく、ダッシュボードのURLを含めた文面にするだけでよい

##