权限管理
由于本人的工作方向偏向于后台，同时也是技术出身转岗产品经理，在设计后台时常会查阅后台的相关资料，但是网上关于这方面的分享也比较少，于是利用空闲时间，把所经历的三家公司所设计过的后台系统进行整理、总结，输出一套通用的完整解决方案。系统的跟大家一起来探讨、分享，希望对大家有所裨益。
由于不同的后台管理系统需求多样化，此处所分享的是通用型，对于大多数的后台管理系统逻辑都已足够使用，主要应用于WEB应用程序，如：网站管理后台、CMS、CRM、OA等等。
当然，您也可以对他进一步深度设计，以做出更强的系统。
涉及到权限的问题往往是都是复杂的问题，在系统权限控制方面，我们经常会参照现成的案例来设计自己的权限控制，以下就是我所总结最常见的四种权限控制的方法。（附上高保真原型链接+整体结构图：见最底部）
一、控制系统的帐号及登录
1. 登录首先要有帐号，帐号的定义
基本上所有的互联网产品，无论是移动端、PC端、C端或B端产品，登陆都需要一个账号。只是对于C端的产品，都是用户自己注册即可。
而对于后台产品而言，是需要公司内部人员去创建账号的。而这个账号就是一把钥匙，我们通过控制账号所具备的权限，进而控制这个员工的所操作范围。
2. 帐号的两个层级：企业（管理员）帐号、普通帐号
公司的实际运营人，他应该掌握最核心、权限最大的企业帐号，所以也可以称为“管理员帐号”，其他都为普通帐号。
在实际系统中的核心业务步骤如下：
企业购买系统时，创建一个企业帐号，这个企业帐号绑定的手机号码为公司实际运营人的手机号码。该手机号码必要时可以解绑修改（例公司运营人变更），但是企业帐号不可删除、离职。
在部署培训阶段，可指导企业账号持有人创建一个或多个普通账号（可是给其帐号授权管理员角色），该账号一般授权给行政总监或人力资源总监，后续配置即由管理员账号进行。
这里需要注意的是2者区别：
帐号禁用：在登录系统时多次输入密码错误，系统会因为帐号安全问题暂时把禁用掉。或涉及到帐号被盗等场景需立马禁用，修改密码等操作。
帐号停用：员工离职，但是在职时所有的操作记录信息还存在，所以设置为停用。（ps：可以跟人事系统打通，人事那边设置某员工离职后，所有系统账号自动设为停用。）
在用户状态上加状态控制，可用的用户就可以登录系统，禁用、停用的就无法登录。
二、角色管理
角色往往是基于业务管理需求而预先在系统中设定好的固定标签，每个角色对应明确的系统权限，他是一个集合的概念，是众多最小权限颗粒的组成。我们通过把权限给这个角色，再把角色给账号，从而实现账号的权限，因此它承担了一个桥梁的作用。引入角色这个概念，可以帮助我们灵活的扩展，使一个账号可以具备多种角色。
其所拥有的系统权限一般不会随意更改，并且角色也不会随着用户的被添加和被移除而进行改变，相较于用户管理而言更加稳定。
由于随着公司扩大角色的增多，而不好进行管理，比如：hr这个角色，如果集团有分公司可以给与分类，比如：上海分公司：人力总监；北京分公司：人力总监。
这个角色所赋予的数据权限会不一样，对于中小型公司，可以对角色进行一个精细的分类管理起来比较方便。
三、控制功能权限
功能权限定义：为可见、可以操作的功能范围。例如：某一部分菜单，或者某个页面里的各种操作。
1. 菜单管理模块
类型分为3种：目录、菜单、按钮。
在目录、菜单上加权限控制，有权限的就可以访问对应模块，没有的连菜单名都看不到。
在业务模块的功能按钮上加权限控制，最小粒度的控制用户行为，譬如：老板娘有录入商品的权限，就能看到商品录入的按钮，点击录入就可以进行商品的录入操作；反之没有该权限的店员就无法进行商品录入的操作。
2. 控制功能权限管理
底层菜单管理配置一般为开发人员一早就配置好，现在由用户进行分配使用这些功能权限。
功能权限：以角色为基础，通过划分不同角色的不同功能权限，并将员工添加到对应的角色中，实现员工功能权限的区分和隔离，包括：
对象级功能：比如功能的入口是否可见，如角色为“蓝鲸观察者”，对象“人员管理”的“查看列表”权限点取消，则此角色下员工不可见人员管理的功能入口。
操作点权限：比如新建、编辑等业务操作；
字段权限：在展示信息时加权限控制，保证敏感信息的安全性。可为角色配置对象字段的读写、只读或不可见。比如：为角色“服务人员”配置销售订单的【销售订单金额】字段不可见。
控制了员工对字段的可见性，可编辑性，比如：不想要电销人员看到客户的电话号码，不需要服务人员看到客户销售订单中销售订单金额，则可以把相应字段隐藏。
【读写】权限：员工将具备该字段的最大权限，【新建】【编辑】时可编辑，列表和详情页可见该字段。
【只读】权限：员工在【新建】【编辑】时不可编辑，列表和详情页可见该字段。
【不可见】权限：员工在【新建】【编辑】【列表】【详情】界面对该字段（或该字段值）不可见。
功能权限对于前端界面的影响点：
如果员工没有某对象“查看列表”的权限，则该对象的功能入口会被隐藏。
如果员工没有某对象的操作点权限，则在对象页面上隐藏相应操作按钮。
如果员工没有某对象的指定字段的可见权限，则在对象页面上隐藏相应字段。
3. 控制字段权限用户操作界面
控制字段权限需要有一个页面配置页面来做支撑，此界面由开发人员进行控制操作。
点击某一个页面进行配置，可以进行添加，或从数据库快速生成属于这个页面的字段。在从这个页面的字段中选择哪些字段是提供给用户进行设置字段权限，因此有了上上图。以及字段的显示名称，是否必填字段都是控制提供给用户进行设置字段权限界面。
4. 控制数据权限
数据权限定义：数据权限管理主要控制某条数据记录对用户是否可见，结合功能权限可以更灵活的配置业务过程中每一位员工的功能操作权限及数据可见范围，全面保障企业数据的安全性。
类似矩阵列表中，功能权限决定用户可见哪些列，比如客户对象中可见姓名、电话、邮箱等字段。数据权限决定用户可见哪几条数据，比如：“王先生”、“李先生”等。
数据权限分两个层次来控制数据：
基础数据权限：即根据数据的负责人来决定。
数据共享：根据基础数据权限中的数据记录所属将其共享给其它用户查看或编辑。
基础数据权限：
私有：对象中所有数据遵循相关团队成员（包括负责人）及其上级对数据可见，且对这条数据具备同样的权限【只读、可编辑】，上级部门的部门负责人可以看到下级部门的所有数据。
公开只读：对象中所有数据对全公司公开，单条数据的负责人及其上级、以及相关团队具备编辑权限的成员可以编辑该数据。
公开读写：对象中所有数据对全公司公开，全员可编辑。
备注：此处的“上级”是指用户的汇报对象，在用户管理界面可进行编辑汇报对象。
系统初始化一开始默认设置好（默认设置的应该是根据客户公司实际运营情况），用户再根据公司的发展而进行改变默认设置，也可进行恢复默认设置，因为默认设置是涵盖了客户公司90%的场景。
数据权限共享：
数据共享规则是将某个部门/员工（数据来源）的某个对象（比如客户）的全部负责的数据共享给某个部门、人员或者用户组（共享范围）。配置数据共享规则后，被共享方对共享方所负责的所有数据可见，并具备共享权限对应的操作权限。
业务配置说明：
数据来源于：即需要共享的数据，选择员工即指该员工负责的记录数据，选择部门即指该部门下员工负责的记录数据。
共享的数据：选择需共享的对象，比如：将员工A负责的客户数据共享给员工B。
数据共享到：被共享方，可选择员工、部门或用户组，被选择的员工、部门或用户组成员将可以看到共享的数据。
共享后的权限：配置被共享方可对数据查看或是可编辑的权限，如果配置为“读写”权限后，被共享方对共享数据的权限可类比于负责人的权限。
业务场景举例：销售一部想让财务部张三看到该部门的所有销售订单数据，并且让张三可编辑。
（1）共享规则配置
【数据来源】是“销售一部”;
【共享数据】是“销售订单”
【共享范围】是“张三”;
【共享权限】是“读写”。
（2） 配置完成后
配置完成后，张三在【销售订单】对象，【共享给我的】场景下，可以看到销售一部的所有员工负责的销售订。
附上高保真原型链接+整体结构图：
《蓝鲸后台权限管理系统》高保真原型链接：http://www.wulihub.com.cn/go/4Jrn8J/start.html#g=1&p=登录页面&c=1
总结
后台权限管理系统并不是越复杂越好，只有贴合客户实际需求并具备最大弹性的权限系统，并有效控制开发成本的设计就是合理的设计。
以上根据自己的设计经验总结给出的一套方案，小小产品一枚，有不足之处，欢迎各路大神拍砖指教~
题图来自Unsplash，基于CC0协议
相关阅读
购买授权之前，建议认真阅读下述 “解惑”，以免造成不必要的困惑。另外也可以阅读 《layui 付费产品服务条款》注意：layuiAdmin 受国
<p class="wrapper"> <p class="inner-menu"> <dl> <dt>商城设置</dt> <dd><a href="<"><i class="fa fa-list">
大家都说后台产品难做、要求高，这是有原因的。而且这个原因会超出我们的认知，一起来看看吧。什么是后台产品后台产品也被我们称为后
100行代码教你实现贪吃蛇小游戏 最近项目中内置了一些比如贪吃蛇,俄罗斯方块,井字棋等小游戏. 这里逐一将实现步骤分享出来供
设计原则101——色彩理论第一印象决定一切！大家都可以从各自的外表上大概看出一个人的性格。同样的，这个理论也可以延伸到设计工作