# ConfOps 2024 系統開發 / Requirements & Spec

## 取名
- OrgForm
- [name=Mac] Idea: ConfOps

## 群組
https://chat.coscup.org/coscup/channels/conf-ops

## 今日目標
- 排序工作優先度
- IU
- 今年優先 focus 在贊助組的工單需求
- Mac
- 今年優先 focus 在議程組的 Email 需求
- 工作日程
- 在過年前，完成基本的工單需求給贊助組使用。
- 如何對齊整合功能
- 先暫時擱置，等之後在找時間整合。

## 技術線

ref: https://www.arewewebyet.org/

- 後端
- 程式語言
- Rust
- Datebase
- Diesel (ORM & SQL Client) (MIT or Apache 2.0)
- MySQL 8.x (Community Version)
- Web framework
- 待定
- 候選
- Actix Web
- Rocket (MIT or Apache 2.0)
- Axum
- 前端
- 程式語言
- JavaScript/TypeScript (Apache 2.0)
- framework
- Vue (MIT)
- UI framework
- Naive UI (MIT)
- License
- AGPL

## 規格
- 共通
- 是否以活動為單位？
- [name=Mac] 支援
- [name=IU] 某些功能例如模板(歷史)可以沿用、跳脫單位限制
- 活動界線
- 以活動為單位 (圍繞在活動事件上)、admin
- Dashboard (首頁)
- 待辦事項
- 可執行操作
- 通知
- ~~支援的 Widget (先寫死)
~~- 根據腳色不同~~
- 用戶系統
- 使用者
- 每個帳號的最小單位
- user id (業務 primary key)
- 這個系統內部自動產生的 uuid (待定)
- 暱稱 / email (auto complete)
- 每個帳號可以設定多個 Email
- 可以用第三方登入
- *** Email 寄連結登入
- 未來
- 志工系統
- Pretalx
- 帳密
- 角色 => 改成標籤 (list or map[k,v]) role=page:贊助商, key=角色,value=贊助商
- 裡面有多個使用者
- 像是：講者、贊助商、議程組、資訊組
- 每個使用者可以是多個角色
- 每個角色有專屬的登入頁面
- 公告
- 只是登入頁面，裡面的功能會根據使用者有的角色出現。
- \****主要還是以使用者為 entity
- 以 tag 為概念 [name=Mac]
- example

                {
                    user_id:"user entity",
                    tags: [
                        {key:"腳色", value:"贊助商"},
                        {key:"權限", value:[...]},
                        {key:"組別", value:"議程組"}
                    ]
                }

                user_role_keys (暫時不做 many2many, 可以一對多)
                user_id, role_id, xxxx, xxxx, xxxx
                1, 腳色:2, ...

                flow:[
                {組長要同意},
                {檢查通知},
                {按下完成}
                ],
                background:[ (不一定是通知)
                    {如果兩天狀態沒有==2: 通知xxxx},
                    {填完表單要xxxx}
                ]

                IU:
                通知誰、內容是甚麼?

- 以工單為主還是以流程為主
1.
take_action (editable), pending (non-editable), approved (non-editable), rejected (editable)

2.
take_action (editable), pending (non-editable), approved (non-editable), rejected (editable)

last approved review

** approve status flow 可以延後

- 角色系統
- 管理者
- 使用者標籤
- 使用者
- 角色的登入頁內容
- 網址
- 登入前訊息
- 登入後訊息
- ~~角色訊息公告~~
- 工單系統
- 工單
- 單向
- 功能
- 流程 (process)
- 類型
- 表單模組
- 審核模組
- 是否必須完成？
- 是否能重複填寫？
- 從歷史帶入 (把去年的工單結構複製出來)
- 表單模板
- example: 開一個贊助商資料收集工單，贊助商 A,B,C 都要來這個工單個別填寫工單中的表單
- 表單模組
- 設計理念：簡易、防呆、靈活
- 填寫者
- 使用者標籤
- 使用者
- 欄位
- 類型
- 文字
- 單選下拉選單
- 多選下拉選單
- 檔案
- 限制大小 副檔名
- 圖片
- 限制大小 尺寸 格式
- 是否
- 狀態
- 是否必填
- 是否能修改？
- 基本的流程判斷
- 根據某欄位，決定題目是否顯示
- 預設值
- 可以使用某個表單
- 截止時間
- 審核模組
- 審核者
- 使用者標籤
- 使用者
- 成功 -> 下一關
- 失敗
- 回上個流程
- 整個流程重來
- 管理
- 查看工單狀態
- 查看工單回應
- 回應結果總表
- 做成像試算表可以即時編輯
- -----
- reviewer (just a idea)
- reviewer 群組，根據工單的 type, team 等
- reviewer 模組
- Usecase
- 講者(自己提名)、社群(幫講者提名) 申請 2024 邀請函、簽證
- 申請表單
- 表單最新狀態
- 留言要求補件
- 檢視 attachment 最終邀請函
- 申請拒絕
- 超過時間不可送出申請 (開始與截止時間)
- *應該是可以 apply 到工單的概念來做到這些事

- Email 寄件 (可能不叫寄件)
- 寄法
- API 寄件
- by 群組寄件
- 選定寄件群組 (不一定需要整合，寄件池維護可能要想一下，下述功能應該是沒有強連結概念的，頂多是 by 事件的聯絡簿)
- 聯絡人池 (*主體可能不是使用者)
- email: primary key
- related emails many-2-many
- link to 寄件群組清單
- 可 sync by api (ex: pretalx)
- 可以 sync by 內部 user list
- 可手動增加清單元素 (ex: 手動新增寄件群組)
- 已讀模式 (在寄件尾放入 coscup.png?id=dsa9ujd09asjd09as)
- 頁面
- 已寄出信件
- 可查詢事件、事件列表
- 群組是否已讀
- 所有寄件事件
- tag filter
- 未排程寄件事件
- 已排程寄件事件
- 其他自訂的 tag
- 功能
- 向動態的收件者寄件 (寄件方法: 可能需要客製化，不確定如何手動篩選名單，似乎會有很多工，不如暫時寫 code 取代手動設定)
- 錄取信件
- 拒絕信件
- 邀請信件
- 行前通知信件
- 事件內容 (就是郵件)
- 新增事件
- 內文編輯
- WYSIWYG 編輯內文
- 儲存成樣板
- 載入樣板
- 事件負責人 (lists of id)
-
- 支援模板變數替換
- 帶入寄件人名稱
- 帶入簡易運算結果 node eval
- 排程預約功能 (邏輯)
- 寄出前可以 Preview 所有寄件池套用實際變數後長怎樣
- 生成寄件池，通知寄出，每隔 1 秒發送一次
- (實驗性質、P3 not urgent)
- 議程組行政模組 (單獨的模組)
- 更換房間事件
- event listener
- 事件申請列表
- list preview 狀態 (已接受、已過期)
- 事件細節
- 新增更換房間事件
- 觸發方式: 初始不接受講者自己點，要議程組組員自己上來點 2 個 pair 的議程，系統自動寄出兩個 email 給講者 (寄出一樣被視為事件，會上 tag)，內容會包含 LINK，兩個講者去點選 \[同意更換時段\]，系統就會自動更換，如果 2 日內沒有點選，會自動過期，並且通知議程組和講者這個請求沒有被接受，需要重新處理。
- 議程組文案廣播事件 (目標: 提早預想有哪些重大廣播事件，新增後，在到期前把文案完成)
- 事件列表
- 新增廣播事件、文案、文案負責人 (lists of user id)、deadline
- 完成新增後審核、點選完成後自動加入行銷組工單
-