系統設定與權限模組

快速理解：本模組把人員身分、組織歸屬、角色功能權限與主管審核範圍組合起來，決定使用者能進入哪些功能、能執行哪些操作，以及能看到哪些業務資料。

1. 模組全貌

管理範圍

本模組擁有 WENK OMS 的共用身分、組織與授權模型：

1. 建立及維護系統帳號，記錄姓名、員工編號、Email、電話、部門與部門小組。
2. 建立角色、加入角色成員，並按功能配置檢視或編輯權限。
3. 建立主管審核群組，把被審核的業務人員集合起來，再由角色決定哪些主管可查看或審核該群組的資料。
4. 在使用者進入頁面及呼叫後端時分層檢查登入與功能權限。
5. 提供部門、角色及審核群組，讓訂單、工單、採購、發票等模組進一步限制資料範圍。

目前設定畫面可直接管理帳號、角色與主管審核群組。部門及部門小組是既有組織主檔，帳號管理只負責選擇歸屬，未見在同一組畫面建立、改名或刪除部門的操作。

不屬於本手冊的範圍

• 各業務模組的送審、退回、通過與歸檔生命週期，仍由該業務模組擁有。
• 合約條款、訂單條款、維肯公司與銀行資訊等是獨立業務主檔，不因出現在設定區就納入本模組。
• LINE WORKS、Asana 及 Google SSO 的外部平台管理不在本模組；本手冊只記錄它們與系統帳號身分的銜接。
• 各清單依負責人、部門、資料類型或狀態衍生的特殊範圍規則，應由對應業務手冊說明。

主要角色

角色	主要責任
帳號管理者	建立、編輯及刪除帳號，配置部門與部門小組
角色與權限管理者	建立角色、維護成員、設定功能的檢視與編輯等級
審核群組管理者	建立主管審核群組並維護被該群組涵蓋的人員
一般使用者	以自身所有角色的合併權限使用系統
主管／審核者	除功能權限外，再依審核群組範圍查看或處理所負責人員的資料
各業務模組	使用共用身分、部門及權限結果，再套用自己的狀態與資料範圍規則

四個不可混用的概念

概念	回答的問題	主要影響
帳號	這個人是誰，是否已完成首次登入，帳號是否仍保留	登入、使用者選單、角色與組織關聯
部門／部門小組	這個人隸屬哪個執行組織	部門工單、可選執行人及部分資料範圍
角色	這個人集合了哪些功能授權	各項系統能力的檢視、編輯或審核權限
主管審核群組	主管負責查看或審核哪些人產生的資料	訂單、採購及發票異動的待審清單與操作資格

「角色成員」代表誰取得一組權限；「審核群組成員」代表誰的業務資料落入某主管的負責範圍。兩種成員關係方向不同，不能以同一份名單替代。

功能權限模型

• 每項可授權能力都有獨立設定，例如訂單管理、部門工單、角色權限設定或發票異動審核。
• 權限分為兩類：一般功能權限決定能否使用某項能力；主管審核群組範圍決定主管可以查看或審核哪些人的資料。
• 系統再按客戶、訂單、工單、採購、發票與設定等業務領域分組顯示，也用來隔離不同領域的主管審核範圍。
• 一般功能的有效等級為「未設定」、「拒絕」、「檢視」、「編輯」；較高等級自然包含較低等級的能力。

2. 核心流程

A. 建立帳號與首次啟用

1. 帳號資料要求英文姓名、中文姓名、員工編號、Email、電話及至少一個部門。
2. 一個帳號可屬於多個部門；每個部門最多搭配一個部門小組，小組必須真的隸屬所選部門。
3. 新帳號初始為「尚未啟用」，並自動加入系統標記的預設角色。
4. 使用者以相同 Email 完成首次 SSO 綁定後，帳號轉為「啟用」，之後才能換取正常存取權杖。
5. 建立帳號後會嘗試補上外部協作平台的使用者識別；同步失敗不回滾已建立的 OMS 帳號。

