天天看點

OA系統權限管理設計(轉載)

任何系統都離不開權限的管理,有一個好的權限管理子產品,不僅使我們的系統操作自如,管理友善,也為系統添加亮點。

l

不同職責的人員,對于系統操作的權限應該是不同的。優秀的業務系統,這是最基本的功能。

可以對“組”進行權限配置設定。對于一個大企業的業務系統來說,如果要求管理者為其下員工逐一配置設定系統操作權限的話,是件耗時且不夠友善的事情。是以,系統中就提出了對“組”進行操作的概念,将權限一緻的人員編入同一組,然後對該組進行權限配置設定。

權限管理系統應該是可擴充的。它應該可以加入到任何帶有權限管理功能的系統中。就像是元件一樣的可以被不斷的重用,而不是每開發一套管理系統,就要針對權限管理部分進行重新開發。

滿足業務系統中的功能權限。傳統業務系統中,存在着兩種權限管理,其一是功能權限的管理,而另外一種則是資源權限的管理,在不同系統之間,功能權限是可以重用的,而資源權限則不能。

針對OA系統的特點,權限說明:

權限

在系統中,權限通過子產品+動作來産生,子產品就是整個系統中的一個子子產品,可能對應一個菜單,動作也就是整個子產品中(在B/S系統中也就是一個頁面的所有操作,比如“浏覽、添加、修改、删除”等)。将子產品與之組合可以産生此子產品下的所有權限。

權限組

為了更友善的權限的管理,另将一個子產品下的所有權限組合一起,組成一個“權限組”,也就是一個子產品管理權限,包括所有基本權限操作。比如一個權限組(使用者管理),包括使用者的浏覽、添加、删除、修改、稽核等操作權限,一個權限組也是一個權限。

角色

權限的集合,角色與角色之間屬于平級關系,可以将基本權限或權限組添加到一個角色中,用于友善權限的配置設定。

使用者組

将某一類型的人、具有相同特征人組合一起的集合體。通過對組授予權限(角色),快速使一類人具有相同的權限,來簡化對使用者授予權限的繁瑣性、耗時性。使用者組的劃分,可以按職位、項目或其它來實作。使用者可以屬于某一個組或多個組。

通過給某個人賦予權限,有4種方式(參考飛思辦公系統)

A.

通過職位

a)

在職位中,職位成員的權限繼承目前所在職位的權限,對于下級職位擁有的權限不可繼承。

b)

執行個體中:如前台這個職位,對于考勤查詢有權限,則可以通過對前台這個職位設定考勤查詢的浏覽權,使他們有使用這個對象的權限,然後再設定個,考勤查詢權(當然也可以不設定,預設能進此子產品的就能查詢),則所有前台人員都擁有考勤查詢的權利。

B.

通過項目

在項目中,項目成員的權限來自于所在項目的權限,他們同樣不能繼承下級項目的權限,而對于項目組長,他對項目有全權,對下級項目也一樣。

執行個體中:在項目中,項目成員可以對項目中上傳文檔,檢視本項目的文檔,可以通過對項目設定一個對于本項目的浏覽權來實作進口,這樣每個成員能通路這個項目了,再加上項目文檔的上傳權和檢視文檔權即可。

c)

對于組長,因為可以賦予組長一個組長權(組長權是個特殊的權限,它包含其他各種權限的一個權限包),所有組長對于本項目有全權,則項目組長可以對于項目文檔檢視,審批,删除,恢複等,這些權限對于本項目的下級項目依然有效。

C.

通過角色

角色中的成員繼承角色的權限,角色與角色沒有上下級關系,他們是平行的。通過角色賦予權限,是指沒辦法按職位或項目的分類來賦予權限的另一種方式,如:系統管理者,資料備份員…

執行個體中:對于本系統中,全體人員應該預設都有的子產品,如我的郵件,我的檔案,我的日志,我的考勤……,這些子產品系統成員都應該有的,我們建立一個角色為系統預設角色,把所有預設通路的子產品的浏覽權加入到裡面去,則系統成員都能通路這些子產品。

D.

直接指定

直接指定是通過對某個人具體指定一項權限,使其有使用這個權限的能力。直接指定是角色指定的一個簡化版,為了是在建立像某個項目的組長這種角色時,省略建立角色這一個步驟,使角色不至于過多。

執行個體中:指定某個項目的組長,把組長權指定給某個人。

針對職位、項目組:

