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，这也是最大的原因；权限列表之选择配置文件储存，我猜想 是因为权限是系统内置，并且是固定的，改动频率较低，所以没有必要每次都要再交互一次数据库，不仅是功能权限如此，下面谈到的数据权限亦是如此。
系统的权限列表
配置的数据结构大致如下(以下只是说明结构，并非实际数据)：
一级节点的key代表的是应用模块，二级节点的key代表权限点，value为权限的描述，详细如下：
角色与权限的关联配置
在Worktile中只需要一张角色表足矣！结构如下(关键字段): id,name,privileges,is_system，其中核心字段是privileges，该字段记录的是权限项，是一个json，详细如右下图。
privileges中一级节点是应用模块，value是角色拥有的权限值，该值是以 0 和 1 组成的字符串组成，其中 1代表拥有，0代表未拥有，每个字符排列的位置是由配置文件中的storage_position 字段；scope是可见范围。
使用
下面基于上述实现对以下三种常见场景的使用：
获取角色下所有的权限列表 以及 拥有状态(后台管理)
获取一个成员的所有权限(登录后前端需要储存的用户权限)
校验一个企业成员是否拥有某个权限(API请求对成员的鉴权)
ps: 只举例一种，剩下两种类似。
三、数据权限
看完前面 功能权限的实现 大家应该觉得非常的简单，如果下面还抱着这种心态，那可就真是小看它了，在此 我也希望大家 能够在下面仔细阅读，体会其中的设计，文章较长，有不明白或需要讨论的欢迎评论留言。
在数据权限的设计中，各行各业大多不尽相同，这是由业务来决定的，Worktile的业务就非常的复杂，所以 权限也随之复杂，Worktile中应用模块很多，由于篇幅原因不会在文中全部讲解，只挑一些典型给大家分享一下。
我这里以Worktile 核心模块 mission(项目、任务) 来讲解分析，mission是非常值得一说的，精彩在于能够允许用户 高度自定义配置，模块下的角色和权限都是可配置的(这里说明一下非上述系统角色和权限)。
由于业务的复杂，不得不在这里给大家从一些界面截图进行演示，有疑惑的地方欢迎提出。
项目(Project)
概览
项目是任务的集合，项目分解出多个任务，项目中有组件(以不同维度 对 任务 的展示和管理)
项目权限的分为可操作权限和可见权限。
可操作的权限
对应的页面
可见权限
规则为：公开项目所有成员可见，私有项目只有已加入的成员可见。
可见范围
私有项目已加入的成员
到现在大家应该对项目和项目中的权限有了大体概念和认
设计
项目权限的设计中有角色模式、项目角色、权限三部分，这三者关系大致为：
配置方面，有全局配置和项目内配置，全局配置的维度是全部的项目，项目设置是全局配置的延伸，对单个项目的配置，项目的配置来源于全局配置。
角色模式 角色模式可以理解为角色组，在项目中必须拥有一种角色模式，由系统默认角色模式和用户自定义创建 两部分组成(见下图)。
全局配置
项目中配置(这里只能选择全局配置好的角色模式)
项目角色项目角色有系统内置角色(管理员、普通成员、只读成员) 和用户自定义角色(见下图)。
全局配置
项目中配置
项目权限在概览中，已经介绍权限列表了，下面只展示配置和关联。
全局配置(角色关联权限)
项目中配置
从上面的设计中可以看出，其实这块的权限还算简单，下面从技术角度讲解一下具体的实现。
项目权限的实现是由三张表和一个配置完成的，分别是项目表(Project)、角色模式(RoleMode)、角色(Role) 和 权限列表的配置文件(PrivilegeConfig)。
关系：
一个项目可以配置多个角色模式，一对多，绑定字段在主表(Project) 的role_modes。
每个角色模式可以创建多个角色，一对多，绑定字段在 从表(Role) 的 role_mode_id。
每种角色可以配置多个权限，关系是一对多，只不过这里的权限字段(permission_value) 是由 0 和 1组成的 字符串，其中 0 代表 未拥有，1 代表 拥有。
项目的可见权限是通过项目两个字段来控制的，一个是visibility(公开/私有)，另一个是 members(项目成员)，当项目是公开的，所有成员可见，当项目是私有的，只有成员列表存在的才可见。使用：
如何获取权限列表？服务端读取系统配置文件，返回给前端，前端再映射对应位置展示即可。
如何获取角色对应的权限列表？服务端读取角色表找到对应 权限值(由 0 和 1 组成的字符串)，然后根据系统配置进行排序，返回给前端，前端通过 0 1 值排列和勾选。
如何验证成员的权限？1. 可见权限，首先判断visibility是公开还是私有，如果是公开项目所有成员可见，如果是私有其次判断 当前成员是否存在于项目成员2. 如果验证的是操作权限，从项目表(Project)读取该成员的 id 和角色，再根据角色找到权限值(由0和1组成的字符串)，最后根据系统配置文件对应权限的位置映射权限值的具体单个值，如果是 1 那么就拥有此权限，反之未拥有！
任务(Task）
概览
任务是工作内容的具体表现形式，任务可以对工作内容描述，流程控制，任务和任务之间的关联和派生。
ps：任务可以单独存在，也可以存在于项目中。
下面是实际场景中的使用
设计
任务的权限和项目的权限从设计上就有很大的不同，任务的权限 是由权限主导的，模型见下图。
其中涉及角色模式、角色、权限模式、权限、安全级别模式、安全级别等概念， 安全模式和安全级别等同于 可见权限。
而其中与项目共同的部分是 角色模式。不同之处是任务角色是由项目角色和任务角色( 任务负责人,参与人等) 组成，而主要设计方式是通过 配置任务类型权限来控制任务的权限，换一种说法讲给任务配置权限，不如说给任务类型 配置权限，这两者是可以划等号的。
什么是任务类型？
见名知意，就是任务的所属类型，之所以 Worktile 适用于大多数企业的原因也是核心就是任务类型，同时也支持企业成员创建和自定义。
实际中使用的任务类型
注：任务 有且只能 拥有一个 任务类型
可操作权限
权限模式权限模式是多个权限的集合，也可理解为权限组，由系统内置权限模式(通用权限模式、软件权限模式等) 和用户自定义权限模式(见下图)。
全局配置
项目中任务类型的权限配置
权限模式 与 角色模式
权限模式、角色模式与角色的关联
权限模式、角色与权限的 关联
权限
系统内置权限：系统定义不可更改的属性权限，比如创建任务，归档任务，拷贝任务......等
任务属性权限：任务的属性是支持用户配置的，所以属性拥有 属性权限，比如修改负责人，修改任务状态......
可见权限
任务中的可见权限，称为“安全级别”。由安全模式和安全级别两部分完成。
安全模式(系统内置安全模式和自定义安全模式)
安全模式与角色模式安全模式与角色模式的绑定，表示该安全模式下哪些角色模式的角色可见。
安全模式与安全级别
安全级别与角色表示哪些角色(包括 项目角色和任务角色)可见
项目中任务类型与安全级别的配置
实现
任务的权限涉及9张表，3个配置文件。
表及关系：
Task任务表、TaskType 任务类型表，一对一的关系，关联字段在主表Task的task_type_id。
PermissionMode: 权限模式表，与任务类型是多对一的关系，一个任务类型有多种权限模式。
TaskPermission：任务权限字典表，是通过系统配置文件(system task permissions) 初始化到该表中的，与权限模式 的关系是多对一，一个权限模式对应多个权限项，关联字段 selectable_permission，注意该字段是同步到 权限模式下，后续供角色来选择。
RoleMode: 角色模式表，与权限模式是一对一的关系，一个权限模式绑定一个角色模式。
Role: 角色表，与角色模式表是多对一的关系。
PermissionRole: 权限角色表，与权限模式是多对多的关系，该表的权限必须是从权限模式下的权限项 中选择，角色必须是该权限模式下绑定的角色模式下的角色中选择。
SecurityMode: 安全模式表，配置的是任务的可见权限，是从系统配置文件初始化到数据库中，与角色模式是一对一的关系，一个安全模式绑定一个角色模式。
Security: 安全级别表，配置的是任务角色(含任务内置角色和默认角色模式下的角色)的可见权限，也是 从系统配置文件初始化到数据库中的，与任务角色是一对一的关系，与安全模式是多对一的关系，一个安全模式下可以配置多个角色。
使用逻辑：
检查一个成员拥有任务的操作权限
检查一个成员是否对一条任务有可见权限
四、总结
文中所讲权限整体是按照RBAC模型设计
权限列表均采取 配置文件的方式储存，好处是轻量，减少连表复杂操作，较少的与数据库交互
文中 mission 模块的数据权限：
项目可操作权限是角色组 + 角色 + 权限
项目可见权限绑定是成员
任务的权限是权限组 + 权限 + 角色组+ 角色来控制任务属性
非常感谢能够认真阅读到这里的伙伴，如果文中有不明白或更好的意见欢迎交流，期待更多揭秘，还望持续关注 Worktile！
欢迎进入官Worktile