授权

授权机制定义了用户在认证后可执行与不可执行的操作。Aptli 结合了两个独立的层级：宽松的管理员权限（您可以做什么）和严格的角色限制（您不能看到什么）。它们共同为管理员提供对功能和数据可见性的精细控制。

授权模型概述

Aptli 的完整安全模型有三个层级：

1. 身份验证 — 您是谁（参见身份验证章节）
2. 管理员权限 — 您能修改什么（许可型授权）
3. 角色限制 — 您不能查看什么（限制型过滤器）

所有限制均在服务器端执行——未经授权的数据永远不会发送到您的浏览器，无论您通过 UI、API 或导出尝试什么操作。

该模型在保持安全性的同时提供了极大的灵活性。

管理员权限（宽松模式）

管理员权限允许修改信息或变更状态。若无此权限，用户仅能查看数据并编辑个人资料。

常见管理员权限：

• usersUpdate — 编辑其他用户资料（姓名、职位、部门——不含电子邮件/密码）
• usersLogout — 强制注销或强制锁定用户
• usersDelete — 删除用户账户
• usersCreate — 创建新用户或恢复已删除账户
• pointsCreate、pointsUpdate、pointsDelete — 修改点要素
• workOrdersCreate、workOrdersUpdate、workOrdersDelete — 管理工单
• assignmentsCreate — 创建工作分配
• reportsCreate — 提交工作报告
• transactionsCreate — 创建库存交易

超级权限（凌驾于所有其他权限之上）：

• appSettingSchemasModify — 修改应用程序级设置（域名、超时设置、安全策略）
• adminRightsModify — 向其他用户授予管理员权限
• viewDeleted — 查看已删除记录（几乎通用，部分受角色限制覆盖）

检查用户管理员权限：

1. 导航至管理 → 用户
2. 打开用户资料
3. "管理员权限"部分列出了所有已授予的权限

角色限制（限制模式）

角色管理页面显示已配置的角色限制

角色是一组限制集合，用于阻止查看和修改具有特定特征的记录。角色成员身份将所有限制应用于该用户。

角色组成部分：

• 成员 — 受这些限制约束的用户
• 所有者 — 控制成员资格的用户（或拥有 rolesUpdate 管理权限的用户）
• 角色限制 — 隐藏特定数据的字段级过滤器

角色限制结构

角色详情页面展示字段级权限配置

每项限制定义：

• 模型 — 哪种数据类型（点、多边形、分配等）
• 字段 — 按哪个属性过滤（所有者、状态、类别、自定义字段）
• 比较 — 匹配方式（=、!=、>、<、包含等）
• 筛选值 — 匹配的具体数值
• 权限 — 被限制的操作（读取、编辑、创建、删除）

示例用例：承包商分离

场景： 防止承包商 A 查看承包商 B 的工作内容

设置：

1. 创建角色："承包商 A"
2. 添加角色限制：
   • 模型：Point（要素）
   • 字段：owner
   • 比较：=
   • 筛选值：承包商 B
   • 权限：读取 ✓，编辑 ✓，创建 ✓，删除 ✓（全部为真 = 无法执行任何操作）
3. 将承包商 A 的用户添加为成员

结果：

• 承包商 A 成员无法查看任何 owner = "承包商 B" 的项目
• 不仅在 UI 中隐藏——API 返回数据时视同记录不存在
• 无法通过截图、API 调用或导出意外查看
• 完全由服务器端强制执行

其他使用场景

按工作阶段： 禁止现场工作人员查看质量控制验证报告：

角色："现场工作人员"
限制：
  模型：Validation
  字段：status
  比较：!=
  筛选值：""（任意值）
  权限：读取 ✓

现场工作人员完全无法查看验证报告。

按资产类型： 分设基础设施团队（电杆/管道 vs. 活动设备）：

角色："土木团队"
限制：
  模型：Point
  字段：category
  比较：=
  筛选值："Active Equipment"
  权限：读取 ✓，编辑 ✓，创建 ✓，删除 ✓

土木团队无法查看或修改活动设备点。

按物理/逻辑区分： 分离办公室数据访问权限（容量关系与办公地点）：

角色："容量分析师"
限制：
  模型：Point
  字段：layer
  比较：=
  筛选值："Office Locations"
  权限：编辑 ✓，创建 ✓，删除 ✓

