如何设计权限、角色、操作员？
本文着重介绍，在每个B端平台中都会出现的系统设计，结合不同系统的特性，介绍如何进行交互设计
在所有的B端的产品当中，基本上都需要进行系统设计。这其中，就涉及到权限、角色、操作员之间的关系。有的系统可能更加复杂点。
一、权限有哪些组成
权限系统有菜单权限、操作权限和数据权限组成。
菜单权限与操作权限
后台系统一般来说有各种各样的功能，举个栗子介绍下：
比如说，假如后台有商户管理、库存管理和广告位管理三个功能，A用户只有商户管理权限，进入后台后，只能维护商户的数据。B用户有库存管理和广告位管理两个功能。
这种对应功能的权限，叫“菜单权限”，也有的叫“页面权限”。
后台系统一般无外乎增、删、改、查这几种操作。举个栗子介绍下不同的操作分别能干什么：
比如说，还是电商后台，商品管理就涉及到新建商品（包括商品的标题，链接，商品图片等等）、删除商品、修改商品、查看商品。这里有涉及到商品的增、删、改、查。
A用户只能查看商品，B用户能增加商品、修改商品，C用户能删除商品。A只有查的权限、B有新增、修改的权限，C有删除权限。
这种对应同一个大功能的子权限，叫“操作权限”。
数据权限
A和B两个用户同时拥有相同的菜单权限和操作权限，但是看到的数据确不一样，这是怎么回事呢？
数据权限要引入另外一个维度，比如说组织架构的维度，上级看到下级的数据，但是下级看不到下级的数据。比较典型的例子应该算是CRM客户关系管理。
例子：CRM客户关系管理，一般提供给销售员或者相关职业的人使用，方便管理自己名下的客户。假如定了一个逻辑，销售员的领导可以看到销售员的客户详情，但是不能对客户信息做更改，销售员能维护自己的客户。领导看不到别人团队的客户。
那么这里涉及到了哪几种权限的控制呢？我们一点一点分析：
1、销售员的领导可以看到销售员的客户详情
这里引入了数据权限，依据组织架构，本级领导能看到下属数据，下属不能看到上级数据。这是个树形结构，在同一个树形分支下，上级能看到下级的数据。不过也并非所有场景都是如此，如果业务规定，只能看到本级和下级两个层级的数据，那么第三个层级的数据就没法看见了。
2、但是不能对客户信息做更改
这里应用了菜单权限和操作权限。本级领导和下属同时配置了客户管理的权限，但是本级领导只有查的权限、下属有增删改查的权限。
3、领导看不到别人团队的客户
不在一个树形结构分支下的数据互相看不见，是互相隔离开的。
二、菜单权限/功能权限、角色、操作员之间的关系
通过角色连接了权限和操作员，那么有人会有疑问，为什么权限不直接配给操作员呢？在常见的场景下的处理方式为给角色赋予权限，给操作员赋予角色，这样就减去了给操作员配置重复权限的工作量。角色可以理解为是权限组，如果某个角色需要添加某个权限，那么有这个角色的操作员都拥有了该权限。
权限和角色是多对多的关系，而角色和操作员可以是一对多、多对多的关系。存在角色和操作员时多对多的场景，一般来说，是为了考虑配置的灵活性和业务的限制。
三、操作页面该如何设计
1、建立角色与权限之间的关系
菜单权限与操作权限
从以上的学习，可以看到菜单权限和操作权限本身就是个树形结构。有两种方式设计权限的选择，一种是沿用树形结构的形式，对每项都可以勾选；另外一种是表格显示，可以减少纵向延伸，更方便选择和阅读，后面的逻辑本质是一个树形结构。
新建角色
包括角色名称、角色描述、选择权限。
2、建立操作员与角色之间的关系
根据各业务场景，录入操作员的基本信息：登录账号、姓名、手机号码等等。
以下示例为简单模型。操作员可以选择一个角色。提交后，密码可由系统随机生成，发送至操作员的手机号码或者邮箱。
在某些特定业务场景，要加入数据权限的控制。举CRM客户关系管理的例子，每个操作员都需要配置所属的部门，挂靠组织架构后，数据上再做处理和限制就可以了。
关于数据权限的控制，再举个栗子，业务是分地域的，在北京的人，只能查看北京的数据，这样每个操作员需要配置他的地域限制。
四、小结
本篇讲了常见了的业务场景下的权限、角色、操作员的设计，当然业务有各式各样的，权限、角色、操作员的设计方式也不仅仅局限于此。在设计的过程中，也需要和各方尽量保持沟通，吃透业务才能做更好的设计。
