互联网|对权限系统的思考( 二 )


功能权限取决于用户在实际工作中 , 要负责的工作内容 。 而工作内容取决于用户所在岗位的岗位职责;因此 , 功能权限取决于用户的岗位职责 , 用户有什么岗位职责 , 在系统上就应该对应拥有什么功能权限 。
张三、李四是一家垂直电商公司的运营专员:张三负责维护商品信息 , 李四负责订单跟进、活动策划 。
张三只拥有商品管理的功能权限 , 可以添加、修改商品信息;李四则拥有订单管理、运营活动管理的功能权限 , 可以查看跟进订单、配置运营活动 。
2. 功能权限设计注意点
1)找出需要做特定权限控制的功能点每个模块都是由很多个功能点构成的 , 但并非每一个功能点都需要对用户做特定的权限控制 。
那些依附于主功能 , 且即使不做控制 , 也不会带来风险的基础功能点 , 完全就可以使用默认授权 , 开放给所有用户使用 。
一个列表页面 , 通常由数据查询、数据列表、添加数据、删除数据、分页等功能点构成;其中 , 数据查询、分页功能 , 依附于数据列表 。

若用户拥有数据列表的权限 , 那么理应也拥有这2个功能的权限;反过来 , 如果用户没有数据列表的权限 , 即便用户有这2个功能 , 也完全不会有任何风险 。
我们要遵循“有独立负责的岗位”和“操作时存在风险隐患”两个标准 , 从大量的功能点中 , 找出少量但必需要做权限控制的功能点 。
优惠券通常由运营人员管理;在优惠券列表中 , 添加优惠券功能 , 通常由运营岗位的员工来操作;添加优惠券时 , 一旦配置错误 , 可能会给公司带来较大损失;优惠券列表中的添加优惠券功能 , 应该要做特定的权限控制 , 而不是默认授权给所有用户 。
而查看优惠券列表 , 没有特定负责的岗位 , 也不存在风险隐患;因此 , 查看优惠券列表功能 , 可以默认授权给全部用户 , 不需要做特定权限控制 。
2)给权限准确命名在给用户授权时 , 我们需要通过权限名称理解该权限控制的内容;给权限命名的准确度 , 直接影响后期给用户授权的效率;命名准确 , 能避免不必要的错误授权 。
“分配权限”的权限 , 可能会授权给部门领导 , 他们不一定理解专业词汇;可以很轻松地理解“添加优惠券”权限的含义 , 但无法理解什么是“获取缓存” , 即便知道“缓存”的含义 , 也无法确定是什么功能的缓存 。

在给权限命名时 , 要注意以下3点:

  1. 避免研发视角的专用词汇 。 如:缓存、队列等;
  2. 使用动宾结构 , 描述完整 。 活动的详细信息 , 应该命名为“查看活动详情” , 而不是简写为“查看”或“活动详情”;
  3. 同一个功能模块或页面中的权限 , 不要重名;如推文列表中 , 查看推文在前端的展示效果和查看推文内容 , 不要都可以命名为“查看推文” 。
3)对权限进行分组管理在对用户进行功能权限分配时 , 需要从权限清单中找出需要授权的权限;若对权限进行合理的分组管理 , 就能使权限清单的管理和权限分配变得非常方便 。
功能点归属于各个模块、页面 , 而功能权限是对功能点进行权限控制;与此同时 , 在给用户授权时 , 我们很清楚地知道 , 这个功能点属于某个模块、某个页面;因此 , 按其所属模块和页面对其进行分组 , 是最自然的分组方式 。
将“添加优惠券”权限 , 分组到“会员营销-优惠券列表”中;在给运营人员分配“添加优惠券”权限时 , 可以直接通过该功能的路径 , 在权限清单中快速找出 , 完成授权 。
如果没有分组 , 就只能从无数个功能权限中搜寻 , 效率极其低下 。
四、数据权限

多个不同或相同岗位的员工都拥有同一个功能的权限 , 但该功能产生的数据 , 每个员工并不需要看到所有数据 , 而只能看到一部分 。
限制用户在查看某类数据时 , 能查看到的数据范围 , 称之为数据权限控制 。


推荐阅读