概述
系統許可權可分為很多種。常用到的有操作許可權和資料許可權。操作許可權是有或者沒有某種操作的許可權，具體表現形式可為看到或者看不到某個選單或者功能按鈕。資料許可權指的是資料級別的許可權設計，立足點在於組織機構（崗位、部門、公司）和流程，對應的使用者沒有對某些資料的訪問許可權。本文件旨在設計資料許可權的控制方案，完善產品資料許可權的控制。
設計思路
通過之前平台規定每張業務表的必備字段（公司、建立人、流程參與人）來設計一些規則來配置某個程式的資料許可權控制規則。設計資料許可權配置程式來配置單個程式或者批量配置一批程式的許可權規則。程式在執行過程中根據配置的資料許可權控制規則來動態構建查詢sql，從而達到資料許可權的控制。各個資料級許可權控制規則為or的關係。
資料許可權控制規則
1、資料建立使用者
即當前程式記錄的建立人，配置此選項後非當前記錄的建立人不能看到此記錄。
建議：如果程式開啟資料許可權控制，此選項預設勾選，並且不能去除，否則如果配置了其他控制規則，業務記錄的建立人都不能看到自己建立的記錄。
2、建立人直接上級崗位
即當前程式記錄建立人的直接上級崗位的使用者能看到此記錄。
考慮到當前建立使用者可能在不同公司有不同的崗位，或者在同乙個公司也可能有多個崗位。這裡取使用者崗位時獲取的是資料建立使用者在當前記錄中的公司所擁有的主崗的崗位號（沒有主崗取所有副崗）。然後根據取到的崗位去獲取其直接上級崗位。
3、建立人所有上級崗位
即當前程式記錄建立人的所有上級崗位（需要進行遞迴）的使用者能看到此記錄。取使用者崗位的邏輯參考第2條。
4、建立人當前部門
即當前程式記錄建立人所在部門的使用者能看到此記錄。
考慮到當前建立使用者可能在不同公司有不同的部門，或者在同乙個公司也屬於不同的部門。這裡取使用者的部門時獲取的是建立使用者在當前記錄中的公司中所屬的主崗所在的部門的部門號（沒有主崗取所有副崗所屬的部門號）。
5、建立人所有上級部門
即當前程式記錄建立人所在部門的所有上級部門（需要進行遞迴）中的使用者能看到此記錄。（不包括當前部門）
取部門的邏輯參考第4條。
6、當前公司
即當前程式記錄中的公司下的所有使用者能看到此記錄。
備註：（1）配置公司資料級許可權時需要考慮和平台公司條件的關係，是否取交集、並集或者是去除平台公司條件？
（2）同時需要考慮s頁面公司列查詢時使用者能選到的公司
7、所有上級公司
即當前程式記錄中的公司的所有上級公司都能看到此記錄。（不包括當前公司）
8、流程參與人
如果當前記錄走流程，則所有的流程處理人（已處理和待處理）和知會人都能看到此記錄。
問題：1、所有流程的參與人具體包含哪些使用者？
2、每一型別的參與人是否需要進行分類配置？
備註：（1）在配置了第6條「當前公司」規則時，在解析條件時，可以忽略2、3、4、5條中配置的條件。
（2）特殊崗位的情況，某些領導擁有檢視所有資料的許可權。
/**
* 貼一段初始化資料級許可權的邏輯吧
* @author chengmeng
*/public static void initdataper(datadom datadom)
資料許可權的設計與實現
最近手上的web專案需要做許可權控制，努力了解下，做如下筆記 1.許可權分為選單許可權，操作許可權，資料許可權，選單許可權即不同使用者能夠看到的選單按鈕不同，如系統管理員能看到系統管理，使用者管理等選單，而普通使用者是看不到這些管理選單的。操作許可權即為不同使用者能夠對列表進行的操作許可權，即增刪改...
許可權設計（功能許可權與資料許可權）
許可權設計的最終目標就是定義每個使用者可以在系統中做哪些事情。當我們談到許可權的時候，一般可以分為 功能許可權 資料許可權和字段許可權 功能許可權 使用者具有哪些權利，比如特定單據的增 刪 改 查 審批 反審批等等 一般按照乙個人在組織內的工作內容來劃分 比如乙個單據往往有錄入人和審批人，錄入人具有...
資料許可權設計
資料許可權設計思考目前有關使用者許可權採用的比較多的都是基於rbac模型 目前有關使用者許可權採用的比較多的都是基於rbac模型，即通過對角色許可權的定義完成對使用者許可權的限制。有關功能許可權部分想必都比較清楚，就是將系統的功能模組劃分清楚，並賦予不同角色的訪問許可權，這樣在使用者訪問某個功能模組...