許可權一般是由頁面許可權、操作許可權和數據許可權組成的。頁面許可權是基礎，首先得現有頁面許可權，纔有操作許可權和數據許可權。在許可權設計的時候需要注意一些點：

1、 頁面許可權優先於操作和數據許可權

每個登錄人員都是首先擁有頁面許可權，纔可以配置當前模塊下的其他許可權。這個很容易理解，就像你都看不到該頁面怎麼擁有操作和數據許可權。

2、 查看許可權優先於增刪改許可權

從理論上講，其實擁有頁面許可權就已經擁有查看許可權了，而查看許可權也是優先於增刪改許可權，因此在設計的時候要首先分配了查看的許可權才能分配增刪改許可權。

3、 數據許可權的設計

數據許可權分為數據範圍和數據欄位，數據範圍基本上是和組織架構相關聯的，比如我們這次的銷售管理模塊，有主管的角色，主管的數據範圍是能看到自己的組員的信息。而數據欄位就是說可以給不同的角色看到不同的欄位，如培訓機構，一般都不會給教師看到學生家長的聯繫方式，就會有許可權控制他們不能看到聯繫方式。

二、我們的系統設計

由於我們的業務模式的設定，之前是沒有組織架構的層級的，所以也就沒有相應的數據範圍的設定。只提供了頁面許可權、操作許可權和數據許可權中的數據欄位許可權。我們的許可權設計是基本的RBAC模型。

1、 基本的RBAC（Role-Based Access Control）模型

如果沒有引入角色這一概念，那麼沒添加一個用戶就得給這個用戶配置許可權。比如說給普通老師配置許可權，每天加一個老師就得為這個老師配置一次，如果先定好角色，角色名為普通老師，給這個角色分配許可權，當添加老師的時候只需要給這個老師分配到普通老師這個角色就可以了，這就省去很多不必要的工作了。

通過這個設計，機構那邊就可以自定義角色並分配許可權，當添加老師的時候，給這個老師分配到相應的角色中就可以實現許可權的控制了。

2、 添加數據範圍許可權

剛才提到我們這個原本是沒有組織層級的，只有簡單的校區管理員這一個層級，而且這個是系統組許可權，是不提供自定義的。為瞭解決銷售主管能看到的數據範圍這一許可權，肯定得添加組織層級這一設定。設定之後，上一層級能看到下一層級的數據。最終我們確定在人員編輯處添加一個層級關係。

然後機構就可以根據自己的組織架構增加層級，這就能控制到數據的許可權範圍了。

三、總結

由於此次的許可權設計，瞭解了一下有關許可權的東西，發現這個許可權管理涉及到的東西特別多，是系統框架的基礎。我們這個系統也是比較簡單的，還有更複雜的許可權設計，但在複雜的也有最基本的原理，基本都是根據RBAC簡單模型演變出來的。由於對於其他更複雜的設計不太熟悉，就不分享了。路漫漫其修遠兮，吾將上下而求索。

推薦閱讀：