在做b端产品，不可避免的遇到权限管理，权限设计，根据什么样的角色，授予什么样的权限，然而权限还涉及到数据权限和功能权限，在说什么是权限，先引入角色的概念
什么是角色
角色，通俗的说，你是什么样的角色，例如你是管理员和普通用户，是两个角色，管理员拥有所有的权限，而普通用户只有部分权限。
管理员可以对普通用户设置权限，例如，普通用户A之前是可以查看和删除评论功能，管理员修改了普通用户A的权限，不能进行删除评论功能，此时普通用户A只有查看的权限。没有删除的权限，至于删除按钮是否显示，这是前端设计：
方案一：可以保留删除按钮，置灰操作或者点击提示你没有删除权限；
方案二：隐藏删除按钮，普通用户没有删除按钮。
在说到管理员和普通用户两种角色，他们分别对应不同的权限，同事在一个系统里，会出现很多种角色，所有需要对角色进行管理，增、删、改、查、设置权限、最基本的五项，其中删除功能在设计过程中要引起注意，删除角色，该角色中人员，人员在系统中有操作行为产生了数据，直接删除角色，会导致系统报错。
举个简单的例子，在商城系统中，人员A在在系统中创建了商品，而创建商品的是只有“店长”这个角色可以创建商品，所以人员A就拥有店长这个角色。这里说明下，人员A不是属于店长这个角色，而是拥有，是一个人员对应对个角色的关系。此时把店长角色删除了，而人员A只设置了一个店长这个角色的时候，该人员自然就报错了，他不属于任何角色。
回到角色管理，一个角色对应哪些权限，而管理员拥有所有权限，所以在设计权限管理的过程中要注意管理员和普通角色这两种角色
功能权限设计
权限设计，可以把一个系统所有的功能设计相应的权限，例如商城管理中，商品管理这个模块，在设计权限过程中，就设计到如下权限：
a、新增商品
b、修改编辑商品
c、商品的上架下架
d、删除商品
e、查看商品
......
以上是功能权限，设计过程中，可以将每个功能设计复选框，管理员拥有所有权限，流程上实现方式如下：
创建用户--->选择角色--->设置权限。例如创建的用户B可以新增商品，编辑商品，上下架商品，查看商品，但是出于安全考虑，不允许用户B删除商品，设置用户B对应的角色中不设置有删除商品的功能。
设计功能权限应该注意什么
一、管理员权限
由于一个系统，一个平台使用的人员较多，涉及到的角色也较多，会出现一个系统多个管理员，分级管理员的情况。另外由于系统处于开发中，会一直新增功能，如果管理员也是同普通角色一样，勾选权限列表功能（全选），虽然是全选，但是后续新开发的模块，需要一一的去权限，一来麻烦，二来设计的也不合理，所有管理员的权限，不应该是同普通角色一样去全选所有的角色，而是默认所有的权限。
二、功能权限的颗粒度
功能权限的颗粒度需要多细，根据实际的场景去考虑，1）如果是对权限管控要求很严格的，需要细化功能权限，例如政府部门系统的设计。2）BtoC产品，为了方便使用者理解和使用系统，功能权限的设计就不需要很细，例如商城系统中商品的搜索功能，搜索商品功能有下拉根据什么属性筛选，根据时间筛选，查看列表等等，而作为用户，是可以搜索和查看商品，在设置搜索商品的权限。也就拥有是搜索功能权限，可以按时间搜索，也可以按时间搜索。
三、更多需要注意的坑，待补充......
什么是数据权限
对于数据权限，接触了很多次，一直不明白，或者处于半明白状态，这里要感谢程序猿的指导。
百度找了下数据权限的定义，并没有，我去。
开发系统，各种功能，由功能产生了数据，但是数据并不是对所有人开放和显示，所以就引入数据权限的概念。而数据权限在交互上是不会体现出来，在中小型系统上也不会显示数据权限的设置页。
引入一个例子方便理解：电商商城，由于后台商城可以创建或维护不同的店铺，有店铺列表的概念，A店铺产生的数据，商品，订单等不会在B店铺中显示出来，这就是数据权限对之进行了限制。那有人会问，在功能设计过程中，查询功能不是进行了限制，这是是个误导，用户C可以查看商品，不没有说明可以查哪些店铺的商品：1）如果用户C是个管理员，那他就拥有查看所有店铺的商品，2）如果用户C只是一个店铺的子管理员，那他的权限只能查看该店铺的商品，3）如果用户只是一个店铺中的一个普通员工C，该店铺有衣服商品，办公用品等各种各样的商品，而该普通员工C只管衣服商品，这时处于衣服这个商品可以查看，其他商品均不能查看。
以上就是数据权限的概念，仅通过功能权限是不够的。
数据权限如何设计
我在做后台系统过程中，遇到过技术要求产品要涉及数据权限，也有技术不要求设计数据权限，那么产品要不要设计数据权限，以及如何设计数据权限?
根据四个方面的因数考虑：
1 根据系统的大小，该系统只有一个系统，还是该系统下有很多子系统，或者系统下各个模块数据的独立性，不能共享，例如商品平台多个店铺，功能间就不能共用；
2 系统对权限划分的颗粒度，根据权限细节角度，权限层级也多，则越需要有数据权限；
3 根据使用场景，需要后期人为去设置数据权限，还是在程序中可以默认设置权限。
4、根据创建账号所在的层级，例如创建账号是最上层管理平台上，此时需要设置数据权限，如果创建账号是属于分支平台上创建，则不需要数据权限
5、....
只要理解了数据权限和功能权限区别，至于要不要设计数据权限，在实践的过程中，就心里有数了。权限管理其实没有那么难，只要理解了就好，他是系统不可缺少的部分。当然也存在系统较小，所有人在同一个平台的操作权限都一样，这种比较少。
有一本书，《通用权限管理系统》，写的有点多，而且会比较过时，不过还是蛮有用的，对权限这块的了解和熟悉。
全文没设计图，也没有流程，懒的画懒的找了。如果逻辑上有错，欢迎提出来...
各位看官，看完喜欢点个赞呗~
2019年7月27更新
补充菜单管理，字典管理和系统日志
权限管理一直都是B端产品很重要的部分，小编在工作中，设计过程中需要有菜单管理，字典管理，系统日志，这些其实是架构师给我的指导和梳理，再次感谢程序员大大
那菜单管理，字典管理，系统日志又是什么，他和权限又有什么依赖关系？
菜单管理
菜单管理，他是系统最高级管理员需要用到的功能
这里需要做个说明，最高级管理员开发者管理员的区别，如果系统是做平台层，或者比较大的系统，菜单是需要做到动态的，而我们常见的最高级管理员，是使用者的最高级管理员，并不是开发者的管理员，开发者的管理员所具有的功能才是最全的，那么有人问，使用者的最高级管理员和开发者最高级管理员合并为一个，不就可以了，其实不然，由于使用者他不一定会懂得编程，对于一些开发的一些概念不懂，也看不懂对应的菜单，比如环境探针，开发者监控日志等，这些如果给到最高级使用者管理员，他们看不懂，也会觉得做的系统奇葩。不需要展示的开放出来干什么。实际上是开发者用的
回到菜单管理，由于系统庞大，或者系统是平台层的，而当平台层需要创建一个新的产品，新的产品菜单的创建，这时候就要菜单管理去增删改查。而这个权限一般是不会下设给其他人，不管系统管理上就乱了
字典管理
所谓字典管理，字段名称创建的根源，一般来说字典管理中的管理表，包含的属性有：名称，名称编码。具体的数据，举个例子：比如性别：区分男/女.而男对应的名称编码比如是0，女对应的名称编码是1.这就是字典管理中的两条数据。不外乎关联其他功能，他是有系统层直接管辖，不受其他数据的牵连，而业务层需要用到，可以调用字典管理中的数据，比如个人中心中需要用到性别字段，可以调用字典管理中的数据。
字典管理，页面上的呈现一般是直接设计一个表，新增的数据，可以是，性别，身高，体重，可选项中的选项值。
这是和架构师学的，其实字典管理，和我们日常使用中的字典有着同样的作用，比如我们去查康熙字典，具体到某个字，这个字可以在不同的地方，不同的语境下产生作用，但是他字的根源在康熙字典中。（杠精会说 字的根源不在字典中，这是比喻，比喻我们设计系统字典管理是什么，他产生的作用是什么，起到什么作用。）
系统日志
我们常见的有登录日志，操作日志，监控日志，等等，他和系统日志又有什么管理，其实是"父子”关系，即系统日志包含所有的日志，系统日志底下有登录日志，操作日志，监控日志，他们各自起到不同的作用，比如我们常见的禅道，有登录日志和操作日志，即登录记录和操作记录，作为管理者可以查看，统计，跟踪问题，跟踪责任，记录事实等。而监控日志，一般是给开发人员用的，系统大数据的并发，产生的卡顿，bug，系统崩溃等，为了方便定位问题，优化系统。
