权限（Permissions）

什么是权限

权限（Permission）决定后台用户能看什么、能操作什么、能管理什么。

Finger Manager 的权限可以覆盖多个层级，例如页面访问权限、功能权限、操作权限、数据权限、API 权限和管理权限。

系统会根据用户拥有的角色及权限，决定后台最终向其开放哪些内容。

01　功能权限

功能权限决定用户可以进入哪些 Finger Manager 模块。

例如工作台、市场与产品管理、客户管理、交易管理、内容与通知、组织与权限、系统设置、日志与问题排查、报表与分析。

如果用户没有某个模块的访问权限，该模块可以不显示，或者禁止用户进入。例如客服人员可以拥有客户管理权限，但不拥有系统设置权限，那么该用户无法访问系统配置相关页面。

02　操作权限

进入模块后，还可以进一步控制用户能够执行哪些操作。

常见操作权限包括 View、Create、Edit、Delete、Publish、Approve、Export、Import、Enable、Disable 和 Manage。

例如在“内容与通知”模块中，某用户可以拥有 View、Create 和 Edit，但没有 Publish 和 Delete。这意味着该用户可以创建和修改通知，但不能正式发布或删除内容。

03　查看权限（View）

查看权限是最基础的权限类型。拥有 View 权限后，用户可以查看对应页面或数据。

例如 Customer View 允许查看客户列表，Order View 允许查看订单，Product View 允许查看产品配置。

只有查看权限而没有编辑权限时，系统可以将相关页面设置为只读状态。

04　创建权限（Create）

Create 权限决定用户是否可以新增数据。

例如新增产品、创建通知、创建用户、创建角色、创建用户组、创建组织和创建定时任务。

如果用户只有 View 权限，则可以查看已有数据，但无法创建新的记录。

05　编辑权限（Edit）

Edit 权限决定用户是否可以修改已有内容。

例如修改产品信息、修改客户资料、编辑公告、修改 Banner、修改用户分组和修改系统配置。

机构可以将查看和编辑权限分别授予不同岗位。

06　删除权限（Delete）

Delete 属于风险相对较高的权限。拥有删除权限的用户可以删除系统允许删除的数据。

例如删除草稿、删除用户组、删除未使用配置和删除部分后台记录。

对于订单、交易记录、操作日志等需要长期保留的数据，系统可以限制永久删除。在实际管理中，建议只向少数管理员授予 Delete 权限。

07　发布权限（Publish）

Publish 权限用于控制内容或配置是否可以正式生效。

例如发布公告、发布普通弹窗、发布跑马灯、发布 Banner、发送 Push Notification 和发布产品配置。

例如运营人员可以负责 Create + Edit，而主管负责 Publish，这样可以建立“制作”和“发布”分离的内部管理流程。

08　审批权限（Approve）

对于需要内部审核的业务，可以使用 Approve 权限。

例如客户审核、KYC / KYB 审批、高风险操作审批、产品上线审批、通知发布审批和权限申请审批。

没有 Approve 权限的用户可以提交业务，但无法执行最终批准。

09　导出权限（Export）

Export 权限决定用户是否可以将系统数据导出。

例如客户数据、订单数据、交易记录、报表、日志和统计数据。

由于导出可能涉及大量业务或客户信息，建议将导出权限与普通查看权限分开管理。例如某用户可以在后台查看客户资料，但不能批量导出客户数据。

10　数据权限（Data Permissions）

功能权限解决“可以进入哪个模块”，数据权限则解决“进入以后可以看到哪些数据”。

例如同样拥有客户管理权限，User A 可以查看全部客户，User B 只能查看 Japan Entity 的客户，User C 只能查看自己负责的客户。

因此，数据访问范围可以独立于功能权限进行配置。

11　常见数据范围

Finger Manager 可以根据机构结构设置不同的数据访问范围。

例如 All Organizations 访问全部组织的数据，Current Organization 只访问当前所属组织的数据，Specific Organizations 只访问指定组织，Team 只访问所属团队负责的数据，Assigned Users 只访问分配给当前用户的客户或业务，Selected Markets 只访问指定市场相关数据，Selected Desk 只访问指定 Desk 相关数据。

通过数据权限，可以在同一个后台功能中进一步建立数据隔离。

12　权限与组织

权限可以受到 Organization 范围限制。

例如 Japan Entity 的 Operations 用户拥有 Product Edit，但其数据范围为 Japan Entity，那么该用户只能修改 Japan Entity 的产品。即使 Hong Kong Entity 也存在产品，该用户也无法进行操作。

