B端产品的权限设计

企业级系统最重要的产品基石就是权限设计，那么一个完善的权限设计应该包含哪些内容呢？

首先是关于公司组织机构的搭建。树形结构是目前的通用结构，且最好对组织进行好分类。

人员管理。每个人员都是独立的资源，同时又是归属于某个组织的。这里要强调下，人员组织的设计要是多对一的，即多个人对应一个部门，那些为了权限管控方便，把一个人归属到多个组织里的不是没见过，只能说只有填过坑，才知道其中的痛

到这里才是关于权限设计的重头戏--角色管理

一般一个系统的完整权限分为三种：菜单权限，按钮功能权限，数据权限。菜单权限的设计很基础，玩不出什么花样，肯定是通过关联角色，进一步关联人员。但是按钮功能权限的管理已经有些设计思路上的区别。

如果是一个新做的系统，那么推荐将菜单权限和按钮权限合并，共同形成菜单功能角色。说白了，就是为了图个方便。但是对于一个已经成型的系统，之前未做过按钮权限控制，那怎么办呢？不用急，有种技术方法可以解决，就是每个页面做一套按钮权限控制器，在页面加载的时候，同步加载按钮权限，进而实现权限的管理。这种方法虽然是补救措施，但却也有一个好处，可以做成通用组件，所有的页面都引用这个功能，需要做按钮权限控制的页面不用再另行开发。这两种方法各有优劣吧，很多时候我们是没得选择（看系统是从零开始，还是半路接手）

上面说的两种方法，都是要将菜单按钮绑定角色，进一步绑定人员

下面再说说数据权限的控制

如果说菜单功能权限，大家还能形成一定的共识，那对于数据权限的设计真的是各显神通。集中在两种思路

      一是将数据权限直接绑定用户，结合组织机构控制订单数据

      二是将数据权限进一步解构，仍然绑定角色，再通过角色绑定用户

通过第一种方法实现数据权限的案例不要太多，比如直接配置某个用户只能看那些用户的单据，又或者只能看那些组织机构的单据；还有通过配置用户的级别（经理、主管）结合组织机构，进行控制数据权限。真的只能呵呵了，这样做的结果是人员权限和单据的强耦合，等到单量过大，业务过复杂时，这种结构就像是气球，一戳即破。

系统设计中有句话，没有什么不是加中间件解决不了的，套用到权限设计也一样。尽管有各种类型的业务权限需要满足，仍然应该将权限先绑定角色，再绑定用户

      拿个栗子，一个简单的权限表应该是包含：适用系统、权限类型、权限值。比如想控制BMS系统的A组织机构里的数据只能XX看到，那么权限维护就是 BMS、组织机构、A；如果想控制ERP系统里的B用户建的单子只能XX看到，权限就维护成WMS、个人、B。这种结构有个好处是，可以随意扩充，而且将用户和权限解耦，随时绑定和解绑，灵活控制各类权限

最后再谈一点额外的权限控制

从业务角度，权限的控制可以分为两种：硬权限、软权限。上面说的都可以是硬权限控制，那么啥叫软权限控制呢？

就是指用户日常工作中不想看到哪些数据，而不是不能让用户看到哪些数据。这里就可以引入一起筛选模板上的管理，即将用户日常规律的数据筛选行为记录，以后系统每次打开自动执行筛选。某些产品陷入到权限黑洞中，总想通过硬权限实现业务需求，往往将系统设计的很复杂。而适当的软权限控制有时会产生意想不到的结果，大力推荐。

职场中常见的ERP/SCM/OMS/WMS/TMS/BMS等企业级系统，都可考虑按此思路设计