本篇以笔者做过的一个复杂项目为例，讲讲进行权限管理的实战总结。
一、项目背景
本次项目是为某研究院搭建一套信息化系统，包括统一用户管理平台、CSS系统、CRM系统、两套LIMS系统。
其中统一用户管理平台由客户IT部门管理，决定哪个用户能够登录哪个系统。
CRM系统由内部管理人员、商务、内勤、办公室、财务等人员使用，用于客户管理和内部管理，需要实现很多跨部门协同的功能，而且是以上各系统中使用人员和范围最广的一个系统。
以下分析均以CRM系统为例：
- 信息化基础：该研究院IT基础薄弱，目前只有GLP实验室管理系统。
- 组织架构：该研究院组织架构较为复杂，包括总部和子公司。部分人员交织在一起，而且组织机构还在不断调整中。
二、权限管理实战
在具体项目中，我们按照【梳理组织架构 – 确定权限管理设计框架 – 开展具体的产品设计 – 梳理角色权限和数据权限 – 初始化配置 – 根据客户需要进行调整】的顺序，去实现合适的权限管理。
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：对于特殊权限，大家有何高见欢迎评论指教，感谢！