因此，一个完整权限通常可以理解为：功能权限 + 操作权限 + 数据范围。

13　权限与角色

实际使用中，通常不会逐个为每位用户设置大量权限。

更常见的方式是先建立权限，将多个权限组合成角色，再把角色分配给用户。

例如 Operations Role 包含 Product View、Product Edit、Banner View、Banner Edit、Notification Create 和 Notification Publish。当用户获得 Operations 角色后，即自动获得这些权限。

14　直接权限

在部分特殊情况下，也可以为单个用户授予额外权限。

例如某位 Operations 员工正常情况下没有 Export Report 权限，但由于该员工临时负责报表工作，可以额外授予 Report Export。

这种权限可以作为角色权限之外的补充。对于长期权限，通常仍建议通过角色统一管理。

15　权限继承

对于存在组织层级的机构，可以根据系统配置使用权限继承机制。

例如 Group Administrator 拥有集团级访问权限，则可以访问下级 Japan Entity、Hong Kong Entity 和 Singapore Entity，而子组织管理员只能管理自己所属组织。

通过权限继承，可以减少大型集团重复配置权限的工作量。

16　功能权限示例

17　敏感权限

部分权限涉及较高风险，应谨慎授予。

例如 Permission Manage、Organization Manage、User Delete、Customer Export、Trading Manage、API Manage、Security Settings、System Settings 和 Audit Log Export。

这些权限通常建议只授予 Super Admin、高级管理员和指定负责人，并通过操作日志记录相关行为。

18　权限组合

Finger Manager 可以通过权限组合建立不同级别的访问能力。

例如只读用户拥有 View，普通操作人员拥有 View + Create + Edit，运营主管拥有 View + Create + Edit + Publish，管理员拥有 View + Create + Edit + Publish + Delete + Manage。

不同模块不一定需要采用完全相同的权限组合。机构可以根据实际风险进行配置。

19　最小权限原则

建议机构按照最小权限原则（Principle of Least Privilege）配置后台权限，也就是说后台用户只获得完成当前岗位职责所必要的权限。

例如客服人员需要查看客户资料，但不一定需要导出全部客户数据；运营人员需要发布活动内容，但不一定需要修改系统安全配置；交易运营人员需要查看订单，但不一定需要管理后台角色。

通过最小权限原则，可以降低系统内部风险。

20　职责分离

对于重要业务，可以通过权限拆分实现职责分离。

例如运营人员负责 Create + Edit，运营主管负责 Approve，管理员负责 Publish，这样一条重要通知需要经过不同人员处理后才能正式发布。

对于交易、客户审核或高风险系统操作，也可以使用类似机制。

21　权限变更

管理员可以根据员工职责变化调整权限。

例如员工原本只有 Customer View，之后由于职责变化，需要增加 Customer Edit，管理员可以通过修改角色或用户权限完成调整。

权限变更后，系统按照新的权限规则控制其后台操作。

22　权限停用

当某项权限不再需要时，可以从角色或用户中移除。

例如员工调离岗位后，可以移除 Notification Publish，保留 Notification View。

这样用户仍然可以查看历史通知，但不能继续发布新的内容。

23　API 权限

除后台页面权限外，Finger Manager 还可以对 API 访问进行独立控制。

例如 Market Data Read、Customer Read、Order Read、Order Write、Notification Send 和 Account Manage。

API 权限可以与后台操作权限分开管理。这可以避免获得后台访问权限的用户自动拥有 API 操作能力。

24　权限检查

当用户执行后台操作时，系统会进行权限检查。

流程通常为：用户发起操作 → 识别当前用户 → 读取所属 Organization → 读取用户角色 → 读取角色权限 → 读取数据访问范围 → 判断是否允许执行 → 允许或拒绝操作。

如果没有相应权限，系统不会执行该操作。

25　操作日志

权限相关操作可以进入 Finger Manager 的操作日志。

例如新增权限、修改角色权限、授予权限、移除权限、修改数据范围和调整 API 权限。

日志可以记录操作用户、操作时间、权限名称、修改对象、修改前状态和修改后状态。这有助于机构追踪权限变化并进行内部审计。

权限管理逻辑

权限管理逻辑可以理解为：定义系统权限 → 按照业务模块分类 → 设置操作级权限 → 设置数据访问范围 → 将权限组合到角色 → 将角色分配给后台用户 → 用户登录 Finger Manager → 系统读取角色与权限 → 判断功能访问范围 → 判断数据访问范围 → 判断具体操作权限 → 允许或拒绝操作。