在任何系統中都需要許可權控制，沒有許可權，系統是不健全的時刻會受到各種問題的干擾。
許可權分為資料許可權和功能許可權
1、功能許可權：
能不能開啟某乙個介面，能不能觸發乙個介面上的按鈕，某些業務員能不能刪除訂單，採購員能不能刪除業務員某個銷售訂單，剛入職的小白誤入系統管理員的介面，胡亂的修改。這是什麼問題？沒錯這就是功能許可權。
曾今做過兩個系統對功能許可權的控制
1）、某某公司erp系統：
業務員具有新增，刪除，檢視，作廢銷售訂單的許可權，其實那家上市公司不允許業務員具有刪除，作廢導致流水號不連續無法更好的管理訂單資訊，後來鑑定那樣的設計其實是非常不好的：將許可權直接賦值給某某人，如：直接將新增的許可權賦值給小李，刪除許可權賦值給小張，作廢的許可權賦值給小王，後來想給小李作廢的許可權，然後又重新將作廢的許可權賦值給小李，後來來了個新員工小芳，小芳想具有小李，小張，小王的許可權，咋個辦呢？乙個系統幾百個許可權當時的系統管理員不幹了，這種許可權賦值對他的操作太麻煩了。每增加乙個人許可權賦值都是乙個體力活，特別是某某人想具有某些人的許可權，這無疑是增加了系統管理員的工作量。
2）、某某資料分析系統：
借鑑了某某公司erp系統功能許可權的失敗：在許可權和人之間追加了乙個角色，先將新增，刪除，檢視，作廢等許可權賦值給莫某角色，然後給某某人賦值某某角色，這樣某某人就具有某某許可權了，某人想擁有某些人的許可權，直接將這些人的角色賦值給某人，這樣某人就具有某些許可權，同時減少了許可權賦值給人的難度。
2、資料許可權：
場景1、 業務員a在業務員b某個訂單上檢視了某某客戶對某某產品的銷售單價，在某某搜搜框中搜出其他業務員的訂單資訊，可以隨意的檢視其他人的訂單資訊，其他人的業務員客戶資訊，其他人負責的產品資訊，這無疑不是對系統健全的挑戰。
場景2、 某業務主管看到公司某產品的平均毛利率，某客戶的平均毛利率，重則帶著下面一群小弟出去創業，稱為公司的競爭對手，這無疑會對公司造成損失。
資料許可權無非就是某人只能看到某些資料，這些資料是可能是屬於自己直接操作的，也可能是間接操作的。
模擬erp系統資料許可權，某業務員a想知道自己有哪些客戶，於是開啟了客戶管理介面，看到的客戶全是自己相關的，假如沒有資料許可權的設定 ，會看到有部分不屬於自己負責客戶。如何統計出某業務主管自己今年銷售狀況好的產品有那些？曾經碰到兩種情況出發：第一種業務主管負責的業務員 ，另外一種直接從負責的客戶出發。
1）、業務主管負責業務員所賣的產品
業務主管根據自己負責的所有業務員統計出所有負責的產品然後篩選出，現實生活中的可不是那麼的理想，某某主管負責的業務員全在自己負責的客戶正常工作。如果乙個業務員負責的客戶時刻在發生變化，並且業務員所負責的客戶不屬於當前業務主管負責，那麼統計出來的資料就會受到質疑，刁難的客戶會對軟體產生極大的不滿。
2）、業務主管負責客戶所買的產品
直接從客戶入手，根據客戶統計出主管的銷售狀況是對業務主管負責業務員變動的補充。
我是這樣理解的訪問乙個系統必定是根據人出發，以人為切入點，設計好人和人之間的關係，人和部門之間的的關係，人和客戶之間的關係，人和產品之間的關係，人和**商之間的關係。一切從關係出發查詢資料，這就是資料許可權。
功能和資料許可權系統設計
rbac許可權系統能很簡單的應用於功能許可權系統 或者可以稱作控制 選單 許可權，控制使用者可以使用系統的哪些功能，例如是否可以使用統計功能等 基於資料許可權的系統 控制使用者可以訪問某個功能的哪些資料，例如部門經理可以訪問本部門的所有使用者資料，科長只能訪問科室的使用者資料等 則與業務邏輯相關，簡...
許可權設計（功能許可權與資料許可權）
許可權設計的最終目標就是定義每個使用者可以在系統中做哪些事情。當我們談到許可權的時候，一般可以分為 功能許可權 資料許可權和字段許可權 功能許可權 使用者具有哪些權利，比如特定單據的增 刪 改 查 審批 反審批等等 一般按照乙個人在組織內的工作內容來劃分 比如乙個單據往往有錄入人和審批人，錄入人具有...
許可權 如何用AOP實現資料許可權功能
針對不同使用者，在資料查詢時要在sql上拼上可以訪問的部門機構部分。這部分資料查詢許可權一般都是按一定配製或規則制定的。這裡看到一種比較好的方法可以實現資料許可權。其中tablealias為sql中表的別名。dataauth tablealias s public result list reque...