<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    隨筆 - 147  文章 - 71  trackbacks - 0
    <2009年2月>
    25262728293031
    1234567
    891011121314
    15161718192021
    22232425262728
    1234567

    常用鏈接

    留言簿(1)

    隨筆分類(146)

    隨筆檔案(147)

    文章分類(28)

    文章檔案(28)

    喜歡的Blog

    搜索

    •  

    最新評論

    閱讀排行榜

    評論排行榜

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

    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這兩個權限代碼的權限

    用戶權限字符串:

           根據用戶授權表的角色代碼、職位代碼、項目代碼得到權限字符串及表中直接分配的權限字符串組合成一個用戶的所有權限字符串集合。

    posted on 2009-02-14 10:18 飛翔天使 閱讀(9602) 評論(7)  編輯  收藏 所屬分類: 軟件設計

    FeedBack:
    # re: OA系統權限管理設計方案 2009-02-14 19:32 heyang
    關注。  回復  更多評論
      
    # re: OA系統權限管理設計方案 2009-06-01 10:26 HiMagic!
    User和Permission之間應該用role關聯,避免關系網太發散。
    Permit code應該用關系表表示,不要把所有code放在一個字段。
    感覺Project的概念應該是一個特殊的Role,與組織上的group不同,以為前者和resource相關,后者不依賴任何項目和權限而存在。  回復  更多評論
      
    # re: OA系統權限管理設計方案 2009-10-27 13:58 式樣
    很好.  回復  更多評論
      
    # re: OA系統權限管理設計方案 2009-11-10 11:30 newPeople
    小弟初學表之間的關聯設計,可以附加上數據模型圖中字段的意思嗎?感激不盡!  回復  更多評論
      
    # re: OA系統權限管理設計方案 2010-01-11 11:55 jimmyhcl
    道友,我認為你的權限值沒有太大的意義  回復  更多評論
      
    # re: OA系統權限管理設計方案 2010-03-04 09:35 mavin
    這文章相當的游泳呀,呵呵,謝謝  回復  更多評論
      
    # re: OA系統權限管理設計方案 2013-09-03 13:38 劍飄紅
    職位和項目屬于部門吧
    不應該與用戶關聯會好點  回復  更多評論
      

    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
    主站蜘蛛池模板: 亚洲成a人片77777老司机| 亚洲中文字幕第一页在线| 亚洲区视频在线观看| ww4545四虎永久免费地址| 亚洲精品免费在线视频| 18级成人毛片免费观看| 中文字幕在线观看亚洲日韩| 成年女人免费碰碰视频| 国产尤物在线视精品在亚洲| 免费又黄又硬又爽大片| www成人免费观看网站| 区久久AAA片69亚洲| 18禁在线无遮挡免费观看网站| 亚洲av午夜成人片精品网站| 三年片在线观看免费观看大全动漫 | 久久国产一片免费观看| 亚洲中文字幕无码久久2017| 精品国产免费一区二区三区香蕉| 久久亚洲免费视频| 国产大片线上免费观看| 爱爱帝国亚洲一区二区三区| 国产自偷亚洲精品页65页| 日韩精品无码专区免费播放| 亚洲天堂免费在线| 亚洲精品乱码久久久久久不卡 | 亚洲中文字幕一二三四区苍井空| 在线jlzzjlzz免费播放| xxxxx做受大片在线观看免费| 亚洲中文久久精品无码| 天天影视色香欲综合免费| 在线视频亚洲一区| 国产成人亚洲综合无码精品| 麻豆最新国产剧情AV原创免费 | 亚洲国产精品VA在线观看麻豆| 免费毛片a在线观看67194| 美女被艹免费视频| 亚洲精品欧洲精品| 又爽又高潮的BB视频免费看 | 七次郎成人免费线路视频| 久久丫精品国产亚洲av不卡| 日韩在线视频免费看|