OA系統許可權管理設計方案

由於公司的大規模發展，應上層要求oa系統要跟上發展的步伐，我決定把系統重做一遍。

現在做前期系統分析，目前遇到乙個困難:許可權設計方案。。

不同職責的人員，對於系統操作的許可權應該是不同的。優秀的業務系統，這是最基本的功能。

l 可以對「組」進行許可權分配。對於乙個大企業的業務系統來說，如果要求管理員為其下員工逐一分配系統操作許可權的話，是件耗時且不夠方便的事情。所以，系統中就提出了對「組」進行操作的概念，將許可權一致的人員編入同一組，然後對該組進行許可權分配。

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

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

針對oa系統的特點，許可權說明：

許可權

在系統中，許可權通過模組+動作來產生，模組就是整個系統中的乙個子模組，可能對應乙個選單，動作也就是整個模組中（在b/s系統中也就是乙個頁面的所有操作，比如「瀏覽、新增、修改、刪除」等）。將模組與之組合可以產生此模組下的所有許可權。

許可權組

為了更方便的許可權的管理，另將乙個模組下的所有許可權組合一起，組成乙個「許可權組」，也就是乙個模組管理許可權，包括所有基本許可權操作。比如乙個許可權組（使用者管理），包括使用者的瀏覽、新增、刪除、修改、審核等操作許可權，乙個許可權組也是乙個許可權。

角色

許可權的集合，角色與角色之間屬於平級關係，可以將基本許可權或許可權組新增到乙個角色中，用於方便許可權的分配。

使用者組

將某一型別的人、具有相同特徵人組合一起的集合體。通過對組授予許可權（角色），快速使一類人具有相同的許可權，來簡化對使用者授予許可權的繁瑣性、耗時性。使用者組的劃分，可以按職位、專案或其它來實現。使用者可以屬於某乙個組或多個組。

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

a.通過職位

a) 在職位中，職位成員的許可權繼承當前所在職位的許可權，對於下級職位擁有的許可權不可繼承。

b)例項中：如前台這個職位，對於考勤查詢有許可權，則可以通過對前台這個職位設定考勤查詢的瀏覽權，使他們有使用這個物件的許可權，然後再設定個，考勤查詢權（當然也可以不設定，預設能進此模組的就能查詢），則所有前台人員都擁有考勤查詢的權利。

b.通過專案

a)在專案中，專案成員的許可權來自於所在專案的許可權，他們同樣不能繼承下級專案的許可權，而對於專案組長，他對專案有全權，對下級專案也一樣。

b)例項中：在專案中，專案成員可以對專案中上傳文件，檢視本專案的文件,可以通過對專案設定乙個對於本專案的瀏覽權來實現進口，這樣每個成員能訪問這個專案了，再加上專案文件的上傳權和檢視文件權即可。

c)對於組長，因為可以賦予組長乙個組長權（組長權是個特殊的許可權，它包含其他各種許可權的乙個許可權包），所有組長對於本專案有全權，則專案組長可以對於專案文件檢視，審批，刪除，恢復等，這些許可權對於本專案的下級專案依然有效。

c.通過角色

a)角色中的成員繼承角色的許可權，角色與角色沒有上下級關係，他們是平行的。通過角色賦予許可權，是指沒辦法按職位或專案的分類來賦予許可權的另一種方式，如：系統管理員，資料備份員…

b)例項中：對於本系統中，全體人員應該預設都有的模組，如我的郵件，我的文件，我的日誌，我的考勤……，這些模組系統成員都應該有的，我們建立乙個角色為系統預設角色，把所有預設訪問的模組的瀏覽權加入到裡面去，則系統成員都能訪問這些模組。

d.直接指定

a)直接指定是通過對某個人具體指定一項許可權，使其有使用這個許可權的能力。直接指定是角色指定的乙個簡化版，為了是在建立像某個專案的組長這種角色時，省略建立角色這乙個步驟，使角色不至於過多。

b)例項中：指定某個專案的組長，把組長權指定給某個人。

針對職位、專案組：

如果用新增新員工，員工調換職位、專案組，滿足了員工會自動繼承所在職位、專案組的許可權，不需要重新分配許可權的功能。

使用者管理

使用者可以屬於某乙個或多個使用者組，可以通過對使用者組授權，來對組中的所有使用者進行許可權的授予。乙個使用者可以屬於多個專案組，或擔任多個職位。

授權管理

將乙個基本許可權或角色授予使用者或使用者組，使使用者或使用者組擁有授予許可權的字串，如果角色、職位、專案中存在相同的基本許可權，則取其中的乙個；如脫離角色、職位、專案組，只是取消使用者或使用者組的中此角色、職位、專案組所授予的許可權。使用者所擁有的許可權是所有途徑授予許可權的集合。管理員使用者可以檢視每個使用者的最終許可權列表。

許可權管理

基本操作許可權與許可權組（基本操作許可權的集合）的管理。

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這兩個許可權**的許可權

使用者許可權字串：

根據使用者授權表的角色**、職位**、專案**得到許可權字串及表中直接分配的許可權字串組合成乙個使用者的所有許可權字串集合。

OA系統許可權管理設計方案

OA系統許可權管理設計方案

OA系統許可權管理設計方案

OA系統許可權管理設計方案

相關推薦