B端产品用户
B端产品用户
B面与C面不同。 C端一般针对个人用户。 涉及的关系结构比较简单，关注的是个体数据以及个体产生的价值。 同时，B端产品的用户一般都是企业，这就决定了直接使用系统的同事需要互相协作，共同完成一件事情。
B端产品用户的需求
B端客户一般具有多样化的客户角色，每个用户对系统的需求和功能不同。 这就需要我们根据他们的使用需求来进行划分，这样系统用户就不会被其他事情打扰，或者看到不该看到的东西。 因此，这就要求B端产品能够根据每个用户的需求进行“定制功能”，即系统设计必须灵活用户角色权限设计，系统管理者可以灵活配置自己想要的权限，管理自己的员工。
RBAC模型
在传统的权限模型中，我们直接向用户授予权限。 RBAC模型的基本思想是，系统操作的各种权限不是直接授予特定用户，而是在用户集和权限集之间建立一个角色集。 每个角色对应一组相应的权限。 一旦为用户分配了适当的角色，该用户就拥有该角色的所有操作权限。 这样做的好处是不必每次创建用户时都分配权限。 您只需为用户分配相应的角色即可。 而且，角色权限更改的频率远低于用户权限更改的频率开发学习，从而降低了系统开销和频率。 设置。 RBAC0模型中的角色和权限是多对多的。 用户拥有的权限是其所有角色的集合。 如下图所示，假设用户1拥有角色1、角色2、角色3三个角色，则其拥有的权限为权限1、权限2、权限3。
RBAC1模型引入了角色分层的概念，即角色可以分为多个级别，每个级别对应的权限不同。 为用户分配权限时用户角色权限设计，需要将其分配到相应的角色级别。 一般来说，级别低的角色权限较少，角色级别高的权限是所有级别低的权限的集合。
RBAC2模型在RBAC1模型的基础上对角色进行了一些限制。
互斥角色限制：当您同时拥有两个或两个以上角色，并且存在互斥角色时像素游戏素材，系统会提示您选择一项功能。 例如，在公司职业中，如果您选择业务角色，生成结算表并将其提交给财务审核，则不能为该员工分配财务角色。 否则，他可以自行提交和解表并自行审核和解表。
角色数量限制：员工的角色数量有限，不能无限制添加；
前提限制：员工想要获得较高的权限，就需要获得低级的权限。 例如，如果他想获得产品总监的权限，他需要首先从产品助理的角色中获得产品经理的权限；
详细案例设计
公司管理
一个B端用户角色权限体系大致可以包括：公司管理、部门管理、角色管理、用户管理。 在一个集团中，不同地区往往有不同的子公司或合资企业。 如果这些公司的员工同时使用该系统，则需要公司管理，如下图：
一般公司管理需要的基本信息包括公司名称、公司联系人、联系电话、统一社会信用代码、批准地址、法人信息以及一些证件信息上传营业执照、法人身份证照片等。
公司管理的录入一般是为了后期的员工管理以及一些基础信息的归属维护。 总体页面设计如下：
部门管理
公司下层到部门管理。 在设计权限的时候，有时会给部门一些权限。 只要该部门的人员拥有部门权限，用户分配角色时，新增的角色权限就会在部门权限的基础上累计。 。 即我们可以把一个部门看成一个用户组，比如销售部门、财务部门，然后直接给这个部门分配角色，让这个部门拥有部门权限，这样这个部门的所有用户都拥有部门权限。 用户组概念可以更轻松地对组用户进行授权，而不会影响用户已拥有的角色权限。
部门设计一般包括公司、上级部门、部门名称、部门分类。 部门划分只需准备下面的用户权限和数据权限即可。 总体设计如下：
角色管理
角色对应权限，一般包括功能权限，细化到功能操作权限，字段权限，包括字段是否可以读取或者使用，还有一些数据权限，是只能看到自己的数据还是可以看到同一个的数据部及其他部门。 ，还有整个公司或者整个地区的数据，这些都是按角色来设定的。
功能权限
对于后端产品来说，针对功能菜单划分用户权限，实际上是一种比较粗粒度的管理方式。 该模式下，用户一旦获得授权，就可以使用菜单栏下的所有数据查看权限和功能操作权限。 页面可以对单个菜单下的操作按钮进行权限设置。
现场使用
字段从对象向下设置，以区分不同的角色。 同一菜单下可以看到和使用的字段是不同的。 用户可以将业务下的字段设置为可见或只读。
需要注意的是，角色一般不会删除，只会禁用和启用。 禁用时会检查当前是否有用户使用。 如果使用，将提醒设置者在禁用之前更改帐户角色。
员工管理
员工管理就是对应的账号。 公司、部门、角色设置好后，我们就可以对员工进行管理了。 一般来说，系统中包含的员工包括使用账户的员工和不使用账户的员工。
在为用户管理分配角色时，我们可以快速分配一个角色、多个角色或全部角色。
一般此时常用的角色权限就可以满足业务需求，但后期可能会涉及到多个系统使用一个用户系统，这就需要产品根据业务模型进行调整，但一般都是基础模型不会改变。
结束！
