「功能」权限设计=功能权限+数据权限( 二 )


基础模型:用户与角色是多对多的关系 。一个用户可以拥有若干角色 , 一个角色也可以赋予若干用户 。但并不意味着角色之间的关系互斥与否 。
「功能」权限设计=功能权限+数据权限
文章图片

文章图片

在企业的后台管理系统中 , 通常包含多种管理模块 , 有针对供应商的模块、客户的模块、财务人员的模块、统计管理人员的模块 。为了避免内部信息的交叉传播 , 以及操作人员可能存在的误操作行为 , 我们就可以通过此种基于角色的访问控制模型 , 为后台的操作者设置多种角色 , 并为每个角色赋予不同的业务权限 , 精确到对应菜单模块的控制 , 甚至是相应的按钮权限 。
这样就可以让销售同事只能查阅和修改供应商管理模块 , 无法查阅公司的财务信息 。而财务同事也只能查阅和修改财务报表相关的管理模块 , 无法查看公司的订单汇总 , 不同岗位各司其职 , 互不干扰 。
对于小型的企业 , 当一个人既负责销售部 , 又负责运营部时 , 就可以为其赋予销售人员、运营人员两个角色 , 这样他就拥有这两个角色的所有权限 , 即可以访问这两个模块的内容 。但是公司规模越大 , 对每个岗位的权责要求也更为细致 , 角色之间可能会有相应的组合关系 。有必要理清楚岗位 , 职务 , 职位 , 权限 , 角色 。
毫无疑问:权限是这些概念中的最细粒度的一个东西 , 而角色是一组权限的集合 。岗位是职位的同义词 , 他们的侧重点不同 。
职务才是被大家忽略的一个概念:具体定义不是很清晰 , 但他是某一业务中某一角色应当承担的责任或者说应该负责的事 。
一个职位一般来说有多个职务 , 比如说我们的经理助理这么一个“职位”可能要负责的事情可能有很多类 , 如:协助安排经理的日程 , 对下面呈上来的某类报告做初步审理等等一条条 。这些被我们认为梳理出来的一条条的东西就是职务 – 他在当前职位上需要担负的义务 。
大家初期容易将岗位抽象成一个角色 , 但是最终发现这个角色可能粒度太粗或者是不宜重用 , 这个时候就应该梳理一下每个职位的职务 , 以职务为单位抽象成角色 , 这样才能制定出更细粒的角色 。
当然职位由于他是我们看的见摸得着的 , 所以直接将职位映射成角色是非常简单清晰没有异议的 , 而职务就不同了 , 他需要产品人员深入理解客户的业务 , 这样才能根据客户的业务情况梳理出一个业务职务体系 , 这个过程必然会很辛苦 。
5. 关于功能权限设计的几点Tips如果项目初期不需要权限管理 , 一定记得提醒开发同学 , 预留相关接口 。功能权限设计 , 也包括页面权限和接口权限 , 这一点没有经验的产品同学可能注意不到 , 需要保证没有该模块功能权限的用户直接输入页面地址或调用接口时 , 也无法访问 。一个页面完成一件事 , 避免页面交互方式太复杂 , 无法划分功能权限 。功能权限与数据权限有时可以通过模块进行转换 。
本文由@山人小道 原创发布于人人都是产品经理 , 未经许可 , 禁止转载 。
【「功能」权限设计=功能权限+数据权限】题图来自Unsplash , 基于CC0协议


推荐阅读