端产品设计用户角色权限系统设置

　　本文首先对B端产品的用户与需求进行了解析，进而利用RBAC模型做了权限划分，并做了详细的案例分析。
　　在做过了一些B端产品后，就会发现所以B端端产品有很多共同的部分，比如系统设置里的用户角色权限以及基础信息的维护，虽然B端产品可能业务不一样，产品服务的人群、产品价值不一样，但是用户体系却是每个系统必不可少的。
　　1. B端产品的用户
　　1.1 B端产品的用户
　　B端和C端不一样，C端一般针对的是个人用户，涉及的关系结构相对来说比较简单，关注个体数据以及个体产生的价值。同时B端产品的用户一般是企业，这就决定了使用系统直接的同事需要相互协作，共同去完成一件事。
　　1.2 B端产品用户的需求
　　B端客户一般客户角色多元化，每个用户对系统的需求和职能也是不一样的，这就需要我们根据他们的使用需求去划分，让系统使用者不会被其他事项干扰或者看到不该看到的东西。所以这就需要B端产品能够根据每个用户的需求去＂自定义功能＂，就是系统的设计要灵活，系统管理者可以灵活配置自己想要的权限以及管理自己的员工。
　　2. RBAC模型
　　在传统权限模型中，我们直接把权限赋予用户。RBAC模型的基本思想就是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。
　　每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，减少系统的开销和频繁设置。
　　RBAC0模型中角色和权限是多对多的，一个用户拥有的权限是他所有角色的集合。如下图，用户1假如拥有角色1、角色2、角色3三个角色的话，那拥有的权限是权限1、权限2、权限3。
　　RBAC1模型中在角色中引入了分层的概念，即角色中可以分为多个等级，每个等级对应的权限是不一样的，把权限分给用户时，需要分到对应的角色等级。一般角色等级低的拥有的权限少，角色等级高的权限是所有等级低的权限集合。
　　RBAC2模型中在RBAC1模型中的基础上对角色进行了一些限制：
　　互斥角色限制：同时拥有两个角色以上，且有角色互斥时，系统提醒职能选择一个，比如公司职业中，如果选择商务角色，生成结算单，并提交给财务审核时，这时候就不能赋予这个员工财务角色。否则他就可以自己提交结算单自己审核结算单了。
　　角色数量限制：一个员工的角色是有限的 了，不能无限制的添加；
　　先决条件限制：若一个员工想获得更高权限时，需要获得低级权限，比如想获得产品总监的权限那就需要从产品助理的角色先到产品经理的权限；
　　3. 详细案例设计
　　3.1 公司管理
　　一个B端的用户角色权限系统大致可以包含：公司管理、部门管理、角色管理、用户管理。在一个集团中，往往在不同地区有不通的子公司或者合资公司，那如果这些公司里的员工同时用这套系统，那就需要进行公司管理，如下图：
　　一般公司管理，需要基本信息包含企业名称、企业联系人、联系人号码、社会统一信用代码、通讯地址、法人信息以及一些证件信息上传营业执照、法人身份证照片等。
　　公司管理的录入一般是为了后期的员工管理以及一些基础信息维护时的归属，一般页面设计如下：
　　3.2 部门管理
　　公司向下就是部门管理，在权限设计时，有时也会赋予部门一些权限，只要是这个部门的人都具有部门权限，当用户再赋予角色时，会在部门权限的基础上累计添加的角色权限。
　　即我们可以把一个部门看成一个用户组，如销售部，财务部，再给这个部门直接赋予角色，使部门拥有部门权限，这样这个部门的所有用户都有了部门权限。
　　用户组概念可以更方便的给群体用户授权，且不影响用户本来就拥有的角色权限。
　　部门设计一般有所属公司、上级部门、部门名称、部门分类，部门的划分只要是为下方的用户权限以及数据权限做准备。一般设计如下：
　　3.3 角色管理
　　角色对应的是权限，一般包含功能权限，精确到功能操作权限，字段权限，包含字段是否可读或者使用、以及一些数据权限，是只能看见自己的数据还是可以看见同部门的、其他部门的、以及整个公司、或者整个地区的数据，这些都是靠角色去设置。
　　功能权限
　　对于后台产品来讲，针对功能菜单来划分用户权限其实是比较粗颗粒度的一种管理方式，这种模式下用户一旦获得授权即可使用该菜单栏下的全部数据查看权限和功能操作权限，页可以针对单个菜单下的操作按钮进行权限设置。
　　字段使用
　　字段的设置在对象向下，用来区分不同角色进入同一菜单下见到和可使用的字段是不一样的。用户可对业务下的字段进行可见或者只读形式的设置。
　　需要注意，角色一般不做删除，只用禁用启用操作，禁用时会校验是否当前有用户在使用，如果有使用时提醒设置者去更换账号角色方可禁用。
　　3.4 员工管理
　　员工管理是对应的账号，在公司、部门、角色设置好后，我们就可以对员工进行管理了，一般员工包含在系统中的使用账号的和不使用账号的。
　　在对用户管理进行分配角色时，我们可以分配一个角色，也可以分配多个角色，也可以快捷分配所有的角色。
　　一般到此一般喜用的角色权限就可以满足业务需求了，但后期可能会涉及到多个系统去使用一个用户体系，这就需要产品跟随业务模式进行调整，但是一般基本模型不会变更。
　　The end !