企业级权限的主干应是用户组加功能权限：先按职能建组、再在组上配功能权限，TAPD 式把成员管理与组权限分离，管理员才说得清每项权限来自哪里；属性与对象关系，只给少数需收窄的权限加条件。

做内部项目管理平台时，权限最容易走偏的地方，不是少设计了一种模型，而是一上来就从复杂模型讲起。管理员真正面对的问题通常很朴素：测试人员应该能创建、编辑和流转缺陷，但要不要允许删除缺陷？能不能导出全部缺陷？他是否可以修改一条与自己无关的缺陷？

如果这些问题还没回答清楚，先讨论 ABAC、ReBAC 或策略引擎，只会让权限看起来专业，却没人知道后台该怎么配置。

企业级权限的主干，应该是“用户组 + 功能权限”；属性和对象关系，只给少数需要收窄范围的权限增加条件。

01 先按职能建立用户组，不要直接给每个人分配权限

用户组首先是一组承担相近职能的成员，也是系统分配权限的单位。空间管理员、产品组、研发组、测试组和外部协作组，分别对应团队中相对稳定的职能，而不是某一个人的职位名称。功能权限配置在用户组上，成员加入组后才获得这组权限。

用户组不必和组织部门一一对应。一个后端工程师既可以属于研发组，也可以临时加入发布值班组；同一个人在两个空间中也可以加入不同用户组。组织架构回答“这个人属于哪个部门”，用户组回答“他在这个空间承担什么职能”。

参考 TAPD 的配置方式，一个可用的权限后台至少要把两件事分开：成员管理 决定谁进入这个用户组，用户组权限 决定这个组可以使用哪些功能。TAPD 的公开资料还显示，用户组权限可以复制到其他用户组或空间，这种“复制后再调整”通常比设计复杂的角色继承更容易理解。

直接给个人授权只适合临时例外。如果大量日常权限都落到个人，人员转岗时很难知道应该回收什么，管理员也无法回答某项权限究竟来自哪里。

02 功能权限要按业务模块和动作拆开

建立用户组之后，第二步才是给它配置功能权限。这里的“功能”不是菜单能不能看见，而是用户能否对业务对象执行一个明确动作。

权限目录可以按两层组织。第一层是需求、缺陷、任务、迭代、测试、报表和空间设置等业务模块；第二层是每个模块下相对稳定的动作。

像截图中的 TAPD 权限页，会在“缺陷”下面继续区分创建、编辑、删除、导入、导出、合并、批量流转、附件上传和附件删除，在“需求”和“迭代”下再提供各自的动作集合。这样的设计比“查看、编辑、管理”三个大开关更长，却让权限和真实业务风险对得上。

但权限点也不能细到每个按钮一个开关。一个稳定的动作应该对应一条业务命令：无论用户从详情页、列表还是看板触发“编辑缺陷”，都使用同一个权限点；“关闭缺陷”则单独作为流转权限，因为它还会检查状态和必填信息。

还有一个容易混淆的地方：菜单权限不等于功能权限。隐藏“缺陷”菜单只能减少入口，用户仍可能通过链接、搜索或 API 访问缺陷。真正的权限必须作用在查看、编辑、删除和导出等业务动作上。

03 大多数权限用用户组解决，少数权限再增加 ABAC 或 ReBAC

用户组和功能权限构成基于角色的访问控制，也就是 RBAC。它应该承担权限体系的大部分工作：测试组能创建缺陷，研发组能处理缺陷，产品组能规划需求，空间管理员能修改配置。

真正需要 ABAC、ReBAC 的，通常是“这个权限已经授予，但只允许作用于哪些数据、在什么条件下生效”。

ABAC（基于属性的访问控制） 使用人员、对象或环境属性增加条件。例如：外部账号不能导出；缺陷归档后不能编辑；敏感级别为高的数据不能通过开放 API 读取。

ReBAC（基于关系的访问控制） 根据用户与对象的关系限定范围。例如：只能编辑自己创建或当前负责的缺陷；只有当前验证负责人可以执行“验证通过”；保密需求只对允许名单、指定用户组和参与人可见。

以“编辑缺陷”为例，后台可以先给测试组勾选编辑权限，再提供一个“适用范围”设置：

