功能權限(Feature Permissions)

功能權限用於控制後台用戶在 Finger Manager 中可以訪問哪些功能模組,以及是否可以使用對應功能。

與數據權限不同:功能權限決定「能不能使用這個功能」,數據權限決定「使用這個功能時,可以看到哪些數據」。

例如某個用戶擁有客戶管理 → 查看客戶功能權限,同時數據權限為 Japan Entity,那麼該用戶可以進入客戶管理模組,但只能查看 Japan Entity 範圍內的客戶數據。因此,功能權限與數據權限通常需要配合使用。

什麼是功能權限

功能權限(Feature Permissions)是 Finger Manager 權限體系中最基礎的功能訪問控制。

它主要用於決定後台用戶是否可以進入某個模組,以及是否可以使用模組中的具體功能。

例如是否可以查看客戶、編輯客戶、查看訂單、管理產品、發布公告、發送 Push Notification、管理用戶或修改系統設定。機構可以根據不同崗位職責,自由組合這些功能權限。

01 模組訪問權限

Finger Manager 可以首先按照一級業務模組控制訪問範圍。

例如工作台、市場與產品管理、客戶管理、交易管理、內容與通知、組織與權限、系統設定、日誌與問題排查、報表與分析。

如果後台用戶沒有某個模組的訪問權限,該模組可以不顯示在左側選單中,或禁止進入。例如 Customer Service 用戶可以看到工作台、客戶管理、內容與通知,但可以不顯示系統設定、組織與權限、API 管理。

02 功能級權限

進入某個模組後,還可以進一步控制其中的具體功能。

例如市場與產品管理可以分別控制市場管理、Desk 管理、產品基礎資料、產品圖標、產品上下架、產品排序、交易時間、價格精度和產品參數配置。

並不是擁有「市場與產品管理」權限後,就必須擁有其中全部功能。機構可以根據崗位職責,只開放必要功能。

03 操作級權限

同一個功能還可以進一步區分不同操作。

常見操作包括 View、Create、Edit、Delete、Publish、Approve、Export、Enable、Disable 和 Manage。

例如某個 Operations 用戶對公告擁有 View + Create + Edit,但沒有 Publish,那麼該用戶可以準備公告內容,但不能正式向用戶發布。

04 查看權限

查看權限(View)用於控制用戶是否可以查看某項功能及相關資訊。

例如 Customer View、Product View、Order View、Position View、Notification View、Report View。

擁有 View 權限後,後台用戶可以查看相應頁面。如果沒有其他操作權限,則頁面可以保持唯讀狀態。

05 新增權限

新增權限(Create)決定用戶是否可以建立新的業務記錄。

例如建立產品、建立客戶、建立公告、建立通知、建立 Banner、建立用戶組、建立後台用戶、建立角色、建立 Organization。

例如擁有 Notification View 但沒有 Notification Create,則只能查看已有通知,不能建立新通知。

06 編輯權限

編輯權限(Edit)決定用戶是否可以修改已經存在的數據或配置。

例如編輯客戶資料、修改產品參數、修改 Banner、修改公告、修改用戶分組、修改角色、修改系統設定。

查看與編輯可以獨立授權。因此,可以允許部分崗位查看重要數據,但禁止其修改。

07 刪除權限

刪除權限(Delete)允許用戶刪除系統允許刪除的數據。

由於刪除操作通常具有較高風險,建議謹慎配置。例如營運人員可以擁有 View、Create、Edit,但不一定擁有 Delete,只有高級管理員才擁有刪除權限。

對於訂單、交易記錄、操作日誌等需要保留歷史記錄的數據,系統也可以完全禁止永久刪除。

08 發布權限

發布權限(Publish)用於控制某項配置是否可以正式對外生效。

常見應用於公告、Banner、普通彈窗、登入彈窗、跑馬燈、Push Notification、App 內通知和產品上架。

例如內容編輯人員負責 Create + Edit,營運主管負責 Publish,這樣可以避免未經審核的內容直接發布至 Finger Trader App。

09 審批權限

審批權限(Approve)適用於需要多人協作或內部審核的業務流程。

例如 KYC / KYB 審核、產品上線審批、通知發布審批、高風險操作審批、權限變更審批、客戶狀態調整。

透過審批權限,可以建立建立 → 審核 → 批准 → 執行的內部流程。

10 匯出權限

匯出權限(Export)控制後台用戶是否可以將數據匯出。

例如客戶列表、訂單記錄、持倉數據、交易歷史、報表和日誌。

查看權限和匯出權限可以分別控制。例如允許客服人員查看客戶資料,但不允許批量匯出客戶資料庫,這樣可以進一步降低數據洩露風險。

市場與產品管理權限

權限示例 Market View、Market Manage、Desk View、Desk Manage、Product View、Product Create、Product Edit、Product Publish、Product Enable / Disable、Product Sort、Trading Hours Edit、Price Precision Edit、Product Basic Information Edit。
使用方式 不同產品營運崗位可以根據職責獲得不同權限。

客戶管理權限

權限示例 Customer View、Customer Create、Customer Edit、Customer Status Manage、Customer Group Manage、Customer Export、Customer Note Manage、Customer Detail View。
角色示例 Customer Service 可以擁有 Customer View、Customer Note Manage;高級管理員可以額外擁有 Customer Edit、Customer Export。

交易管理權限

權限示例 Order View、Historical Order View、Position View、Trading Signal View、Trading Signal Manage、Risk Transfer Manage、Trade Export、Trade Report View。
角色示例 普通客服可以查看部分訂單狀態,Trading Operations 則可以擁有更完整的交易管理權限。

內容與通知權限

