前言
上篇文章組織結構與許可權模型設計（一）中，介紹了許可權模型的第一種實現方案，即使用者與角色關聯、角色與許可權關聯，職位作為使用者的乙個標籤顯示，不涉及許可權。這種方案存在乙個問題，通常我們說的許可權，其實是包含兩個維度：操作功能和資料範圍。比如學校班級的班長有檢查同學作業、布置任務的權利，這是說他能操作的功能；另外，班長只對本班級的學生有布置任務的權利，這裡是對資料範圍的限制。
方案二
基於上面的分析，可以認為許可權是由操作功能和資料範圍兩個維度組成的，角色定義使用者的操作功能，職位定義資料範圍。在乙個企業裡面，不同部門的部門經理雖然職位是一樣的（都是部門經理），但是他們所能做的事是不一樣的：開發部的經理管專案開發事項、財務部的經理管理財務收支，對映到系統中，就是說他們的操作功能不一樣。
相對第一種方案，模型沒有發生變化，唯一改變的是對許可權和職位的定義不一樣了。
對於許可權：在方案一中，沒有將許可權細分為操作功能和資料範圍兩個維度，許可權既管操作功能也管資料範圍。在方案二中，許可權只定義操作功能，資料範圍由職位決定。
打個比方，對於檢視工作日誌這個功能。
按方案二實現的話，系統中會有乙個許可權項，叫檢視工作日誌（操作功能），至於檢視誰的工作日誌（資料範圍），則依據成員的職位，如果他是部門經理，則能檢視整個部門的工作日誌，如果他是普通成員，則只能檢視自己的工作日誌。將許可權項賦給乙個角色，再將這個角色和職位賦給使用者，使用者就具備了相關的許可權。
按方案一實現的話，系統需要兩個單獨的許可權項，叫檢視部門成員工作日誌、檢視自己的工作日誌。這兩個許可權項既定義了操作功能（檢視日誌），又定義了資料範圍（看誰的日誌）。將許可權項賦給乙個角色，再將這個角色賦給使用者，使用者就具備了相關的操作許可權。
其實兩者的區別就在於方案一把二維拉平成了一維，假設操作功能用f表示，資料範圍用d表示，那麼方案一中的許可權項會有f * d種。
總結
方案二的優點是：將操作功能和資料範圍分為兩個維度管理，分別用角色許可權和職位管理，清晰易擴充套件。它的缺點就是，對使用者來說有點繁瑣，需要在兩個地方（角色、職位）定義。
組織結構與許可權模型設計（一）
前言 許可權模型是企業管理軟體最基本，也是最重要的功能之一，它屬於系統的基礎架構，涉及到對資料 操作功能的許可權控制。它的難點在於如何將企業的日常管理合理地對映到系統的業務功能，使使用者在使用系統的時候就跟日常辦公一樣自然，同時又能享受到辦公自動化帶來的效率提公升。在這次qone online的產品...
專案 RBAC模型與許可權設計
一.rbac模型 什麼是rbac rbac 全稱 role based access control 基於角色的許可權訪問控制，作為傳統訪問控制 自主訪問，強制訪問 的有前景的代替受到廣泛的關注。在rbac中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許...
系統設計 許可權模型設計
該許可權資料模型設計依據spring security框架，針對賬號 角色 許可權 資源 模組 選單 等物件做了簡單設計 指系統登陸賬號，系統使用者物件身份標識。只使用者的身份象徵標識，乙個登陸賬號，可同時擁有多個系統使用角色 身份 比如在網購 當中，使用者同時擁有a資源管理員角色 b資源管理員角色...