B. 建立角色與合併功能權限

1. 權限管理者建立角色，加入一位或多位有效帳號。
2. 每個角色可對各項「功能權限項目」分別設定「瀏覽查詢」及「新增、編輯、刪除」。
3. 使用者可同時加入多個角色；系統逐功能合併所有有效角色：
   • 任一角色可編輯，結果為「編輯」。
   • 否則任一角色可讀，結果為「檢視」。
   • 角色有該功能資料但皆不可讀、不可編輯，結果為「拒絕」。
   • 完全沒有該功能時，操作端視為「未設定」。
4. 權限更新或角色成員異動後，後端清除相關使用者快取，使後續請求重新計算。

C. 前端導覽與後端授權

1. 前端進入需登入頁面前，先確認權杖、取得使用者資訊，再載入目前功能權限。
2. 導覽列只保留具有「檢視」以上權限的項目；父選單沒有任何可見子項時也會被移除。
3. 有設定功能要求的路由會檢查「檢視」；不足時導向禁止存取頁。
4. 頁內新增、編輯、刪除與審核操作可再以「編輯」門檻隱藏或停用。
5. 前端檢查只負責操作體驗；後端有標示權限的操作會重新讀取登入者權限，直接呼叫 API 仍須通過後端門檻。這是全系統的通則，其他模組不再重述。

D. 主管審核群組與可審核範圍

1. 群組管理者建立審核群組，將業務人員加入群組。
2. 權限管理者在角色上，分別為訂單、採購與發票領域勾選該群組的查詢或審核能力。
3. 主管加入該角色後，角色與群組權限會連到群組成員，而不是把主管本人加入被審核名單。
4. 「可檢視」用於待審資格與清單可見性；「可編輯」用於真正通過或退回。實際審核仍需同時通過業務模組的主管功能權限與資料狀態檢查。

3. 商業規則

帳號與組織

主題	規則
姓名	英文姓名只接受英文字符；中文姓名只接受中文字符
Email	有效帳號不可重複；可依環境設定限制允許的公司網域
員工編號	有效帳號不可重複；若找到同編號的已刪除帳號，建立流程會恢復原帳號而非另建新身分
部門	至少一個、不可重複，且必須是有效部門
部門小組	選填；每個部門最多一個，且小組必須有效並隸屬該部門
多部門	同一使用者可同時隸屬多個部門；部門型資料範圍取有效部門關聯
部門異動	編輯帳號時以新清單取代有效部門與小組關聯；移除者軟刪除，重新加入則恢復原關聯
預設角色	新帳號自動加入標記為預設的角色；恢復已刪除帳號時只恢復預設角色，不自動恢復其他舊角色
刪除後指派	已刪除帳號及其部門關聯不再出現在一般有效人員與部門人員選項；既有單據、任務及歷史負責人資料不會連帶刪除
刪除後審核	角色成員關聯會移除，使該人失去一般主管功能來源；但其作為「被審核人」的主管審核群組成員關聯目前不會隨帳號刪除

角色與權限等級

主題	規則
角色名稱	有效角色不可同名
角色成員	只能加入未刪除帳號；同一帳號不可重複加入同一角色
多角色合併	按功能取所有有效角色的最高能力，不採拒絕優先，也沒有角色排序覆蓋
「檢視」	允許查詢；也是前端導覽及有標記路由的最低門檻
「編輯」	允許需要編輯門檻的操作，並自然滿足「檢視」的數值比較
勾選關係	讀取與編輯欄位可獨立保存；目前沒有強制「勾選編輯必須同時勾選讀取」，有效判定仍以「可編輯」優先
無能力	讀取與編輯皆關閉時，該角色權限資料視為刪除；使用者若沒有其他角色提供能力，最終無權限
刪除角色	系統標記不可移除的角色不能刪；仍有有效成員的角色也不能直接刪除

後端權限判定

