权限往往关系数据安全、信息隐私、组织层级。越大的公司，访问权限越重要，重要到WIFI不能随意访问。权限在管理后台配置。小项目初创之期，管理后台最不被重视，因为内部使用，开发时连原型都没有，交互体验更是让使用者叫苦连天。
权限的背后
初创项目的小后台，在实现基础功能基础和权限并重。权限往往对应线下部门，比如销售和客服，他们有不同任务，知晓不同的信息，业务和权力相伴随；后台权限只是把信息触点搬到线上。执行不同任务，只看到自己需要操作的界面，简洁页面和操作路径，做起来更高效；并且避免误操作不属于自己的业务。还有些团队，诸如外包等临时协作者加入时，可见可点会与正式团队区分，也需要区别对待。
设计最小权限
导航先行。如果规划时，管理后台导航层级不清晰，极端情况如无层级平铺，新增一个功能，加一个入口。这样不但运营效率低，还让后续增加功能时开发困难。不合理的导航，同样权限配置带来负担，因为颗粒度最粗的权限是导航入口。
最简单易实现的权限，以一级导航为颗粒度来组织，组织之前，先介绍主流的权限系统模型：Role-based access control
这个模型中，有三个元素：
- 权限：可以获取的信息或执行的操作
- 角色：一个角色，可拥有多个权限
- 账户：成员用账户登陆管理后台，账户对应角色
如果层级比较深，业务线条多，可以增加‘部门’，用以抽象角色，方便更高效配置。比如销售部门下，有助理和经理两个角色，他们拥有销售部共同的权限，也拥有各自角色不同权限，助理只能看到自己的销售额，经理可以看到部门销售总额。
你要的所有权限
模型中权限这个元素，按颗粒度从大到小，可以分为：
- 导航：由路由控制，是否可以访问一组页面
- 页面：是否可以访问某个页面
- 操作：访问某个页面时，按钮是否可以见，可否增删改查
- 字段：页面中某个字段是否可见、是否可编辑
导航权限最好实现，适用简单管理后台上线初期，协作者少的项目。比如电商业务开始只有商品和客服两组人，商品要管理品类、上传编辑商品、发起折扣；客户要回复留言、查看购买记录。如此组织，可将‘商品模块’和‘客服模块’的权限以导航组织，一级导航下整组页面，所有数据可见，所有操作可执行。只是和开发商量好，设计数据结构和逻辑规则时考虑扩展性，准备好未来细化到操作甚至字段级别的颗粒度。
操作级别的权限，如果技术是微服务架构，可以做成以url控制操作。比如按钮点击时，访问url，不同权限，可访问不同url；未授权时点击按钮操作无效。若希望按钮完全不可见，需要前端增加判断。
字段级别，是最精细的权限控制。比如电销人员浏览客户信息时，电话号码不可见，客服人员看到客户销售订单时，销售金额不可见；权限设计时，需要隐藏页面上相应字段。
任意组合权限，给谁？
上述这些不同颗粒度权限，相互组合之后，分配给不同角色。比如电商中，创建以一个角色‘商品运营’，这个角色拥有权限可以这样描述：可以访问和编辑‘商品’一级导航下所有页面。因为业务线上不止一个员工，‘商品运营’这个角色，可以有多个人承担；在这些员工自己账号下，分配‘商品运营’角色。
用角色作为权限和账号的中介，最大好处在一次批量配置，不用每个账号单独配置。
界面怎么画？
如果只要导航级别权限，其实只需要两个页面。一个角色页面，一个账户页面。角色页面主体是角色列表，可新建角色，新建时勾选权限。账户页面主体是账户列表，可新建账户，新建时选择账户对应的角色。
更多具体细节，可以看SAAS产品的帮助文档，因为是给客户用的，文档会有教科书级别的页面和描述，比如某CRM产品权限模块使用说明：
如果员工没有某对象“查看列表”的权限，则该对象的功能入口会被隐藏
如果员工没有某对象的操作点权限，则在对象页面上隐藏相应操作按钮
如果员工没有某对象的指定字段的可见权限，则在对象页面上隐藏相应字段
网友评论