系統中員工登錄其帳戶後的權限顯示方法與流程
2023-06-07 15:02:26
本發明涉及erp等管理軟體系統的用戶權限顯示方法，特別是涉及一種系統中員工登錄其帳戶後的權限顯示方法。
背景技術：
基於角色的訪問控制（rbac）是近年來研究最多、思想最成熟的一種資料庫權限管理機制，它被認為是替代傳統的強制訪問控制（mac）和自主訪問控制（dac）的理想候選。基於角色的訪問控制（rbac）的基本思想是根據企業組織視圖中不同的職能崗位劃分不同的角色，將資料庫資源的訪問權限封裝在角色中，用戶通過被賦予不同的角色來間接訪問資料庫資源。
在大型應用系統中往往都建有大量的表和視圖，這使得對資料庫資源的管理和授權變得十分複雜。由用戶直接管理資料庫資源的存取和權限的收授是十分困難的，它需要用戶對資料庫結構的了解非常透徹，並且熟悉sql語言的使用，而且一旦應用系統結構或安全需求有所變動，都要進行大量複雜而繁瑣的授權變動，非常容易出現一些意想不到的授權失誤而引起的安全漏洞。因此，為大型應用系統設計一種簡單、高效的權限管理方法已成為系統和系統用戶的普遍需求。
基於角色的權限控制機制能夠對系統的訪問權限進行簡單、高效的管理，極大地降低了系統權限管理的負擔和代價，而且使得系統權限管理更加符合應用系統的業務管理規範。
然而，傳統基於角色的用戶權限管理方法均採用「角色對用戶一對多」的關聯機制，其「角色」為組/類性質，即一個角色可以同時對應/關聯多個用戶，角色類似於崗位/職位/工種等概念，這種關聯機制下對用戶權限的授權基本分為以下三種形式：
1、如圖1所示，直接對用戶授權，缺點是工作量大、操作頻繁且麻煩；
2、如圖2所示，對角色（類/組/崗位/工種性質）進行授權（一個角色可以關聯多個用戶），用戶通過角色獲得權限；
3、如圖3所示，以上兩種方式結合。
以上的表述中，2、3均需要對類/組性質的角色進行授權，而通過類/組/崗位/工種性質的角色進行授權的方式有以下缺點：
1、用戶權限變化時的操作難：在實際的系統使用過程中，經常因為在運營過程中需要對用戶的權限進行調整，比如：在處理員工權限變化的時候，角色關聯的某個員工的權限發生變化，我們不能因該個別員工權限的變化而改變整個角色的權限，因為該角色還關聯了其他權限未變的員工。因此為了應對該種情況，要麼創建新角色來滿足該權限發生變化的員工，要麼對該員工根據權限需求直接授權（脫離角色）。以上兩種處理方式，在角色權限較多的情況下對角色授權不僅所需時間長，而且容易犯錯，使用方操作起來繁瑣又麻煩，也容易出錯導致對系統使用方的損失。
2、要長期記住角色包含的具體權限難：若角色的權限功能點比較多，時間一長，很難記住角色的具體權限，更難記住權限相近的角色之間的權限差別，若要關聯新的用戶，無法準確判斷應當如何選擇關聯。
3、因為用戶權限變化，則會造成角色創建越來越多（若不創建新角色，則會大幅增加直接對用戶的授權），更難分清各角色權限的具體差別。
4、調崗時，若要將被調崗用戶的很多個權限分配給另外幾個用戶承擔，則處理時必須將被調崗用戶的這些權限區分開來，分別再創建角色來關聯另外幾個用戶，這樣的操作不僅複雜耗時，而且還很容易發生錯誤。
現有的erp等管理系統中，員工登錄其帳戶後不能清楚地區分的了解自己各崗位/工位號的權限，不利於工作的開展。此外，現有的erp等管理系統中存在多個員工在工作中使用同一個用戶進行操作的情況，此時系統在進行分析時不能簡單、清晰的分析員工的操作行為或痕跡，導致對工作的追本溯源變得很複雜。
技術實現要素：
本發明的目的在於克服現有技術的不足，提供一種系統中員工登錄其帳戶後的權限顯示方法，在員工登錄其帳戶後根據該帳戶關聯的角色清楚地顯示其對應的權限，便於該員工開展工作。
本發明的目的是通過以下技術方案來實現的：系統中員工登錄其帳戶後的權限顯示方法，包括：
員工根據其對應的帳戶登錄系統；
系統向該員工顯示第一信息或第二信息，所述第一信息包括所述帳戶關聯的全部角色和各角色對應的權限，所述第二信息包括所述帳戶關聯的全部角色的主要角色和該主要角色對應的權限。
優選的，所述權限顯示方法還包括：員工選擇顯示第一信息或第二信息。
優選的，系統向員工顯示第一信息時，該員工選擇第一信息中的一個角色和該角色對應的權限進行顯示；系統向員工顯示第二信息時，該員工選擇其對應帳戶關聯的所有角色中除主要角色外的一個角色及該角色對應的權限進行顯示。
優選的，員工登錄其對應的帳戶後，僅能在系統當前顯示給該員工的角色的權限下進行操作。
優選的，每個角色是獨立的個體，而非組/類，同一時段一個角色只能關聯唯一的帳戶，而一個帳戶關聯一個或多個角色；所述角色創建時必須選擇一個部門，角色一旦創建後則該角色歸屬於該部門，根據角色的工作內容對角色進行授權，且該角色的名稱在該部門下唯一，該角色的編號在系統中唯一；所述帳戶跨部門調崗時，取消帳戶與原部門內的角色的關聯，將帳戶與新部門內的角色進行關聯。
優選的，所述帳戶關聯一個或多個角色時，設置其中一個角色為主要角色。
優選的，所述帳戶能且只能通過其與角色的關聯確定權限，一個員工對應一個帳戶，一個帳戶對應一個員工。
系統中員工登錄其帳戶後的權限顯示方法，包括：
為員工選擇一個已創建、未關聯員工、未凍結的帳戶作為該員工的帳戶，或為該員工單獨創建一個帳戶；
員工根據其對應的帳戶登錄系統；
系統向該員工顯示第一信息或第二信息，所述第一信息包括所述帳戶關聯的全部角色和各角色對應的權限，所述第二信息包括所述帳戶關聯的全部角色的主要角色和該主要角色對應的權限。
優選的，為員工單獨創建一個帳戶的方法為：
選擇該員工的員工表單中的一個在系統中具有唯一性的欄位作為該員工的帳戶；
或，選擇該員工的員工工號作為該員工的帳戶。
所述員工離職後凍結該員工的帳戶；當該用戶再次入職後，解凍該員工此前的帳戶作為該員工的當前帳戶。
本發明的有益效果是：
（1）本發明中，在員工登錄其帳戶後根據該帳戶關聯的角色清楚地顯示其對應的權限，便於該員工開展工作；
（2）本發明中一個員工對應一個帳戶，一個帳戶對應一個員工，從而可以方便的對每個帳戶的操作進行追溯，查得相應的責任人；
（3）本發明中員工的帳戶的創建方法為：選擇一個已創建、未關聯員工、未凍結的帳戶作為該員工的帳戶，或為該員工單獨創建一個帳戶；從而保證了一個員工對應一個帳戶，一個帳戶對應一個員工，不會出現多個員工對應一個帳戶、導致難以對每個帳戶的操作進行追溯的情況；
（4）採用員工的員工表單中的一個在系統中具有唯一性的欄位作為該員工的帳戶；或，選擇該員工的員工工號作為該員工的帳戶；不僅能夠為員工快速創建帳戶，而且創建的帳戶和已有的帳戶不會重複，具有唯一性，有利於對帳戶的操作進行追溯；
（5）員工登錄其對應的帳戶後，僅能在系統當前顯示給該員工的角色的權限下進行操作，有利於在帳戶關聯多個角色時直接顯示不同角色（崗位號/工位號）的相關信息；
（6）傳統的權限管理機制將角色定義為組、工種、類等性質，角色對用戶是一對多的關係，在實際的系統使用過程中，經常因為在運營過程中需要對用戶的權限進行調整，比如：在處理員工權限變化的時候，角色關聯的某個員工的權限發生變化，我們不能因該個別員工權限的變化而改變整個角色的權限，因為該角色還關聯了其他權限未變的員工。因此為了應對該種情況，要麼創建新角色來滿足該權限發生變化的員工，要麼對該員工根據權限需求直接授權（脫離角色）。以上兩種處理方式，在角色權限較多的情況下對角色授權不僅所需時間長，而且容易犯錯，使用方操作起來繁瑣又麻煩，也容易出錯導致對系統使用方的損失。
但在本申請的方法下，因為角色是一個獨立的個體，則可以選擇改變角色權限即可達到目的。本申請的方法，雖然看起來在系統初始化時會增加工作量，但可以通過複製等方法，使其創建角色或授權的效率高於傳統以組為性質的角色，因為不用考慮性質為組的角色在滿足關聯用戶時的共通性，本申請方案會讓權限設置清晰，明了；尤其是在系統使用一段時間後（用戶/角色權限動態變化），該申請方案能為系統使用方大幅度提高系統使用中的權限管理效率，使動態授權更簡單，更方便，更清晰、明了，提高權限設置的效率和可靠性。
（7）傳統以組為性質的角色授權方法容易出錯，本申請方法大幅降低了授權出錯的機率，因為本申請方法只需考慮作為獨立個體的角色，而不用考慮傳統方法下關聯該組性質角色的多個用戶有哪些共通性。即使授權出錯也只影響關聯到該角色的那一個用戶，而傳統以組性質的角色則會影響關聯到該角色的所有用戶。即使出現權限授權錯誤，本申請的修正方法簡單、時間短，而傳統以組性質的角色在修正錯誤時需要考慮關聯到該角色的所有用戶的權限共通性，在功能點多的情況下不僅修改麻煩、複雜，非常容易出錯，且很多情況下只能新創建角色才能解決。
（8）在傳統以組為性質的角色授權方法下，若角色的權限功能點比較多，時間一長，很難記住角色的具體權限，更難記住權限相近的角色之間的權限差別，若要關聯新的用戶，無法準確判斷應當如何選擇關聯。本申請方法的角色本身就具有崗位號/工位號的性質，選擇一目了然。
（9）調崗時，若要將被調崗用戶的很多個權限分配給另外幾個用戶承擔，則處理時必須將被調崗用戶的這些權限區分開來，分別再創建角色來關聯另外幾個用戶，這樣的操作不僅複雜耗時，而且還很容易發生錯誤。
本申請方法則為：被調崗用戶關聯了幾個角色，在調崗時，首先取消用戶與原部門內的角色的關聯（被取消的這幾個角色可以被重新關聯給其他用戶），然後將用戶與新部門內的角色進行關聯即可。操作簡單，不會出錯。
（10）創建角色時，需要選定一個部門，一旦該角色創建完成，則部門不能被更換，角色為什麼不能更換部門：
理由1：因為本申請的角色性質等同於一個工位號/崗位號，不同的工位號/崗位號的工作內容/權限是不一樣的，如銷售部門下的銷售員1角色和技術部門的開發人員1角色是完全不同的兩個工位號/崗位號，其權限是不同的；
理由2：若將銷售員1角色的所屬部門（銷售部）更換為技術部，其銷售人員1這個角色的權限不變，則在技術部存在擁有銷售部權限的一個角色，這樣會導致管理混亂及安全漏洞。
附圖說明
圖1為背景技術中系統直接對用戶進行授權的方式示意圖；
圖2為背景技術中系統對組/類性質角色進行授權的方式示意圖；
圖3為背景技術中系統對用戶直接授權和對組/類性質角色授權相結合的方式示意圖；
圖4為本發明的一種實施方式的流程圖；
圖5為本發明的又一種實施方式的流程圖。
具體實施方式
下面結合附圖進一步詳細描述本發明的技術方案，但本發明的保護範圍不局限於以下所述。
【實施例1】如圖4所示，系統中員工登錄其帳戶後的權限顯示方法，包括：
員工根據其對應的帳戶登錄系統；
系統向該員工顯示第一信息或第二信息，所述第一信息包括所述帳戶關聯的全部角色和各角色對應的權限，所述第二信息包括所述帳戶關聯的全部角色的主要角色和該主要角色對應的權限。
例1：系統中，員工甲對應的帳戶關聯有銷售經理1、生產主管1和財務主管1三個角色，銷售經理1這個角色為該帳戶的主要角色。那麼，員工甲登錄系統後，系統向員工甲顯示銷售經理1、生產主管1和財務主管1，以及這三個角色各自對應的權限，或者系統向員工甲顯示銷售經理1及其對應的權限。
所述權限顯示方法還包括：員工選擇顯示第一信息或第二信息。如例1中，員工甲登錄系統後，系統提供讓員工自行進行角色選擇；員工甲可以選擇顯示所有角色，那麼系統將向員工甲顯示銷售經理1、生產主管1和財務主管1，以及這三個角色各自對應的權限；員工甲也可以選擇顯示主要角色，那麼系統將向員工甲顯示銷售經理1及其對應的權限。
系統向員工顯示第一信息時，該員工選擇第一信息中的一個角色和該角色對應的權限進行顯示；系統向員工顯示第二信息時，該員工選擇其對應帳戶關聯的所有角色中除主要角色外的一個角色及該角色對應的權限進行顯示。
如例1中，系統向員工甲顯示銷售經理1、生產主管1和財務主管1，以及這三個角色各自對應的權限時，員工甲可以選擇切換為顯示生產主管1，則顯示生產主管1對應的權限。系統向員工甲顯示主要角色銷售經理1時，則顯示銷售經理1對應的權限，員工甲可以通過下拉框等形式選擇切換為生產主管1和財務主管1中的一個角色，則顯示所選擇角色對應的權限。
員工登錄其對應的帳戶後，僅能在系統當前顯示給該員工的角色的權限下進行操作。如例1中，如果系統向員工甲顯示的是銷售經理1、生產主管1和財務主管1，以及這三個角色各自對應的權限時，員工甲此時可以執行這三個角色的權限下的所有操作；如果系統向員工甲顯示的是主要角色銷售經理1及其權限時，員工甲此時僅能執行銷售經理1的權限下的操作；如果系統向員工甲顯示的是生產主管1時，員工甲此時僅能執行生產主管1的權限下的操作，如果將顯示的角色由生產主管1切換為財務主管1時，員工甲此時則僅能執行財務主管1的權限下的操作。
每個角色是獨立的個體，而非組/類，同一時段一個角色只能關聯唯一的帳戶，而一個帳戶關聯一個或多個角色。
所述帳戶能且只能通過其與角色的關聯確定權限，一個員工對應一個帳戶，一個帳戶對應一個員工。
角色的定義：角色不具有組/類/類別/崗位/職位/工種等性質，而是一個非集合的性質，角色具有唯一性，角色是獨立存在的獨立個體；在企事業單位應用中相當於崗位號（此處的崗位號非崗位，一個崗位同時可能有多個員工，而同一時段一個崗位號只能對應一個員工）。
舉例：某個公司系統中可創建如下角色：總經理、副總經理1、副總經理2、北京銷售一部經理、北京銷售二部經理、北京銷售三部經理、上海銷售工程師1、上海銷售工程師2、上海銷售工程師3、上海銷售工程師4、上海銷售工程師5……
用戶與角色的關聯關係：若該公司員工張三任職該公司副總經理2，同時任職北京銷售一部經理，則張三需要關聯的角色為副總經理2和北京銷售一部經理，張三擁有了這兩個角色的權限。
傳統角色的概念是組/類/崗位/職位/工種性質，一個角色能夠對應多個用戶。而本申請「角色」的概念相當於崗位號/工位號，也類同於影視劇中的角色：一個角色在同一時段（童年、少年、中年……）只能由一個演員來飾演，而一個演員可能會分飾多角。
所述角色創建時必須選擇一個部門，角色一旦創建後則該角色歸屬於該部門，根據角色的工作內容對角色進行授權，且該角色的名稱在該部門下唯一，該角色的編號在系統中唯一。
所述帳戶跨部門調崗時，取消帳戶與原部門內的角色的關聯，將帳戶與新部門內的角色進行關聯。在創建角色之後，可以在創建用戶的過程中關聯角色，也可以在用戶創建完成後隨時進行關聯。用戶關聯角色後可以隨時解除與角色的關聯關係，也可以隨時建立與其他角色的關聯關係。
所述帳戶關聯一個或多個角色時，設置其中一個角色為主要角色。
【實施例2】如圖5所示，系統中員工登錄其帳戶後的權限顯示方法，包括：
為員工選擇一個已創建、未關聯員工、未凍結的帳戶作為該員工的帳戶，或為該員工單獨創建一個帳戶；
員工根據其對應的帳戶登錄系統；
系統向該員工顯示第一信息或第二信息，所述第一信息包括所述帳戶關聯的全部角色和各角色對應的權限，所述第二信息包括所述帳戶關聯的全部角色的主要角色和該主要角色對應的權限。
例2：系統中存在帳戶a、帳戶b和帳戶c，且帳戶a、帳戶b和帳戶c均沒有關聯員工，帳戶a和帳戶b均沒有被凍結，帳戶c被凍結。那麼可以從帳戶a和帳戶b選擇一個作為員工甲的帳戶；或者，在系統中再創建一個新的帳戶作為員工甲的帳戶。
系統中，員工甲對應的帳戶關聯有銷售經理1、生產主管1和財務主管1三個角色，銷售經理1這個角色為該帳戶的主要角色。那麼，員工甲登錄系統後，系統向員工甲顯示銷售經理1、生產主管1和財務主管1，以及這三個角色各自對應的權限，或者系統向員工甲顯示銷售經理1及其對應的權限。
為員工單獨創建一個帳戶的方法為：選擇該員工的員工表單中的一個在系統中具有唯一性的欄位作為該員工的帳戶；或，選擇該員工的員工工號作為該員工的帳戶。
例3：員工甲的員工表單中有一個員工編號，該員工編號在系統中是唯一的，那麼可以將該員工編號作為員工甲的帳戶；或者，將員工甲的員工工號（該員工工號既可以在員工甲的員工表單中，也可以不在員工甲的員工表單中）作為他的帳戶。
所述員工離職後凍結該員工的帳戶；當該用戶再次入職後，解凍該員工此前的帳戶作為該員工的當前帳戶。
例4：員工甲對應的帳戶為帳戶a，若員工甲離職後，則將帳戶a凍結；若員工甲離職後再入職時，則將帳戶a解凍後作為員工的當前帳戶。
以上所述僅是本發明的優選實施方式，應當理解本發明並非局限於本文所披露的形式，不應看作是對其他實施例的排除，而可用於各種其他組合、修改和環境，並能夠在本文所述構想範圍內，通過上述教導或相關領域的技術或知識進行改動。而本領域人員所進行的改動和變化不脫離本發明的精神和範圍，則都應在本發明所附權利要求的保護範圍內。