情况

许多组织运行着共享平台，多个参与方在这些平台上共同处理同一套资产数据。例如，一家公用事业公司内部的工作团队、一家总承包商以及两三家分包商都连接在同一个网络上；一个市政部门则由其自有员工和外部工程公司组成。这些彼此竞争的参与方，往往最终要在同一个应用程序中协同工作。

每个用户都需要一个登录名。登录名向系统表明其身份。此外，还需要明确第二点：每个人被允许查看的内容。

分离需要什么

在共享平台上进行分离需要具备四个特性。

**一个共享平台。**各方就大部分数据开展协作，基于这些数据编制报告，并在同一张地图上进行工作。仅对敏感部分进行隔离处理。

**源头管控。**受限记录保留在服务器上。浏览器、API 以及所有导出内容仅显示用户有权查看的内容。

规则集中管理。 只需设定一次规则，即可涵盖所有数据读取方式，包括后续添加的功能。

面向所有人的实时数据。 各方均基于实时记录开展工作。

Aptli 通过两层架构满足了这四点要求。

我们的方法将授权分为两个相互独立的层，它们共同构成系统。

管理员权限具有开放性。 这些权限规定了用户可以执行哪些操作：创建工单、编辑报告、删除库存项目。没有管理员权限的用户只能查看其角色允许查看的数据。

**角色限制具有约束性。**每条限制都指定了一种记录类型（要素、工作单、报告）、该记录上的一个字段（标签、状态、类别）、一个比较条件以及一个值。该角色的成员将被禁止对匹配的记录执行选定的操作（创建、读取、编辑、删除），且每条限制都以简明易懂的句子形式呈现。

这两层是独立运行的。一名现场工作人员可以拥有编辑报告的权限，而角色限制则会隐藏其他人的报告。管理员权限授予该能力，角色限制则缩小其适用范围。这种独立性确保了随着产品的发展，该模型依然稳健。

Aptli 在数据离开数据库之前，会在服务器端应用角色限制：

系统对每个请求都会回答一个问题：该记录是否符合规则？

同一光纤建设项目中有两家承包商。两家都使用同一张地图和相同的共享底图，并分别针对各自的工作生成日志报告。每家承包商的要素都带有其专属标签：contractor-a 或 contractor-b。

创建一个名为承包商 A的角色，并设置一项限制：

“角色”窗口将其读作一句完整语句：“承包商 A”角色的成员可以执行所有操作，但无法创建、读取、编辑和删除标签为 contractor-b 的特征记录。 将该角色分配给承包商 A 的员工，并为 承包商 B 配置镜像，使用 contractor-a。这就是全部配置。

承包商A的施工团队现在可以看到自己的要素以及共享图层。要素列表中排除了承包商B的要素，CSV导出文件经过了筛选，而粘贴的ID会返回404未找到错误。承包商B看到的则是完全相反的情况。双方都能看到各自的工作内容、位置以及变更时间。

共享的基础设施（电缆线路、电线杆、管道基础设施）既不标有任何标签，也始终对双方可见。各方在需要时进行合作，在必须时保持独立。

两个之间没有任何共同点、从未合作过、且因监管原因必须部署在物理上相互独立的基础设施上的各方，将各自运行独立的实例。Aptli 为每位客户运行一个实例和一个数据库，且每一方都可以拥有自己的实例和数据库。

测试方法很简单：那些使用相同基础层、相同报告和相同地图的各方应位于同一个平台上，并在服务器端强制实施隔离。