测试组拥有“编辑缺陷”权限
并且，当前用户是创建人或处理人
并且，缺陷状态不是已归档

第一行是 RBAC，第二行是 ReBAC，第三行是 ABAC。对普通管理员，页面不必直接展示三个缩写，只要提供“允许哪些用户组”“作用于哪些对象”“满足哪些条件”即可。

这里需要做一个明确取舍：不要让每项权限都支持任意条件表达式。创建、查看普通需求这类高频权限，用用户组勾选就够了；字段编辑、状态流转、保密数据和批量导出等风险较高、范围容易变化的权限，再开放条件设置。否则管理员最终面对的不是权限后台，而是一套没人敢改的规则编程语言。

04 多个用户组先合并功能权限，条件规则再收窄范围

一个人可以同时加入多个用户组，因此系统必须规定有效权限怎样计算。最容易理解的一种方式是：同一空间内，多个用户组的基础功能权限取并集；用户要执行某个动作时，再检查空间范围、数据可见性和该权限附带的条件。

有效权限 = 空间成员资格
AND 用户组已经授予该功能
AND 对象在可见范围内
AND 该功能附带的属性、关系条件成立

例如某人同时属于研发组和测试组，他可以同时获得“处理缺陷”和“验证缺陷”两组基础权限。但如果“验证通过”要求当前用户是验证负责人，那么他不能验证一条与自己无关的缺陷。用户组决定他有没有这类能力，对象关系决定这次能不能使用。

对于保密需求，空间成员和用户组权限都不能直接绕过保密范围。TAPD 的公开接口资料显示，保密需求可以使用人员或用户组白名单，也可以把参与人动态纳入可见范围。从产品模型看，这就是在基础功能权限之上，再按具体对象关系收窄数据范围。

第一版不建议引入复杂的“显式拒绝覆盖所有允许”或多层角色继承。多数研发团队先规定三条语义就够了：未授予就拒绝；多个用户组的功能权限取并集；保密范围和权限条件继续收窄。等确实出现跨组织强制限制，再增加更高优先级规则。

05 页面、看板、批量操作和 API 必须执行同一项权限

权限后台勾选得再清楚，如果只有页面按钮遵守，也没有意义。

“编辑缺陷”应该是一项稳定的业务权限。详情页保存、列表行内编辑、看板拖拽、批量操作、开放 API、自动化和 Agent Tool，无论从哪个入口发起，都要在服务端检查同一个权限点及其条件。前端隐藏按钮只是减少误操作，不能构成安全边界。

权限失败和业务校验失败也必须分开。测试组没有“关闭缺陷”权限，应该提示需要加入相应用户组或申请权限；用户拥有关闭权限，但验证结果还没填写，应该提示补齐验证信息。前者回答“你能不能做”，后者回答“这条缺陷现在能不能这样变化”。

为了让界面可理解，服务端最好返回当前对象的可用动作、不可用原因和恢复方式。用户看到的不应只有“无权限”，而应是“测试组没有删除缺陷权限”或“你不是当前验证负责人”。

06 用户组权限只是入口，还要区分数据、字段和流转权限

测试组被授予“编辑缺陷”，只说明它拥有这类功能，并不意味着组内成员可以修改全部缺陷、全部字段和任意状态。

• 对象查看 决定用户可以看到哪些缺陷。普通缺陷可以对空间成员开放，保密缺陷则继续按允许名单、用户组或参与关系收窄。
• 字段可见 决定看见对象后还能看到哪些事实。外部测试可以看到缺陷编号和状态，但客户名称、成本或安全细节仍然隐藏。
• 字段编辑 决定哪些值可以修改。测试人员能填写验证结果，不代表可以改需求优先级；能登记自己的工时，也不代表可以修改别人的工时。
• 步骤执行 决定能否沿合法路径推进状态。执行“验证通过”通常要求当前用户拥有流转权限，并满足当前验证负责人、待验证状态等条件；验证结果是否填写完整，则属于业务校验。

因此，一个完整的判断顺序是：先看用户组有没有这项功能，再看对象是否在数据范围内，最后判断字段或流转步骤的附加条件。不能把这几层压缩成一个“编辑”开关。

