Aptli

谁能查看和修改什么

这是我们被问到最多的问题,因此值得在开头就明确说明。Aptli 的访问模型刻意设计得简单,并基于一个默认原则:

默认情况下,所有人都能查看所有内容——但并非所有人都能修改所有内容。 系统默认即开即用,可见性完全开放;而编辑权限则由您授予。随后,您只需在特定需要的地方收窄可见范围即可。

控制机制分为两个独立层级。它们层层叠加:用户对任何记录的最终访问权限,取决于这两个层级共同允许的范围。

   START: everyone can SEE everything
              │
              ▼
   ┌──────────────────────────────────────────────┐
   │ LAYER 1 — ADMIN RIGHTS                        │
   │ "What may this person CHANGE?"                │
   │ Granted per area, per action.                 │
   │ No right → can view, but not create/edit/delete
   └──────────────────────────────────────────────┘
              │
              ▼
   ┌──────────────────────────────────────────────┐
   │ LAYER 2 — ROLE RESTRICTIONS                   │
   │ "What may this person's role even SEE?"       │
   │ Hides matching records from the role —        │
   │ everywhere those records would appear.        │
   └──────────────────────────────────────────────┘
              │
              ▼
   RESULT: what this person can see and do

第 1 层 — 管理员权限(可修改的内容)

每个用户都拥有一组 管理员权限。每项权限都是针对某个区域内某项操作的单一开关 — 例如 jobsUpdatesitesDeleteresourcesCreate。 拥有该权限即可执行该操作;若无此权限则无法执行。

这种模式在整个系统中保持一致:大多数领域都包含创建更新删除权限。

   Jobs        →  jobsCreate · jobsUpdate · jobsDelete
   Sites       →  sitesCreate · sitesUpdate · sitesDelete
   Resources   →  resourcesCreate · resourcesUpdate · resourcesDelete
   Reports     →  reportsCreate · reportsUpdate · reportsDelete
   ... and so on for every area

如果没有权限,用户实际上处于只读状态:他们可以打开并查看应用程序中的记录,但无法使用创建/编辑/删除控件。您需要授予权限来扩大每个用户的操作范围。

少数权限不针对单一区域——它们解锁特定功能,例如 查看已删除 (viewDeleted)、协助取货审计视图。这些权限的运作方式相同:持有或未持有。

第二层 — 角色限制(可见内容)

第一层从不隐藏任何内容——它仅管理编辑权限。若要将内容从视图中移除,需使用角色

角色是一组命名用户,附带一组限制。每条限制都是一条规则,其实质是:“该角色的成员不应触碰符合此条件的记录。” 限制的主要作用是隐藏符合条件的记录——对于该角色而言,这些记录在任何地方都不会显示。

三个层级

对于任意给定的记录,用户最终会处于以下其中一个状态:

   ┌────────────────────────────────┬──────┬───────┐
   │                                │ SEE  │ EDIT  │
   ├────────────────────────────────┼──────┼───────┤
   │ Open                           │  ✓   │  ✓ *  │
   │ View-only                      │  ✓   │  ✗    │
   │ Hidden          (role-hidden)  │  ✗   │  ✗    │
   └────────────────────────────────┴──────┴───────┘

   * Editing requires the matching admin right from Layer 1.
  • 公开 — 可见,且任何拥有相关管理员权限的人均可编辑。
  • 仅查看 — 可见,但不可编辑。 这仅仅是当某人不具备编辑权限(第1层)时,其看到的任何记录的状态。由于默认可见且允许编辑,大多数人对于大多数内容都是只读的——这是正常状态,而非特殊的锁定措施。
  • 隐藏 — 某个角色将记录隐藏,因此该记录完全不会出现在该用户的列表或地图上。

由于角色规则关联的是符合特定条件的记录(而非整个页面),因此一个角色可能仅能查看工作、站点或要素的子集,而另一个角色则能查看同一集合中的不同子集。

适用于所有层级

通过角色隐藏记录并非某个界面的专属功能。 相同的视图规则在整个系统中统一适用——职位、工单、报告、资源、站点、库存、地图要素、用户、角色等,其列表均需经过当前用户的角色限制筛选。只要在某处为某个角色隐藏某类记录,该角色在任何查看位置都会被隐藏。

关于两层机制协同工作的说明。隐藏 由角色决定并适用于所有场景。编辑 由管理员权限决定——因此,让某组用户仅能查看而不作动的可靠方法是撤销其编辑权限。 (角色虽也可包含编辑/创建/删除规则,但请将管理员权限视为真正的编辑门槛。)

“所有人皆可查看一切”的例外情况

这种开放的默认设置有几个刻意设计的例外:

  • 已删除的记录会被隐藏,除非某人持有 查看已删除 权限 请求显示它们。软删除的项目仍可恢复,但不会显示在视图中。
  • 个人站点归其所有者所有。 员工的个人库存站点对他人可见,但只有其所有者才能编辑它——无论站点权限如何。
  • 孤立地图要素(其父图层已被删除)将保持隐藏,除非您明确查看已删除内容。

其余内容均遵循以下规则:默认可见,需授权方可修改,并在您认为有必要时通过角色权限进行限制。

这在管理区域中的体现

您可通过 管理 菜单管理这两个层级:

  • 用户 — 分配用户的管理权限(第 1 层)及其角色成员资格。
  • 角色 — 定义角色及其权限限制(第 2 层)。
  • 授予访问权限 — 添加新用户并进行配置。

如需了解完整的安全架构,请参阅 身份验证(用户如何证明身份)和 授权(如何深入配置权限和角色)。