本篇以笔者做过的一个复杂项目为例，讲讲进行权限管理的实战总结。

一、项目背景

本次项目是为某研究院搭建一套信息化系统，包括统一用户管理平台、CSS系统、CRM系统、两套LIMS系统。

其中统一用户管理平台由客户IT部门管理，决定哪个用户能够登录哪个系统。

CRM系统由内部管理人员、商务、内勤、办公室、财务等人员使用，用于客户管理和内部管理，需要实现很多跨部门协同的功能，而且是以上各系统中使用人员和范围最广的一个系统。

以下分析均以CRM系统为例：

二、权限管理实战

在具体项目中，我们按照的顺序，去实现合适的权限管理。

1. 梳理组织架构

对客户实际组织架构和业务情况进行了解梳理，总结如下：

• 其中财务部归总部管理，财务部管理所有下属子公司和业务部门的费用、风险控制。子公司一为独立法人公司，但部分员工、资产和资质仍归属总部。
• 子公司一签署的合同主体既有独立法人公司的，又有总部的。但子公司一的员工、资产和资质将逐渐从总部剥离。
• 子公司二为独立法人公司，签署的合同主体、授信均为本公司。
• 业务一部归总部管理，签署的合同主体、授信均为总部。
• 子公司一、子公司二、业务一部的业务数据要进行隔离。

2. 确定权限管理设计框架

通过对组织机构的梳理，并通过用户访谈对业务进行了深入的理解，我们总结出：

• 该系统需要对各子公司和业务部门的客户数据和业务数据进行隔离；
• 各子公司和业务部门均有销售经理、办公室经理、商务、内勤、办公室几个角色，而且通过了解，同角色的人员所负责的事项都是相同的；
• 有一些特殊的权限管理需求：例如商务、内勤只具有本人的业务单据权限，但可以查看操作所属法人公司的到账、授信、客户余额等数据。

可以看出，传统的权限管理模型显然不能满足该系统的权限管理需要。如果使用传统的RBAC模型，也存在多个角色重复创建、无法管理数据权限的问题。

因此，我们确定在CRM系统上，应该使用基于RBAC的扩展模型。通过岗位管理用户在系统中的功能权限和数据权限，以满足客户需求。

3. 开展具体的产品设计

（1）用户管理

1）用户列表、查询

用户列表页展示用户名（即用户在系统中的账号名）、姓名（用户实际姓名）、电话、邮箱、状态、部门、岗位等有价值的信息。

同时具备编辑、启用、分配岗位功能。

2）用户新增、编辑、删除

本项目中，用户的新增、删除均通过统一用户管理平台进行，并分配系统级权限。

各系统中自行编辑、分配权限。

用户的字段包括登录邮箱、手机号码、姓名、用户名、部门、性别等字段，其中姓名和部门为必填项。

3）禁用

如果出现用户离职的情况，可以将用户禁用，不可登录系统，防止业务数据流失。

4）分配岗位

可以为用户分配相应的岗位，用户与岗位的关系是一对多。

（2）组织机构管理

1）组织机构列表、查询

左侧为组织机构，可以编辑组织的层级关系。

右侧为该组织机构下的岗位列表，可以对岗位进行查看、编辑、删除、分配角色和数据权限、分配用户的操作。

2）新增、编辑部门

点击组织机构右侧的“+”按钮，可新增子部门。

填写部门编码、部门名称、部门类型、公司类型。默认新增部门为所选部门的子部门。

其中，公司类型是这个项目的特殊需求，与客户业务相关，正常权限管理一般不需要这个字段。

3）删除部门

点击部门右侧的“删除”图标，可以删除该组织节点。

（3）角色管理

1）角色列表

左侧为角色列表，右侧为角色对应的功能权限。功能权限可以根据客户需求，可以细致到按钮级，也可以只管理到页面级别。

2）角色新建

点击“新建角色”按钮，输入角色编码、名称和备注。

其中，如果有特殊的权限需求，一般要与角色编码挂钩，这种情况下角色编码需要与技术团队约定规则，不可随意变更。

3）分配功能权限

点击左侧的角色名称，可以在右侧列出的功能列表中，对该角色分配相应的功能权限。

（4）岗位管理

1）岗位列表

在岗位列表页可查看岗位名称、岗位编码和部门。并可对岗位进行查看、删除、编辑、分配角色和数据权限、分配用户的操作。

2）新建岗位

点击左侧的组织机构，即可创建该组织节点下的岗位，部门默认为左侧所选的组织节点。

填写岗位名称、岗位编码、选择部门。岗位编码同角色编码，若有特殊权限需求，要与开发制定相应的规则，不可随意变更。

3）岗位详情

点击“查看”按钮，可以查看岗位详细信息和具有该岗位的人员列表。

4）分配角色和数据权限

为岗位分配其角色和数据权限。

岗位和角色之间是多对多的关系，一个岗位可以具有多种角色，一种角色也可被赋予多个岗位。

数据权限本次项目上做的非常冗余、用户体验极差，给每个角色又配置了相同的名称和数据权限，即“职能”，系统管理员还不能编辑岗位职能。（我也不知道当时产品和开发咋想的哈哈哈）

通常来说，应当直接分配数据权限：本人、本部门、本部门及下级部门，简单明了。

另外，若组织机构比较复杂，可以加上“法人公司”的数据权限，往上追溯离用户最近的法人公司。用户即具备法人公司下的业务数据权限。

5）分配用户

点击“分配用户”按钮，可将岗位分配给用户。用户与岗位是多对多的关系。

4. 梳理角色权限表单

通过组织机构分析和产品设计，我们已经抽象出可以使用CRM系统的角色。

这时就需要产品经理梳理角色权限表单，目的有二：

• 测试阶段需要初步验证业务流程是否可以正常进行；
• B端客户对系统一般不太熟悉和了解，让用户梳理角色权限是不太可能的。因此在上线前我们往往会初始化角色权限，用户只需要在后续使用中进行调整即可。

角色权限表单可参考下图：

5. 梳理数据权限

对各岗位的数据权限进行梳理，若存在无法通过系统配置的特殊权限需求，需要与开发沟通，通过代码写死或者约定一定的规则，用角色编码或岗位编码实现。

例如：本项目上，商务人员、内勤人员的客户和委托单数据权限为本人，但是对于循环授信、到账公告和客户余额，他们又需要查看和使用其所属法人公司的数据。

6. 系统上线、试运行

系统上线时，需要对角色权限进行初始化配置，并通过用户培训和配置文档将配置规则教给客户。

上线试运行期间，可以由运维人员协助客户对实际业务的新情况调整权限配置，在过程中让客户IT人员逐渐熟悉权限配置规则。

在使用过程中，客户也必然会提出一些新的特殊权限的需求，这时候需要产品进行评估，根据对现有权限框架的影响决定是否变更。

最后，权限管理体系下的用户登录有两种方式：

PS：对于特殊权限，大家有何高见欢迎评论指教，感谢！