07 单对象能判断正确，还不代表列表、搜索和报表安全

很多系统把单条详情页保护得很好，却在列表查询上泄露数据。用户无权查看需求 B，不只意味着打不开详情页，也意味着搜索联想、列表总数、分组统计、关系图、通知和导出都要执行同样的数据范围。

安全查询不能先查出全部数据，再在页面上隐藏几行。权限条件要尽可能进入查询计划；搜索、报表和导出只返回当前用户可见的数据。即使底层索引更新较慢，结果返回前也要按当前权限再次裁剪。

跨空间关系还要分别判断关系两端。公开需求 A 依赖保密需求 B 时，可以完整展示 B、只提示“存在一个受限工作项”，也可以隐藏关系本身。选择哪种方案取决于保密要求与排期解释之间的取舍，但不能默认把 B 的标题带出来。

08 授权不仅要能授予，还要能真正撤销

企业权限不是一张配置后永远不变的表。成员加入、转岗、离职以及临时协作，都会改变用户组成员和有效权限。

临时授权至少要明确用户组、资源范围、动作和到期时间，到期后自动失效。人员转岗不能只加入新用户组，还要退出旧用户组；离职还需要让会话、API Token、权限缓存和机器委托在规定时间内失效。

管理员把成员移出测试组，只是修改了权限来源。详情页、列表、搜索、报表和 API 都不再允许访问，才算撤权真正完成。已经下载到本地的文件无法收回，所以导出权限必须单独控制，不能混在普通查看权限里。

09 主流产品的差异，来自授权粒度与组合方式

TAPD 最适合说明“用户组 + 功能权限”这条主线。管理员先选择用户组，再按需求、缺陷、迭代等模块配置创建、编辑、删除、导入、导出、流转和附件等操作。它还支持复制用户组权限，减少重复配置；到了保密需求、字段可编辑规则和工作流授权，再引入名单、参与人、字段条件或授权用户。从产品模型看，就是先用 RBAC 完成主配置，再对少数权限增加属性与关系条件。

Jira 围绕全局权限、空间权限方案、空间角色和工作项安全级别组织授权，擅长复用权限方案，并把编辑、分配、迁移和关闭等动作拆开。ONES 强调项目、组件、工作项和操作路径上的多层权限，权限点覆盖状态更新、关联、工时和导出。飞书项目则把用户组、数据与字段权限、创建人、节点角色和业务角色结合起来，更适合运行关系频繁变化的流程型协作。

公开资料可以说明这些产品暴露了哪些权限对象和配置入口，却不能证明它们内部使用相同的策略引擎。本文的模型是从企业授权问题反推的产品架构，不是对任何产品内部实现的猜测。

10 一个完整例子：测试组如何管理缺陷

下面用一个简化配置把整套模型串起来。某空间建立“测试组”，基础功能权限如下：

管理员只对“编辑缺陷”和“验证通过”增加条件：编辑缺陷时，当前用户必须是创建人或处理人，且缺陷不能处于已归档状态；执行“验证通过”时，当前用户必须是验证负责人，缺陷必须处于待验证状态。

测试人员陈测试进入空间后，系统会得到五个不同结果：

如果陈测试已经满足流转权限，但没有填写验证结果，系统仍然不能完成流转。不过这次不是权限失败，而是业务校验失败。正确提示应该是“请先填写验证结果”，而不是“你没有权限”。

这个例子里，用户组解决了团队大部分稳定分工；功能权限明确了测试组能使用哪些能力；ReBAC 把编辑和验证限制在自己参与的缺陷；ABAC 又按状态继续收窄。普通管理员看到的是一套清楚的配置顺序，底层才需要把这些规则组合成一次判断。

权限体系做到这里，主线其实已经很清楚：先用用户组管理职能，再按业务模块分配功能权限，只对少数高风险或强上下文动作增加条件。 如果一项普通权限也必须写复杂规则才能生效，问题往往不是企业业务太复杂，而是权限目录没有先设计好。

下一篇，我们进入权限边界之内的机器执行：当负责人变化、状态推进或时间到期后，系统怎样把确定规则转化为可靠动作，又怎样避免重复执行、规则循环和级联事故。