Permission 权限

Aras Innovator 提供了多层安全机制，从登录认证到数据级别的细粒度访问控制。权限通过 Permission 实体来定义，并结合 Identity 体系、Lifecycle 状态、Team 角色等机制实现动态的安全策略。

---

安全模型总览

两个核心概念：

• Authentication（认证）：验证用户身份（用户名 + 密码）
• Authorization（授权）：决定用户能对哪些数据做什么操作

---

Permission（权限包）

Permission 是一组访问规则的集合，通过 ItemType 的 Permissions 标签页分配给 ItemType。每个 ItemType 必须有一个默认权限包，新创建的记录自动继承该权限。

权限级别

权限	说明
Can Discover	允许在搜索网格中发现记录（看到行），但不能打开表单查看详细信息
Get	允许打开记录，查看完整的表单内容。拥有 Get 权限自动获得 Can Discover
Update	允许编辑记录
Delete	允许删除记录
Can Change Access	允许运行时切换当前记录的权限包（通过 ...More → Permissions 菜单）
Show Permission Warnings	当搜索结果中存在无权访问的记录时，显示权限警告图标

权限与 Identity 的组合

在 Permission 的 Access 标签页中，为每个 Identity 分别配置上述权限：

Permission: "Design Request"
  ├── Administrators:  Get ✓  Update ✓  Delete ✓  Can Change Access ✓
  ├── Engineering:     Get ✓  Update ✓  Delete ✗
  ├── All Employees:   Can Discover ✓  Get ✗
  └── Owner:           Get ✓  Update ✓  Delete ✓

root 用户绕过所有权限

除 Super User（root）外，所有用户（包括 Administrators 组成员）都受权限约束。root 仅在特殊维护场景下使用。

---

Can Discover 与 Get 的协同

这两个权限的组合决定了数据的可见性层级：

Can Discover	Get	搜索网格中的行为
✗	✗	记录不出现在搜索结果中，完全不可见
✓	✗	记录出现在搜索结果中，但仅显示非隐藏列的值，无法打开表单
✓ 或 ✗	✓	记录完全可见，可打开表单查看全部信息

要让 Can Discover 严格生效（不自动包含 Get），需要在 ItemType 上勾选 Enforce Discovery 选项。

---

Permission 的生效优先级

一条 Item 在任意时刻只有一个生效的权限包（存储在 permission_id 字段中）。权限的来源按优先级排序：

1. Lifecycle State Permission：如果当前 Lifecycle 状态配置了 State Permission，优先使用
2. Item 的 permission_id：运行时通过 Can Change Access 手动切换的权限
3. ItemType 的 Default Permission：ItemType 上标记为 Is Default 的权限包

如果 Lifecycle 状态没有配置 State Permission，则继续沿用上一个状态的权限。

---

私有权限（Private Permission）

私有权限是为单条记录创建的专属权限配置，不与其他记录共享。典型场景：临时授权审计人员访问某条特定记录。

启用条件（两个条件同时满足）：

1. ItemType 上勾选 Allow Private Permissions
2. 默认权限包中，相关 Identity 拥有 Can Change Access 权限

创建方式：

1. 打开目标 Item → ...More → Permissions → Create Private
2. 在弹出的权限编辑界面中，为各 Identity 配置访问级别
3. 保存后，该权限仅作用于当前这条记录

私有权限会随权限包切换而删除

如果后来通过 Can Change Access 将该记录切换回 ItemType 默认权限或其他权限包，Private Permission 会被删除。

---

Team 权限

Team 机制将 Identity 与运行时上下文结合，实现基于项目/产品的差异化权限：

配置流程：

1. 创建 Team 实例（如 "Mobile Products"），添加成员并分配 Team Role
2. 在 Permission 的 Access 标签页中，为 Team Role（如 Team Manager、Team Member）配置权限
3. 在 ItemType 的 Form 上放置 team_id 字段（Item 类型）
4. 用户创建记录时选择具体 Team，权限根据所选 Team 的成员角色动态生效

Permission: "Design Request"
  ├── Administrators:   Get ✓  Update ✓  Delete ✓
  ├── Team Manager:     Get ✓  Update ✓  Delete ✓
  └── Team Member:      Get ✓  Update ✓  Delete ✗

同一个用户在 "Mobile Products" Team 中可能是 Team Manager（拥有删除权），在 "Computing Products" Team 中可能是 Team Member（无删除权）。

---

Can Add 控制

Can Add 控制哪些 Identity 有权创建某个 ItemType 的新记录，配置位置在 ItemType 的 Can Add 关系标签页（或 TOC Editor 中），与 Permission 是独立的机制。

机制	控制内容
Can Add	是否能在系统中创建该 ItemType 的新记录
TOC Access	是否能在目录区（TOC）看到该 ItemType 的菜单入口
Permission	对已有记录的读写删改权限

三者相互独立，需要分别配置。

---

密码策略

参见 用户与身份 章节中的详细说明。密码策略通过 Identity 层级配置，支持密码有效期、历史记录、最小长度、锁定阈值等设置。