在账户体系设计中，账户关系可能存在多层级，例如：厂商（一汽大众）—> 经销商门店（北望路4S店）—> 员工账户（员工）。

背景

假设有一个【报表域】需要展示账户的经营概览信息。

厂商：看到的是所有经销商门店的汇总以及明细信息；
门店：看到的是所有员工账户的汇总以及明细信息；
员工：看到的是自己的汇总信息；

厂商（厂商Id）下可以拥有N个厂商管理员（userId）角色；
门店（门店Id）下可以拥有N个门店管理员（userId）角色；
员工子账户（员工userId）是最小的粒度；

员工的存在流动性，即一个员工在不同的时期可以在多个门店工作。
一个管理员既可以是厂商管理员，也可以是门店管理员，也可以是员工账户；

账户层级关系.png

诉求

厂商管理员可以下钻到别的门店账户中，查询具体门店账户的信息；
厂商管理员如果是门店管理员的话，那么他可以切换到自己的门店中；
如果是离职员工账户的话，那么前门店可以查询它离职前的数据，所在职的门店可以查询它入职后的数据；

解法

如何实现下钻功能

下钻功能类似于代登录，但是代登录的实现非常麻烦，会涉及到权限、安全等控制。那么我们如何实现下钻的功能呢？

（1）后端协议的制定

假设厂商管理员登录后，他想查询下钻到员工账户中，查询员工账户的具体信息。故在设计的时候，我们需要定义如下字段：

loginUserId：当前登录者的userId；
loginUserRole：当前登录者的角色；
currentOptId：当前被操作者的账号（厂商id、门店id、员工userId）；
currentOptRole：当前被操作者的角色；

登录者查询什么样的数据，查询的是被操作者账户的数据，而非登录者的信息，这样就可以实现下钻查询。

（2）和前端的交互设计：

这几个字段前端是否需要感知？我理解是不需要的，前端点击下钻/切换角色时，调用后端接口，后端将这些信息种植到cookie中，前端后续的请求将基于这些cookie，后端在解析这些cookie，从而定位到当前被操作者的信息

（3）多层下钻如何处理

在上面的设计中，只是保留了登录者userId和当前被操作者optId。但是会存在数据问题。举个例子

登录者：厂商管理员userId；
被操作者：员工A、子账户；

厂商管理员通过下钻门店C，在下钻到员工A（已离职）。

但是我们在参数中只能获取到员工账户。那么无法定位到当前查询的是员工A在门店C的数据，还是在门店B的数据。

故需要优化协议，将下钻的路径都记录下来，这样就可以实现精确查询。

loginUserId：当前登录者的userId；
loginUserRole：当前登录者的角色；‘
List<currentOptInfo> 当前被操作者的列表（下钻列表）

currentOptInfo：
  currentOptId：当前被操作者的账号（厂商id、门店id、员工userId）；
  currentOptRole：当前被操作者的角色；

（4）下钻&切角色【终版设计】

在原有的设计中，登录者如何快速实现切换角色？直接覆盖loginUserRole字段即可。但是假设下钻后，肯定无法切换loginUserRole中的角色，那么我们如何实现呢？

切换角色本身可以是一种下钻，只不过下钻是逐层下钻，而切角色可以跳级切换。

假设用户是厂商管理员登录，cookie的格式

{
  "loginUserId":"登录者的userId",
  "loginUserRole":"1",
  "currentOptInfos":[{
    "currentOptId":"厂商id",
    "currentOptRole":"1"
   }
  ]
}

假设用户是厂商管理员登录，切换角色到子账户。
注意，此时前端会传子账户userId，但是后端种cookie的时候需要补全门店id

{
  "loginUserId":"登录者的userId",
  "loginUserRole":"1",
  "currentOptInfos":[{
    "currentOptId":"厂商id",
    "currentOptRole":"1"
  },{
    "currentOptId":"门店id",
    "currentOptRole":"2"
  },{
    "currentOptId":"员工userId",
    "currentOptRole":"3"
  }
  ]
}

假设用户是厂商管理员登录，切换到子账户后，有切换到厂商角色；
注意：需要进行回删，currentOptInfos只暴露一条数据；

{
  "loginUserId":"登录者的userId",
  "loginUserRole":"1",
  "currentOptInfos":[{
    "currentOptId":"厂商id",
    "currentOptRole":"1"
  }
  ]
}

假设用户是厂商管理员登录，切换到门店角色后，在下钻到员工B上；

{
  "loginUserId":"登录者的userId",
  "loginUserRole":"1",
  "currentOptInfos":[{
    "currentOptId":"厂商id",
    "currentOptRole":"1"
  },{
    "currentOptId":"门店id",
    "currentOptRole":"2"
  },{
    "currentOptId":"员工userId-B",
    "currentOptRole":"3"
  }
  ]
}

（5）权限控制

数据表中的记录是通过：【厂商id+门店id+员工userId】来作为唯一键确定一条记录，假设用户传递的组合不对，其实是查不到数据的。

唯一需要验证权限的是，当前登录者和被操作者（权限最大）是否有关系，例如：登录者的userId是否是门店的管理员？