二. 用戶角色權(quán)限系統(tǒng)建設的三大模塊

 

1. 用戶管理

 

用戶管理中的用戶主要是功能系統(tǒng)的使用者，這些用戶是一個一個的員工個體，這些個體往往從兩個維度來進行劃分：行政關(guān)系(部門架構(gòu))、業(yè)務部門(業(yè)務架構(gòu))。用戶管理就是在此兩個維度來給員工個體進行關(guān)聯(lián)性的初步分群或者分組。按照行政部門或者按照業(yè)務線部門劃分后，對應部門或者小組內(nèi)的用戶有著基本相似的系統(tǒng)功能使用需求和權(quán)限等級;

 

2. 角色管理

 

(1)角色管理

 

角色往往是基于業(yè)務管理需求而預先在系統(tǒng)中設定好的固定標簽，每個角色對應明確的系統(tǒng)權(quán)限，其所擁有的系統(tǒng)權(quán)限一般不會隨意更改，并且角色也不會隨著用戶的被添加和被移除而進行改變，相較于用戶管理而言更加穩(wěn)定;

 

(2)自動賦權(quán)：用戶自動進入角色

 

如果角色與行政關(guān)系下的組織部門存在綁定關(guān)系，那么如果一個用戶進入到該組織部門后，該用戶會自動被加入到對應的角色中，并且擁有該角色所有的系統(tǒng)權(quán)限。如一個財務人員【小張】入職財務部后，那么該用戶無需進行額外的授權(quán)即可在對應財務報表系統(tǒng)查看該部門員工可查看的財務數(shù)據(jù)報表和對應的操作權(quán)限(比如操作財務審批等);

 

(3)角色賦權(quán)：用戶被添加進角色

 

業(yè)務是不斷創(chuàng)新和發(fā)展的，隨著業(yè)務的發(fā)展，會有越來越多的新的角色被設置和創(chuàng)建，比如公司新啟動了一個企業(yè)團餐項目，項目部橫向的從各個部門找了多個員工組建項目團隊，并且該項目的業(yè)務權(quán)限也只是授權(quán)給這批員工可查看和操作，那么，在此項目中，會產(chǎn)生一個新的角色 “ 財務1 ”，系統(tǒng)高級管理員會把從財務部門選中的財務【小張】添加到“ 財務1 ”這個角色中，那么【小張】即可獲得查看企業(yè)團餐項目業(yè)務數(shù)據(jù)報表和操作的權(quán)限。這種權(quán)限的授予無法通過用戶行政關(guān)系的自動綁定來實現(xiàn);

 

(4)角色繼承：角色權(quán)限的繼承

 

權(quán)限可以是獨有的，也可以是繼承的。每個角色都有自己的權(quán)限集，角色繼承其實也就是繼承父系角色的權(quán)限，一般角色在繼承其父系角色的全部權(quán)限的基礎(chǔ)上增加擁有一些自己的權(quán)限。而系統(tǒng)角色繼承往往存在于用戶分級管理比較明確的團隊或者公司;

 

(5)角色互斥：角色包含的權(quán)限互斥

 

角色互斥的業(yè)務背景：當一個業(yè)務流程由于風控的原因，需要將其操作給劃分成分開的幾個步驟時，需要給這幾個不同的步驟授權(quán)不同的角色，并且這些角色之間需要進行互斥。比如大額財務報銷審批流程，財務人員【小張】擁有了審批人權(quán)限后，就無法將審核確認的權(quán)限再授予小張，以此來規(guī)避一個人完成大額報銷而帶來的財務風險;

 

(6)臨時角色

 

臨時角色往往是針對特殊群體設置的，比如公司有特殊訪問團隊蒞臨，需要給這些特殊的客戶一些臨時身份來體驗某些功能操作。那么把這些人添加到部門的組織架構(gòu)中顯然是不合適的，因為這些人只是臨時的擺放者，不是企業(yè)員工;其次，這些客戶需要體驗的功能操作往往是橫跨多個業(yè)務模塊和產(chǎn)品線的(比較繁雜)，一般公司并沒有現(xiàn)成的固定角色符合擁有客戶所需的全部操作權(quán)限，因此需要給這些客戶開設臨時角色，并且支持給臨時角色最大的權(quán)限選擇空間;

 

(7) 黑白名單。

 

以上就是小編對于網(wǎng)站搭建后臺用戶角色權(quán)限管理系統(tǒng)的模板的分析。