判定方式	語意
單一功能	指定一個「功能權限項目」及最低等級；功能不存在、為「拒絕」，或只有「檢視」卻要求「編輯」時拒絕
多功能其一	指定多個「功能權限項目」及共同最低等級；至少一個功能符合就通過
多功能全部	目前未見要求清單內每一個功能都必須符合的共用判定方式
部門功能	系統保留按指定部門及其上層組織角色取最高等級的能力；目前盤點未見業務端點直接使用這個共用檢查
環境開關	測試、驗收與正式環境啟用功能權限驗證；本機開發環境可關閉，不能以本機放行推定正式環境也會放行

所有業務端點都要求已登入，但功能權限只保護有明確標示的端點。用來擋「端點漏標權限」的全域檢查目前未啟用，因此未標示的端點只剩登入門檻——不能假設後端會從前端路由推導權限。

導覽、路由與頁內操作

• 前端權限以「實際權限等級必須高於或等於所需等級」判斷；找不到功能時為「未設定」，預設不顯示。
• 固定導覽樹與後端回傳的角色合併權限共同決定選單；目前前端未使用後端另一套動態導覽資料。
• 路由只有在明確設定必要功能時才做權限檢查；沒有設定者在前端只受登入限制。
• 頁內操作需要各畫面自行套用「編輯」門檻。選單存在或可打開頁面不代表每個按鈕都可操作。

主管審核群組

主題	規則
名稱、成員與刪除	與角色相同：有效群組不可同名、成員只能是未刪除帳號且不可重複加入、仍有有效成員時不可刪除
授權方向	主管所屬角色取得某審核群組權限，群組成員則成為該主管可處理資料的負責人範圍
領域隔離	同一群組需按訂單、採購、發票三個「業務領域分類」分別配置，不應把某領域權限推定到其他領域
「可檢視」	支援待審清單或可查詢資格；仍可能疊加業務模組自己的功能權限
「可編輯」	支援實際審核；服務層仍會核對目標資料負責人是否落在可編輯群組範圍

審核群組是一般功能權限之外的第二層資料範圍。只有主管功能權限、卻沒有可讀的群組範圍時，可能進得了審核功能但看不到待辦；只有群組關係、卻沒有主管功能權限時，也不能呼叫審核操作。

權限變更何時生效

• 新增或移除角色成員、修改角色功能權限後，後端會清除受影響使用者的權限快取；下一次相關 API 請求重新聚合角色權限。
• 後端功能權限快取正常最長保留六小時，但角色管理流程的主動清除使這類異動不必等待自然到期。
• 前端權限清單在進入應用程式時載入一次，同一畫面不會因另一位管理者修改角色而自動推送更新；使用者需重新載入應用程式，選單、路由與按鈕才保證同步。
• 審核群組成員及群組範圍查詢直接讀取目前有效關聯，未見同一套六小時權限快取；其跨節點一致性與正式生效時限仍需產品及技術共同定義。
• 帳號部門異動會直接改變後續依部門查詢的資料範圍；目前帳號更新流程未明確清除既有使用者及部門權限快取。

4. 狀態與例外

帳號生命週期

「帳號狀態」雖另有「停用」，目前帳號管理畫面及服務流程沒有把帳號轉入或轉出「停用」。畫面上的「刪除帳號」是把帳號、部門、部門小組與角色成員軟刪除，並保留原「尚未啟用」或「啟用」狀態；主管審核群組成員關聯不在這次刪除範圍。

常見阻擋與例外

