---
title: Invite 功能的資料更動與動線
tags: v1
---

# Table of Content
[ToC]

# 先備知識

## MongoDB Collection: fio

fio = app = S.M.A.R.T. Contract

## MongoDB Collection: alpha_admin

使用者帳號資料

## 畫面上，status 與 UX 的關係


- status: pending 的 APP 會出現在 user dashboard
- status: active 的 APP 會出現在 sidebar - invited app block
- status: reject 的 APP 就不出現
- status: inactive 的 APP，該 User 就不可看到該 APP 畫面
# 目標
- 可以發送邀請 也可以接受或拒絕邀請
- 同時將先前存取 user 與 approver 的資料合併儲存 也就是 fio.users 與 fio.approvers 這兩個資料表

# 規劃

1. 將資料庫的 fio.approvers 與 fio.users 合併成 fio.invitations
- 欄位:

        [
            {
                type: 'user', // user || approver
                email: '[e-mail]' // 被邀請人的 email
                status: pending // 邀請後一率都是 pending 直到被邀請人接受
                date: '2021,01,01' // 邀請日期
            }

        ]
    -  type: user/approver
    -  email: [e-mail]
    -  status: pending/active/reject/inactive
    -  date: 更新日期
 
![](https://i.imgur.com/7CFMz85.png)

2. 在 alpha_admin 新增一個叫 invited(array object)
    - 欄位:

[
{
type: 'user', // user || approver
app_id: ID, //被邀請的app id
app_name: fio.name //被邀請的 app name）
enabled: true / false (solution 是否啟用)
solution: LearningCurve (被邀請的 solution)
status: active/inactive/pending
}

]

    - type: user/approver
    - app_id: fio._id （被邀請的app id）
    - app_name: fio.name （被邀請的 app name） 
    - enabled: true / false (solution 是否啟用)
    - solution: LearningCurve (被邀請的 solution)
## Micky 的想法

Sidebar 資料來源：從 alpha_admin 尋找
不需要依序至 fio.users、fio.approvers 尋找
> 要確保資料的一致性，才能這麼做 [name=Joe]
>> 沒錯。能有兩個方式處理：
>> 1. 在 User management 刪除或變更這個 User，必須：
    >> a. 刪除/變更  alpha_admin.invite
    >> b. 刪除/變更 fio.users 或 fio.approvers
>> 2. 將 fio.users 及 fio.approvers 合併成 invited 的 Array，再加一個欄位判斷「是 user 或 approver」。之後就都透過 fio.invited 尋找，不需要另外在 `alpha_admin` 下增加欄位
>> [name=MickyFan]

> 當 `alpha_admin` 該 user 不存在時，怎麼辦？ [name=Joe]
>> 有登入的才會看到 Dashboard 上的邀請，這裡邀請的資料是透過 fio.users 跟 fio.appreovers 去找到的，然後按下 accept 我們再到`alpha_admin`裡加入第二點的資料 [name=Micky]

被 Reject 後，User 能在 FiO 看到 reject log 嗎？
> User 看不到，可是邀請的人看得到 User 拒絕了他的邀請
> [name=Micky]

## Summary

為了減少搜尋資料的次數
1. `alpha_admin.invited`: 在 User accept 邀請後，在`alpha_admin` 加入所需資料，未來要找被 invited 的資料 只需在 `alpha_admin` 尋找即可
     - 遇到問題 : 資料變更的時候需要在原本出處與新增的地方都做變更
2. `fio.invited`: 把 fio.users 與 fio.approvers 合併成一個叫 invited 的 array 並加入欄位判斷是 user/approver，日後搜尋只需查詢 fio.invited 就好

# 結論

需要從這些角度思考

- 動作(CTA)：invite, aceept, reject
- CRUD 的動線

## 規劃
1. 將 fio.users 與 fio.approvers 存入 fio.invitations 並加入欄位 status : active
2. 將已在 fio.user 與 fio.approvers  存入 alpha_admin.invited 

- School invite Approver
    - FiO:
        - insert in fio.invitations
- Approver accept
    - FiO:
        - insert fio.approvers
        - update fio.invitations
        - insert alpha_admin.invited
- School/Approver invite User
    - FiO:
        - insert in fio.invitations
            - 因為 alpha_admin 可能會不存在該 user
- User accept:
    - FiO:
        - insert fio.users
        - update fio.invitations
            - 註明被 invite 的狀態、日期、被誰邀請等等資訊
        - insert alpha_admin.invited
            - 該 user 總共被 invited 哪些 app
- School/Teacher remove User 
    - FiO:
        - update fio.invitations
            - 註明該 user 被 remove
        - remove alpha_admin.invited
            - 該 user 無法再使用該 app

## 邏輯流程圖：User flow

![](https://i.imgur.com/hvp1NFr.jpg)

## 資料流程圖：Data flow

![](https://i.imgur.com/0zsBK6r.jpg)


## API

### Menu 用的 API

API: 
- GET /my-apps/sidebar

1. function: 我已訂閱的 apps
2. function: 被邀請並已加入的 apps

alpha_admin.invited
{type: approver}
{type: user}

- PUT /username

## 變更後原本資料的影響
### Case 1

1. 抓取資料的欄位變更
    - 解決想法流程圖:    
    
      ![](https://i.imgur.com/3NxhAIG.jpg)
> 加入 status = active 原因: 舊制邀請後自動加入app，因此 status 會是 active 


2. 變更前已經接受邀請的人 `alpha_admin.invited` 沒資料
    - 解決想法流程圖: 
        
         ![](https://i.imgur.com/GfobD8e.jpg)
### Case 2
- 寫一支程式一次搞定
    - migration.js  

## Final
- 採用 Case 1