Worktile 权限设计

Worktile 是国内最优秀的企业级项目协作与目标管理工具之一，这个项目已经持续了 9 年之久，书写了研发团队的历史长卷，我作为“后来者”有幸地参与其中。在过去研发的一年里，做的事情大多数是对原有功能的增强和重构，也学习和总结了 一点点 Worktile 核心技术和知识，本文就是其中之一—— 权限系统。

Worktile的权限异常复杂，在开发中，从疑惑到深入，再到后来的望之止步，直至最终的克服，这其中多次与同事的交流，又多次的总结，逐渐地清晰，到现在对它进行了我认为比较全面的总结，下面就跟大家一起 揭秘(分享) 这块复杂而精彩的内容。

一、Worktile 帐户体系

首先总览一下 Worktile 的帐户体系。在此之前，先介绍一下该系统：它是多租户系统的一种，在我接触过的多租户系统中，有两种类型，一种是像企业微信，飞书，它们的租户类型有用户和团队/组织/企业，那么这类应用的帐户体系 就有两个用户概念，一个是系统用户，一个是团队成员；而另一种就是 Worktile，租户类型 是 企业/团队/组织的，它是不含个人租户，一切业务的基础条件是 团队(team) ，所以权限这块也是基于 团队成员来控制的。

目前比较主流的权限设计模型，一种是 ACL(Access Control List)，是主要是基于用户来控制权限，而另一种是 RBAC 模型（Role-Based Access Control ）基于角色的访问控制，而这两种在 Worktile 中都有涉及，在绝大部分是 RBAC 模型，少量的权限是基于用户设计和控制的。

上图中，可以看到 Worktile 权限是由功能权限和数据权限两部分组成，下面对这功能权限和数据权限两部分 具体讲解。

二、设计与实现

功能权限和数据权限都是基于应用的维度来划分的，Worktile 现有的应用有项目、任务、目标(OKR)、消息、日历、审批、网盘、考勤......

功能权限

设计

功能权限是完全按照 RBAC 模型 设计的，关系为：

由两部分组成：操作权限和可见权限，是按照应用模块的维度划分的，每个应用模块下分布多个权限点和可见范围。

 

给用户呈现的形式是在应用的后台—>角色管理中(见下图)，其中企业角色包含两部分： 1. 系统默认角色(所有者、管理员、成员、部门主管) 2.自定义角色，权限列表(下图右侧)中，打对勾的代表该角色已拥有的权限，数据范围 代表 该角色 在 应用内的可见维度。

可操作权限

 

可见权限

 

实现

在传统关系型数据库的设计，基本都是三张表：角色表，权限表，角色权限关联表，如果校验一个或一组权限，是需要三表关联查询的。

而在 Worktile 中则不然，采用的储存方式是：非关系型数据库 Mongodb + 系统配置文件， 由一张表来表现，权限列表由系统配置文件存储。

• Mongodb，天然支持数组和 JSON 类型的数据储存，在角色和权限的关联配置中更为灵活，这一环在此设计中，不可或缺！

• 配置文件主要存储的是权限列表，系统内置，前端也需要一份配置是因为列表展示位置匹配。

为何这么设计？

数据库是因为整个产品的主库就是 Mongodb，这也是最大的原因；权限列表之选择配