情境	系統行為
沒有存取權杖進入一般頁面	前端導向登入；直接呼叫需登入 API 時後端回應未授權
使用者資訊取得失敗	前端清除本機登入資料並中止導航
權限清單取得失敗	前端中止導航並顯示權限取得失敗
路由要求功能但沒有「檢視」	導向禁止存取頁
前後端使用不同功能碼或門檻	可能出現畫面可見但系統回應「禁止存取」，或畫面先隱藏其實後端可呼叫的落差
直接呼叫有功能權限標示的 API	不信任前端狀態，後端重新檢查目前登入者的合併權限
主管沒有任何可讀審核群組	待審資格被拒絕或清單沒有可匹配資料
主管可讀但不可編輯該負責人群組	可看待辦，但實際通過或退回時被拒絕
被審核的業務帳號已刪除	不再能被選為新負責人或執行人，既有資料保留
帳號被刪除但仍有既有登入狀態	刪除流程不會轉為「停用」、撤銷既有 refresh token 或主動清除權限快取，無法由目前實作保證立即全面失效
重新建立相同員工編號	恢復原帳號公開身分、部門關聯與預設角色；不恢復其他舊角色

5. 上下游與未確認事項

上下游影響

關係	模組	影響
上游	SSO 身分提供者	以 Email 綁定預先建立的帳號，提供登入身分
上游	部門與部門小組主檔	提供帳號組織歸屬
下游	客戶模組	決定客戶維護、負責業務、財務／法務審核及授信編輯能力
下游	廠商模組	決定廠商維護、類型可見範圍及財務／法務審核能力
下游	報價模組	決定價格卡檢視、維護及服務負責部門選項
下游	訂單與合約模組	提供負責業務、主管群組、Project AE、執行人與功能權限
下游	工單與執行模組	以部門限制工單範圍，以角色控制檢視、派工、個人執行及倍率紀錄
下游	採購與請款模組	提供申請人、員工收款對象、主管審核群組與財務權限
下游	發票模組	提供財務、異動申請、主管群組與會計審核權限
旁路管理	系統管理者權限	清除快取等少數管理操作使用登入權杖內的系統角色，與畫面維護的功能角色不是同一判定來源

待確認

1. 帳號停用與立即失效：需決定「離職／停權」應使用「停用」、軟刪除或兩階段停用，並明定是否立即撤銷 access token、refresh token、所有權限快取及審核／派工資格。現行刪除不足以證明可立即切斷既有登入。
2. 端點漏標的預設政策：後端用來拒絕未標示權限端點的全域檢查目前未啟用；需決定是否採「沒有明確權限就一律拒絕」，並先完成所有端點的豁免與權限盤點。
3. 前端權限即時同步：後端角色異動後，已登入使用者的選單與按鈕不會自動刷新；需決定採重新載入、定期更新、版本號偵測或推送失效。
4. 編輯是否必須包含檢視：資料允許「可編輯但不可檢視」，而有效等級仍判定為「編輯」；需決定管理介面及後端是否應強制編輯必然包含檢視，避免設定語意矛盾。
5. 部門權限模型的正式用途：系統有部門階層角色與部門權限快取，但目前業務端點主要直接以登入者部門清單做資料篩選；需確認要完成部門角色授權、維持單純部門歸屬，或移除未使用模型。
6. 帳號與組織異動生效時限：角色異動會清使用者權限快取，帳號部門異動與刪除則未見相同處理；需定義單機及多節點環境都能遵守的最長生效時間。
7. 審核群組的共用程度：同一群組可分別套用訂單、採購與發票，但名稱仍稱「訂單審核群組」；需決定它是正式共用的主管責任群組，或各領域應有獨立群組與維護入口。

附錄：技術對照（供開發）

中文業務用語	程式識別字	類型
尚未啟用	Unauthenticated	帳號狀態
啟用	Active	帳號狀態
停用	Disabled	帳號狀態
帳號狀態	UserStatus	類型
未設定	None	權限等級
拒絕	Denied	權限等級
檢視	View	權限等級
編輯	Edit	權限等級
可檢視／可編輯	CanRead／CanEdit	權限欄位
功能權限項目	PROMFeatures	功能識別
一般功能權限	PermissionCategory.Feature	權限分類
主管審核群組範圍	PermissionCategory.OrderReviewGroup	權限分類
業務領域分類	FeatureCategory	權限分類