分析师可查看办公室信息但不可修改位置（只读权限）。

管理员权限与角色限制的结合

默认行为： 所有用户均可查看所有内容，但无法修改任何内容（除非拥有管理员权限）。

添加受限写入权限：

示例： 现场工作人员可编辑自己的工作内容，但不可编辑他人内容

管理员权限：
  - reportsCreate: true
  - reportsUpdate: true

角色限制：
  模型：Report
  字段：reportedBy
  比较：!=
  筛选值：[当前用户 ID]
  权限：编辑 ✓

结果：

• 工作人员可创建报告（已授予管理员权限）
• 工作人员仅能编辑自己的报告（角色限制会过滤其他报告）
• 无法查看或修改其他工作人员的报告

服务器端强制执行

工作原理：

• 所有 API 查询在数据库检索前均经过过滤
• 角色限制在服务器端执行（不仅限于 UI 隐藏）
• 用户无法通过直接 API 调用、浏览器工具或导出功能绕过限制
• 未授权用户面前数据真实不存在

安全影响：

• 截取他人屏幕截图无效（数据不会为您加载）
• 无法导出受限数据（服务器强制执行过滤规则）
• 无法"猜测"记录 ID（ID 查询前已过滤）
• 权限范围之外的记录即使知道 ID 也会返回"未找到"

管理角色

创建角色：

1. 导航至管理 → 角色
2. 点击"创建角色"
3. 输入角色名称和描述
4. 添加成员（将用户拖入成员字段）
5. 添加角色限制（可设置多个）
6. 保存

编辑角色：

• 仅限角色所有者或拥有 rolesUpdate 管理权限的用户
• 可添加/移除成员
• 可修改限制条件
• 可删除角色（解除成员限制）

角色成员资格：

• 用户可同时拥有多个角色（限制叠加）
• 离开组织时：删除账户前先从所有角色中移除
• 批量成员管理：可同时拖拽多个用户

为新用户自定义授权

应用程序设置配置（需 appSettingSchemasModify 权限）：

1. 导航至应用程序设置 → 身份验证
2. "新用户角色" — 自动为新账户分配角色
3. "新用户管理员权限" — 授予默认权限
4. 保存

典型配置：

现场工作人员默认设置：

角色：["现场工作人员"]
管理员权限：{
  reportsCreate: true,
  assignmentsRead: true
}

办公室协调员默认设置：

角色：[]
管理员权限：{
  assignmentsCreate: true,
  ordersCreate: true,
  stockItemsView: true
}

不自动授予（人工审核）：

角色：[]
管理员权限：{}（无）

管理员在账户审核后手动分配。

查看有效权限

针对特定用户：

1. 导航至用户个人资料
2. "管理员权限"部分 — 用户可执行的操作
3. "角色"部分 — 用户不能查看的内容（通过限制实现）
4. 组合视图显示实际生效的权限

测试权限：

1. 以用户身份登录（或使用管理员权限模拟登录）
2. 正常浏览页面
3. 受限数据直接不显示
4. 无管理员权限的操作被禁用/隐藏

最佳实践

从限制开始，按需授予：

• 新用户仅获得最低权限
• 根据角色需求逐步添加管理员权限
• 授予权限比撤销更容易（避免权限膨胀）

使用角色控制数据可见性：

• 分隔承包商（防止竞争情报泄露）
• 分隔工作阶段（质量控制与现场工作人员）
• 分隔资产类型（基础设施与活动设备）

使用管理员权限管理功能：

• 谁可以创建分配
• 谁可以修改库存
• 谁可以授予权限

记录角色用途：

• 角色名称清晰（"承包商 A"优于"角色 1"）
• 描述说明限制条件
• 帮助未来管理员理解意图

定期权限审核：

• 每季度审查用户管理员权限
• 移除未使用的权限（用户角色变更）
• 检查角色成员资格（用户已离开组织）

监控访问尝试：

• 记录失败的授权尝试
• 拒绝模式表明用户尝试未经授权的访问
• 调查并调整权限或对用户进行培训

最小权限原则：

• 仅授予工作职能所需的最低权限
• 项目临时提升访问权限（结束后撤销）
• 超级权限（adminRightsModify）仅授予可信管理员