內容與通知模組可以將不同營運職責細分給不同人員。

Banner 與彈窗 Banner View、Banner Create、Banner Edit、Banner Publish、Popup View、Popup Create、Popup Edit、Popup Publish。
公告與訊息 Announcement View、Announcement Create、Announcement Edit、Announcement Publish、Marquee Manage、Push Notification Send、In-App Notification Send、SMS Send、Email Send。
營運範圍 Scheduled Publishing Manage、Targeted User Manage、User Group Manage。

組織與權限管理權限

組織與權限模組屬於高敏感後台功能,這些權限通常只授予高級管理員。

權限示例 Organization View、Organization Create、Organization Edit、Organization Manage、User View、User Create、User Edit、User Disable、Role View、Role Create、Role Edit、Role Manage、Permission View、Permission Manage、Data Permission Manage。

系統設定權限

系統設定可能影響整個系統,建議限制給 Super Admin 或指定技術管理員。

權限示例 System Settings View、System Settings Edit、Email Provider Manage、SMS Provider Manage、API Settings Manage、Security Settings Manage、Integration Manage、Home Configuration、Navigation Configuration、Feature Visibility、Branding Configuration、Client Settings。

日誌權限

權限示例 Operation Log View、System Log View、Error Log View、Login Log View、Log Export。
角色示例 普通營運人員可以查看自己的操作記錄,管理員可以查看整個組織的後台操作日誌,安全管理員可以進一步查看系統和登入相關日誌。

報表與分析權限

權限示例 Report View、Report Create、Report Export、Analytics View、Dashboard View。
角色示例 管理層可以擁有 Report View,但不需要產品編輯或客戶管理權限。Finance 則可以擁有特定財務報表訪問權限。

功能權限與選單顯示

Finger Manager 可以根據功能權限動態控制後台介面。

例如用戶沒有 Organization Manage,那麼「組織管理」選單可以直接隱藏。如果用戶擁有 Organization View 但沒有 Organization Edit,則可以顯示組織頁面,但編輯按鈕不可使用。

這種設計可以讓每個後台用戶只看到與自己職責相關的功能。

功能權限與按鈕控制

權限不僅可以控制頁面,也可以控制頁面中的按鈕。

例如某個公告頁面:擁有 Announcement View 可以看到公告;擁有 Announcement Edit 可以看到「編輯」按鈕;擁有 Announcement Publish 可以看到「發布」按鈕;擁有 Announcement Delete 才可以看到「刪除」按鈕。

這樣可以實現更加精細的介面權限控制。

功能權限與角色

一般情況下,功能權限不會逐個直接配置給所有用戶。

更常見的方式是:功能權限 → 組合成角色 → 再將角色分配給後台用戶。

例如 Operations Role 包含 Product View、Product Edit、Banner Manage、Announcement Manage、Push Notification Send;Compliance Role 包含 Customer View、KYC / KYB Review、Compliance Task Manage、Audit Log View。透過角色統一管理,可以大幅減少重複權限配置。

功能權限與數據權限

功能權限和數據權限共同決定最終的訪問結果。

例如某用戶擁有 Order View,說明該用戶可以使用訂單查看功能;同時 Data Permission = US Equity Desk,說明該用戶只能查看 US Equity Desk 的訂單。

最終結果就是可以查看訂單,但只可以查看 US Equity Desk 範圍內的訂單。

示例

User A 角色為 Japan Operations。功能權限為 Product View、Product Edit、Notification Create、Notification Publish。數據權限為 Japan Entity。因此 User A 可以管理 Japan Entity 的產品及通知。
User B 角色為 Customer Service。功能權限為 Customer View、App Notification Send。數據權限為 Assigned Customers。因此 User B 只能查看自己負責的客戶,並向這些客戶發送 App 內通知。

功能權限變更

當員工職責發生變化時,可以修改其角色對應的功能權限。

例如 Operations 原本只有 Banner View、Banner Edit,之後增加職責 Banner Publish,管理員只需要在角色中增加對應權限。

擁有該角色的後台用戶即可根據新的權限規則使用相關功能。

高風險功能權限

部分功能屬於高風險操作,建議單獨控制。

例如 Permission Manage、Organization Manage、System Settings Edit、Security Settings Manage、Customer Export、Trade Manage、API Manage、Notification Bulk Send、Delete、Approve。

這些權限不應預設授予普通後台人員,建議只根據實際職責分配。

最小權限原則

功能權限建議按照最小權限原則(Principle of Least Privilege)配置,即用戶只獲得完成目前崗位工作所需要的功能。

例如客服人員需要查看客戶資料,但不需要修改交易系統設定;營運人員需要管理 Banner 和通知,但不需要管理後台角色;Compliance 需要審核客戶,但不需要發布營銷活動。

透過最小權限配置,可以使系統職責更加清晰,並降低誤操作和權限濫用風險。

功能權限檢查邏輯

功能權限檢查邏輯可以理解為:用戶登入 Finger Manager → 讀取所屬 Organization → 讀取用戶角色 → 讀取角色中的功能權限 → 判斷是否允許訪問模組 → 判斷是否允許使用具體功能 → 判斷是否擁有對應操作權限 → 再結合數據權限確定數據範圍 → 允許或拒絕操作。

功能權限屬於 Finger Manager 權限體系中控制系統功能訪問的核心能力。

機構可以透過功能權限分別控制後台用戶能否查看、建立、編輯、發布、審批、刪除或管理不同業務模組。

再結合角色和數據權限,可以形成:組織確定管理邊界,角色確定崗位職責,功能權限確定可以做什麼,數據權限確定可以操作哪些數據。

從而建立完整、清晰且可擴展的後台訪問控制體系。