在线上产品，用户能看到不同的内容，是因为具有对应的数据权限；能进行各种操作，是因为具有对应的功能权限。大部分c端产品的数据权限、操作权限对于用户都是放开的，如电商网站上所有商品的信息以及下单全流程操作，因而不需要考虑用户之间的权限差异。但是，对于b端产品而言，不同用户的数据权限、功能权限都可能存在差异，如在数据可视化软件，领导与下属能查看的报表很可能存在差异，管理员可以编辑、删除，而普通用户只能查看，因而需要为用户设置相应不同的权限。
系统的用户权限有两种极端情况，一是所有用户的权限都一样，如c端产品都放开，一是所有用户的权限都不一样。b端产品的用户权限，多数情况下，是介于这两者之间，即有些用户的权限是一样的，有些是不同的。那么具有相同权限的用户可归为一类角色，角色是一个包含很多权限的集合，这样相同权限的用户就不用一一去设置权限，只需要对应一个角色即可，从而在系统初始化时减少为用户设置权限的工作量，同时新增用户、用户的权限发生变化时，只需要设置角色、修改角色即可，而不需要遍历权限去勾选。
在一个新版本上线前，系统的功能全集是确定的，从一个功能模块，到里面的具体操作按钮，甚至细到一个表格的字段，都可以通过功能权限进行差异化设置。一个角色，如果勾选某个功能模块、某个具体操作、某个字段，那么该角色的用户进入系统后就能看到这个模块，在模块里面可以进行这个操作，在模块的表格中可以看到这个字段。显然，功能是分层级的，只有父级功能勾选了，下面的子级功能才可以选择。因此功能权限，需要按层级进行梳理，这也有利于后续新功能在功能树中找到准确的相对位置。当然，并不是系统中所有功能、每个字段都有进行权限控制，要根据业务实际情况，判断哪些模块、哪些操作、哪些字段在用户中存在差异，从而梳理出需要设置的功能权限树。
在界面上看到的数据，来自于数据库导入的、前端手动添加的、接口调用其他系统的，等等。从某种程度上说，数据与系统、与系统中的功能，是独立开来的。举个例子，很多b端系统都有用户管理模块，在导入数据之前，界面上可以看到用户信息表的表头包含哪些字段，表格之上有新增、批量删除等按钮，这就是在用户管理模块你拥有的功能权限，但是在表格里面你能看到哪些用户的信息，所在部门的，还是全公司用户的？这就是由数据权限控制。所以，原则上讲，数据权限与功能权限不能绑定在一起，需要分别设置。
数据权限的设置，情况远比功能权限复杂。在b端c端都有业务的平台，数据权限的控制要求比较简单，因而系统上数据权限的设置也比较简单，比如企业集采的商旅平台，公司内部规定只有T5职级以上的员工才能看到公务舱之上的舱位，那么只需要创建一个“T5以下”的角色，后台过滤公务舱之上的舱位，就能保证T5职级上下的用户看到的舱位存在差别。在纯b端，有些系统的数据权限设置就比较复杂，当然这还是业务需求决定的。比如，银行客户经理使用的CRM（客户关系管理系统），底层的客户经理管理各自的客户，他们彼此之间的客户数据是隔离的，那么上面领导的数据权限就要看其与哪些客户经理存在直系领导关系，是某个客户经理的直系领导，就能看到该客户经理的所有客户数据。这时，创建角色需要比较细致，角色会比较多，仅仅通过客户经理、客户主任、客户部副总经理等级别信息来区分还不够，角色名称还需要冠以具体组织信息，如一部客户主任、二部客户主任。这种情况接近于每个用户一种角色，那为什么不直接把用户与权限挂钩？因为用户在系统中的角色可能会发生变化，还会增加新的用户，只修改角色或设置角色比遍历所有数据权限进行选择，要简单得多。
在整体用户的功能权限划分与数据权限划分重合度很低的情况下，可以考虑分别设置功能角色、数据角色。还以刚才的CRM为例，仅从功能权限划分，假设只需要设置5种角色，而从数据权限划分，假设要设置25种角色。如果功能权限、数据权限统一包含在一个角色中，数据权限相同的用户，功能权限也都相同，这是最理想的情况，总共需要25个角色，而极端情况下总共需要125个角色。那么在角色设置过程中，数据权限、功能权限各需遍历选择了25-125次；而如果分别创建25个数据角色、5个功能角色，那么在角色设置过程中，数据权限只要遍历选择25次，功能权限只要遍历选择5次，并且两者独立，如果有变动修改范围小，当然每个用户都要勾选两个角色。因此，角色统一包含数据权限、功能权限，还是设置数据角色对应数据权限集合、功能角色对应功能权限集合，需要通盘考虑数据权限、功能权限的划分，以及它们在用户身上的重合度而决定。
权限设置是b端产品的基础功能，不显眼但很重要。做方案设计时，要充分考虑初始化时权限设置的工作量以及可扩展性。以上是实际工作中的一点体会，分享给大家。
网友评论