itl group 權限列表 con 簡化 項目代碼 -s 當前 rtm

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

OA系統權限管理設計方案
不同職責的人員，對於系統操作的權限應該是不同的。優秀的業務系統，這是最基本的功能。
可以對“組”進行權限分配。對於一個大企業的業務系統來說，如果要求管理員為其下員工逐一分配系統操作權限的話，是件耗時且不夠方便的事情。所以，系統中就提出了對“組”進行操作的概念，將權限一致的人員編入同一組，然後對該組進行權限分配。
權限管理系統應該是可擴展的。它應該可以加入到任何帶有權限管理功能的系統中。就像是組件一樣的可以被不斷的重用，而不是每開發一套管理系統，就要針對權限管理部分進行重新開發。
滿足業務系統中的功能權限。傳統業務系統中，存在著兩種權限管理，其一是功能權限的管理，而另外一種則是資源權限的管理，在不同系統之間，功能權限是可以重用的，而資源權限則不能。

針對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這兩個權限代碼的權限
用戶權限字符串：
根據用戶授權表的角色代碼、職位代碼、項目代碼得到權限字符串及表中直接分配的權限字符串組合成一個用戶的所有權限字符串集合。

頂

0

踩

OA系統權限管理設計方案