在賬戶體系設(shè)計中，賬戶關(guān)系可能存在多層級，例如：廠商（一汽大眾）—> 經(jīng)銷商門店（北望路4S店）—> 員工賬戶（員工）。

背景

假設(shè)有一個【報表域】需要展示賬戶的經(jīng)營概覽信息。

廠商：看到的是所有經(jīng)銷商門店的匯總以及明細信息；
門店：看到的是所有員工賬戶的匯總以及明細信息；
員工：看到的是自己的匯總信息；

廠商（廠商Id）下可以擁有N個廠商管理員（userId）角色；
門店（門店Id）下可以擁有N個門店管理員（userId）角色；
員工子賬戶（員工userId）是最小的粒度；

員工的存在流動性，即一個員工在不同的時期可以在多個門店工作。
一個管理員既可以是廠商管理員，也可以是門店管理員，也可以是員工賬戶；

賬戶層級關(guān)系.png

訴求

廠商管理員可以下鉆到別的門店賬戶中，查詢具體門店賬戶的信息；
廠商管理員如果是門店管理員的話，那么他可以切換到自己的門店中；
如果是離職員工賬戶的話，那么前門店可以查詢它離職前的數(shù)據(jù)，所在職的門店可以查詢它入職后的數(shù)據(jù)；

解法

如何實現(xiàn)下鉆功能

下鉆功能類似于代登錄，但是代登錄的實現(xiàn)非常麻煩，會涉及到權(quán)限、安全等控制。那么我們?nèi)绾螌崿F(xiàn)下鉆的功能呢？

（1）后端協(xié)議的制定

假設(shè)廠商管理員登錄后，他想查詢下鉆到員工賬戶中，查詢員工賬戶的具體信息。故在設(shè)計的時候，我們需要定義如下字段：

loginUserId：當前登錄者的userId；
loginUserRole：當前登錄者的角色；
currentOptId：當前被操作者的賬號（廠商id、門店id、員工userId）；
currentOptRole：當前被操作者的角色；

登錄者查詢什么樣的數(shù)據(jù)，查詢的是被操作者賬戶的數(shù)據(jù)，而非登錄者的信息，這樣就可以實現(xiàn)下鉆查詢。

（2）和前端的交互設(shè)計：

這幾個字段前端是否需要感知？我理解是不需要的，前端點擊下鉆/切換角色時，調(diào)用后端接口，后端將這些信息種植到cookie中，前端后續(xù)的請求將基于這些cookie，后端在解析這些cookie，從而定位到當前被操作者的信息

（3）多層下鉆如何處理

在上面的設(shè)計中，只是保留了登錄者userId和當前被操作者optId。但是會存在數(shù)據(jù)問題。舉個例子

登錄者：廠商管理員userId；
被操作者：員工A、子賬戶；

廠商管理員通過下鉆門店C，在下鉆到員工A（已離職）。

但是我們在參數(shù)中只能獲取到員工賬戶。那么無法定位到當前查詢的是員工A在門店C的數(shù)據(jù)，還是在門店B的數(shù)據(jù)。

故需要優(yōu)化協(xié)議，將下鉆的路徑都記錄下來，這樣就可以實現(xiàn)精確查詢。

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

currentOptInfo：
  currentOptId：當前被操作者的賬號（廠商id、門店id、員工userId）；
  currentOptRole：當前被操作者的角色；

（4）下鉆&切角色【終版設(shè)計】

在原有的設(shè)計中，登錄者如何快速實現(xiàn)切換角色？直接覆蓋loginUserRole字段即可。但是假設(shè)下鉆后，肯定無法切換loginUserRole中的角色，那么我們?nèi)绾螌崿F(xiàn)呢？

切換角色本身可以是一種下鉆，只不過下鉆是逐層下鉆，而切角色可以跳級切換。

假設(shè)用戶是廠商管理員登錄，cookie的格式

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

假設(shè)用戶是廠商管理員登錄，切換角色到子賬戶。
注意，此時前端會傳子賬戶userId，但是后端種cookie的時候需要補全門店id

{
  "loginUserId":"登錄者的userId",
  "loginUserRole":"1",
  "currentOptInfos":[{
    "currentOptId":"廠商id",
    "currentOptRole":"1"
  },{
    "currentOptId":"門店id",
    "currentOptRole":"2"
  },{
    "currentOptId":"員工userId",
    "currentOptRole":"3"
  }
  ]
}

假設(shè)用戶是廠商管理員登錄，切換到子賬戶后，有切換到廠商角色；
注意：需要進行回刪，currentOptInfos只暴露一條數(shù)據(jù)；

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

假設(shè)用戶是廠商管理員登錄，切換到門店角色后，在下鉆到員工B上；

{
  "loginUserId":"登錄者的userId",
  "loginUserRole":"1",
  "currentOptInfos":[{
    "currentOptId":"廠商id",
    "currentOptRole":"1"
  },{
    "currentOptId":"門店id",
    "currentOptRole":"2"
  },{
    "currentOptId":"員工userId-B",
    "currentOptRole":"3"
  }
  ]
}

（5）權(quán)限控制

數(shù)據(jù)表中的記錄是通過：【廠商id+門店id+員工userId】來作為唯一鍵確定一條記錄，假設(shè)用戶傳遞的組合不對，其實是查不到數(shù)據(jù)的。

唯一需要驗證權(quán)限的是，當前登錄者和被操作者（權(quán)限最大）是否有關(guān)系，例如：登錄者的userId是否是門店的管理員？