如果用添加新員工,員工調換職位、項目組,滿足了員工會自動繼承所在職位、項目組的權限,不需要重新配置設定權限的功能。

使用者管理

使用者可以屬于某一個或多個使用者組,可以通過對使用者組授權,來對組中的所有使用者進行權限的授予。一個使用者可以屬于多個項目組,或擔任多個職位。

授權管理

将一個基本權限或角色授予使用者或使用者組,使使用者或使用者組擁有授予權限的字元串,如果角色、職位、項目中存在相同的基本權限,則取其中的一個;如脫離角色、職位、項目組,隻是取消使用者或使用者組的中此角色、職位、項目組所授予的權限。使用者所擁有的權限是所有途徑授予權限的集合。管理者使用者可以檢視每個使用者的最終權限清單。

權限管理

基本操作權限與權限組(基本操作權限的集合)的管理。

OA系統權限管理設計(轉載)

實體資料模型圖如下:

OA系統權限管理設計(轉載)

根據以上設計思想,權限管理總共需要以下基本表:

tb_User:使用者資訊基本表;

tb_Department:部門表;

tb_Company:公司表;

tb_Module:系統子產品表;

tb_Action:系統中所有操作的動作表;

tb_Permit:由tb_Module與tb_Action兩表結合産生的系統基本權限表;

tb_Permit_Group:權限組表,将一子產品的中的所有權限劃分一個權限組中,可以通過權限組授予使用者權限;

tb_Role:角色表,基本權限的集合。無上級與下級之分;

tb_Position:職位表,有上級與下級之分;

tb_Project:項目組表,

tb_Role_Permit:角色授權表;

tb_Postion_Permit:職位授權表;

tb_Project_Permit:項目授權表;

tb_Project_User:項目成員表,IsLead字段代表此成員為項目組長;

tb_Postion_User:職位成員表;

tb_User_Permit:使用者授權表,使用者ID與角色、職位、項目及直接授予的權限串表;

權限的産生:

由tb_Module中的ModuleCode與tb_Action中的ActionCode組成

權限代碼PermitCode=ModuleCode+ActionCode。

執行個體:ModuleCode=0101,ActionCode=01,則PermitCode=010101。

權限值則有ModuleValue與ActionCode組合而成,采用下劃線來連接配接。

執行個體:ModuleValue=Sys_User,ActionValue=AdD,PermitValue= Sys_User_Add

權限組:

包括一組同一子產品下的權限的組合,如管理使用者包括基本的權限:添加、删除、修改、檢視等,将這些組合起來構成一個使用者組——“使用者管理”權限組。其它類似。隻是為了更友善的檢視系統權限與權限的配置設定。

執行個體:如管理使用者的權限代碼為010101à檢視使用者,010102à添加使用者,010103à删除使用者,010104à修改使用者,010105à稽核使用者等,将這些基本權限組合起來一個集合而構成了“使用者管理”權限組。

角色、職位、項目:

也就是按特定的需要劃分一種權限的集合。使用角色授權表、職位授權表、項目授權表來實作。授權表中存放的是權限代碼PermitCode,而不是權限組的GroupCode代碼。

使用者授權:

由使用者授權表來實作,使用者授權表中的RoleCode、PositionCode、ProjectCode分别是角色表中RoleCode組成的串、職位表PositionCode組成的串、ProjectCode組成的串。與角色授權表中的角色代碼RoleCode、職位授權表中PositionCode、項目授權表中的ProjectCode不對應(不是主表與從表之間外鍵關系)。

進而能夠實作了一個使用者可以擁有多個角色、多個職位、多個項目的情況。

使用者授權表中的PermitCode為直接授權的權限代碼串,直接給使用者配置設定權限。

執行個體:

使用者ID為UserId=1的使用者權限授權表的記錄為:

RoleCode=001,003

PostionCode = 001,002

ProjectCode=001,005

PermitCode = 010101,020102

表明此使用者擁有兩個角色,代碼為001和003,并繼承這兩個角色的權限;

擔任兩個職位,代碼為001與002,并繼承兩個職位的權限;

屬于兩個項目組中的成員,項目代碼為001與005,并繼承兩個項目中的權限。

直接指定給使用者的權限為010101與010102這兩個權限代碼的權限

使用者權限字元串:

根據使用者授權表的角色代碼、職位代碼、項目代碼得到權限字元串及表中直接配置設定的權限字元串組合成一個使用者的所有權限字元串集合。

原文釋出時間為:2010-05-25

繼續閱讀