设计实例：如何以“用户”为单位的进行权限设计（一）.docVIP

设计实例：如何以“用户”为单位的进行权限设计（一）　　权限设计可以很好地对保证公司信息系统的安全。权限设计的方式主要有：以“用户”为单位、以“权限”为单位和以“用户”与“权限”结合的权限设计方式。这篇文章针对以“用户”为单位的权限设计方式进行展开解读。 　　 　　最近公司发生一件大事：公司一员工，窃取网站后台管理功能资源以及网站销售额等数据，事后发现是敌对公司派人有意所为。电视剧场景在现实重演，有些吃惊，为防止此类事情再次发生，临危受命，针对权限管理进行重构。 　　为何有权限设计的需求 　　禁止非法用户盗取资源 　　访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，每一台计算机具备浏览器，如果不建立一个完整的权限检测，那么一个非法用户可以轻而易举通过浏览器访问Web应用项目中的所有功能资源。 　　保证数据的保密性 　　公司内部员工的角色不同，自然对于系统使用功能的权限不一样，关于机密数据的列表菜单是不能允许让所有人进行访问的。 　　比如：一个电商网站的销售额等报表数据，是不允许公司内所有员工都进行查阅的，有针对地进行管理。 　　权限设计的方式有哪些？ 以“用户”为单位的权限设计以“权限”为单位的权限设计以“用户”与“权限”结合的权限设计　　针对以上三种类型，结合业务场景以及具体设计方式，详细进行讲解。 　　以“用户”为单位的权限设计 　　适用的业务场景 　　当使用该系统的人之中，存在很多拥有同一类权限的人，将拥有同一类权限的人定义为“角色”或者“部门”等其他称号，而这个集合的称号就是定义权限的集合体。 　　举例：在公司内部，运营部人员拥有查询报表的权限，客服部人员拥有审核商品评论的权限，而运营部人员和客服部人员人数众多，且权限一致，那么以“用户”为单位的权限设计更符合业务需求。 　　如何进行设计？ 　　1、信息架构图 　　 　　用户：添加用户过程中，分配至某一个部门，该部门拥有的权限就是该用户的权限 　　部门：添加部门时，除填写部门基本资料外，对该部门定义具体权限 　　2、业务流程图 　　 　　具体流程：添加部门，给部门设置权限，添加用户时，设置所属部门，部门的权限即是该用户的权限。 　　3、具体原型图设计 　　添加部门： 　　 　　添加用户： 　　 　　由于公司内部资料的保密性，我纯手打两分钟，撸了个最简单的示意图进行参照，其设计方式相信一看即懂。 　　关于此方法的权限设计疑问 　　1.权限的类型有哪些？ 　　权限分为菜单功能和特殊项区分权限。 　　菜单功能权限：为一个用户设置权限，该用户所属部门为运营部，运营部的权限设置中，勾选报表管理，但是未勾选导出报表。 　　那么该用户进入该系统，能看到菜单页，但是无法看到导出报表的按钮，因为没有改权限。 　　特殊项区分权限：有这样一个业务场景，该后台系统管理几个电商网站，我不希望A网站的运营人员看到B网站的销售额数据，同理，B网站的运营人员看不到A网站的销售额数据，似乎菜单功能权限不能为我们解决此问题。 　　那么，我们分两步走： 　　1、在给部门设置权限的页面，加上特殊项区分权限。 　　 　　2、找出与此特殊项区分权限所有相关的页面，进行展示并进行标记。 　　 　　以上为报表详情页，如果该用户所在部门的权限中，勾选了A站、B站以及C站的权限，那么在报表详情页中的搜索选项，出现的站点为权限勾选的网站，如果未勾选任何网站，那么相应地，报表详情页中查看不到任何网站的数据。 　　需要记住一点的是，涉及到特殊项区分权限的页面很多，产品经理需要全部找出，并进行合理的设计展示，完善方案后给到开发，进行代码的实现。 　　3.当遇到一个部门内部，必须针对不同的人设置不一样的权限，如何处理？ 　　业务场景：一个后台管理系统管理众多电商网站的评论，客服部人员内部进行分工，1号客服负责A网站的评论审核，2号客服负责B网站的评论审核，3号客服负责C网站的评论审核，那么问题来了。 　　1号、2号、3号客服同属于一个部门，他们所拥有的权限不一样，你如何进行处理？ 　　大部分人会想到一个解决方案：那就帮2号、3号客服再次新建一个部门，一个部门一个权限可以解决。 　　但是，这是有弊端的： 试想这种业务场景足够多的话，那么会造成的结果是：你的部门列表会有一堆重复的部门，部门之间也无法进行区分，显得页面非常乱。有些重复的部门下只有一两个人，非常不利于进行管理　　此路不通，怎么解决？ 　　方法是制造一个二级部门的概念，部门太大需要在小组内再区分，就增加三级部门的概念。 　　三级部门属于二级部门，二级部门属于一级部门，针对现实的状况进行区分。 　　在添加部门时，选择一级部门时，如图所示： 　　 　　选择二级部门时，如果所示： 　　 　　选择不一样的部门类型，进行添加，针对部门进行权限设置，也更方便解决会有重复