通用數據權限設計——列權限（一數據權限設計界面設計） _經驗分享

數據權限設計思路（摘抄）
數據權限決定用戶能看到什么數據、多少數據量。
我們常接觸到的數據訪問權限都通過組織機構去劃分，在實際應用中，也可能會根據業務增加其他維度的訪問權限，如終端門店管理中單獨設置門店訪問權限，企業多品牌營銷中設置品牌訪問權限等。
1、以機構層級向下覆蓋
根據組織機構樹設定用戶默認擁有所屬組織及以下的數據訪問權限。也是最基礎的一種數據權限，對于簡單的
2、與角色融合的數據訪問權限
在設定角色時，同時設置該角色對應功能權限下的的數據訪問權限層級：本人、本部門、本部門及以下、全公司。
用戶可視菜單中的數據權限由擁有該菜單的角色數據權限而定，且當一個用戶擁有多個角色時，角色菜單有重疊的，取兩角色中最大數據權限，或數據權限并集。
3、設置部門訪問權限
用戶默認擁有所屬組織及下級組織的訪問權限，同時可以自由配置其他部門的訪問權限，使得某些數據可以跨部門查看。
相比常規的基于企業組織架構，權限向下覆蓋的方式，采用部門訪問權限配置可以根據業務需求靈活地配置用戶的訪問數據范圍，避免了父、子、兄弟甚至其他節點間的數據共享糾結，實現跨部門數據共享。
將數據訪問權限分配在用戶上，足夠靈活但也犧牲了維護便捷性，在用戶特殊訪問權限不多的情況下可以選擇該類方法進行設置。
4、實際應用中根據業務需要劃定數據及功能權限范圍
在實際應用中，僅通過部門設置數據訪問權限不一定能滿足業務數據的分界要求，在具體的功能里往往通過部門訪問權限+其他條件組合的情況來限制用戶數據權限范圍。
如【部門訪問權限+角色標簽】，公司內部有領導類的角色，某種業務的原始單據信息需要給高層領導類角色的查看權限，但涉及到管理分權又不想賦予該類人員所有部門訪問權限，此時要么單獨開入口查詢所有信息，領導類角色功能權限中都配置上該頁面，也可以在該頁面查詢數據時，在部門訪問權限之前再加一層角色標簽的判斷邏輯，若角色標簽為領導的則不需要根據部門訪問權限過濾。
總結及碎碎念
B端系統權限設計中，系統權限區分為功能權限和數據權限，分別對應系統中的功能模塊和系統中的數據，功能權限大多基于RBAC模型，并可根據業務需要引入角色繼承、用戶組、角色標簽等概念，數據權限主要基于用戶機構、角色，或單獨在頁面中根據實際需要進行配置。但最終，所有的設置都是需要基于業務，先有業務、需求后有產品，只是權限配置這一功能模塊偏向于公司層面要求，受公司業務形態影響較小，所以能抽象出一套較廣泛適用的系統方法。
2、用戶權限管理，數據庫表設計網上資料說權限設計 = 功能權限 + 數據權限，我認為還是很有道理的。之前項目中只涉及到功能權限，沒有數據權限，原因是最開始設計時，數據已經綁定在特定的用戶下了，而且涉及到的表數量很少，不需要單獨考慮數據權限的問題。
權限管理，最細致的權限管理有用戶，用戶組，角色，權限，功能。根據不同的需求適當選擇，如用戶量過大，每個人都授權和麻煩，就引入用戶組，對用戶組賦予權限。功能上也根據業務不同做適當的擴展。由于如用戶權限之前存在多對多關系，需要引入中間表。
本系統設計如下：
數據量很小，功能也不復雜，所以只有用戶，角色，權限（功能）及產生的中間表。
表中的數據都是提前填的，用戶登陸，查ermroleuser表，獲取角色，查ermrolefunction表，獲取功能，再查ermfunction表，返回該用戶的功能的中文，在頁面上展示。
功能權限詳細設計請參考，本項目也是受此啟發：
http://blog.csdn.net/painsonline/article/details/7183613/
需求：給一個原來沒有權限的數據配置系統加上登錄，權限功能，不同角色查同一張表返回結果不同。
思路：所謂數據權限，關注點在于實體屬性值、條件、允許值，用戶登錄后，查詢該用戶的查詢條件，根據條件獲取數據即可。詳細表結構設計可以參考： https://zhuanlan.zhihu.com/p/31339794
具體介紹一下每個字段含義：
（1）主鍵 id；
（2）acl_id 映射權限點表主鍵，代表每行記錄是針對哪個權限點的；
（3）status 代表當前這條配置是否有效，方便臨時激活與禁用；
（4）param 代表需要校驗的參數名，允許一個請求有多個參數參與數據校驗；如果參數復雜，比如包含對象，定義的參數可能為a.b.c 這種多級的形式，建議不要太復雜
（5）operation 代表數據攔截的規則，使用數字代表是等于、大于、小于、大于等于、小于等于、包含、介于之間等，可以根據自己需要增加或減少支持的攔截規則
（6）value1 和 value2 用來和param、operation組成一個關系表達式，比如：1<=a<2
next_param_op 字段根據需要使用，如果一個權限點支持多條數據規則時，連接兩個規則之間的操作，|| 還是 &&
（7）seq 字段用于某個權限點包含多條數據權限規則時的順序
假設有這么一條數據，那么他的含義是：id為1（acl_id）的權限點，配置了一條有效（status=1）的數據規則，規則是：傳入參數id（param）的值要大于（operation）10（value1）
這種設計很細致了，當然我的項目沒有那么復雜，所以最終沒有采用這個。
http://www.cnblogs.com/jeffwoot/archive/2008/12/23/1359591.html 講述了數據權限設計的演化過程。
本系統跟權限相關的表結構如下：
權限設計的總結用戶：參與系統活動的主體，如人。
角色：特定權限的集合；
權限：角色可使用的功能，分角色的功能權限和角色的數據權限；
RBAC設計方案：基于角色的權限設計方案,更好的管理用戶；
操作類型：對資源可能的訪問方法，如增加、刪除、修改等；
功能：對資源的操作，是資源與操作類型的二元組，如增加銷售單、修改銷售單等；
資源：系統中的資源，主要是各種業務對象，如銷售單、付款單等；數據類型：業務系統中常用的數據權限類型，如公司、部門、項目、個人等；
數據對象：具體的業務對象，如甲公司、乙部門等等，包括所有涉及到數據權限的對象值；權限設計原則：第一：權限的粒度要做到最小，保證在權限分配時，只賦予用戶足夠完成其工作的權限；第二：避免出現權限互斥的情況
權限設計原則：第一：權限的粒度要做到最小，保證在權限分配時，只賦予用戶足夠完成其工作的權限；第二：避免出現權限互斥的情況；
所以基于數據的權限設計（數據權限則是控制你可以看到哪些數據，比如市場A部的人只能看到或者修改A部創建的數據，他看不到或者不能修改B部的數據。）
第一步梳理：梳理層級關系（我們可以找出每一個層級的BOSS）
超級管理員：
集團管理員
城市管理員（我們也可對這個城市組織節點授權）
學校管理員（我們也可對學校組織節點授權）
部門管理員（我們也對對這個部門組織節點授權）
第二步：每一層建立角色
每個后臺用戶可以自定義角色，給相應的用戶授權，每個后臺用戶的權限是上一個后臺用戶權限的子集，后臺用戶創立角色的權限是子集的權限子集；這里也可以首先給城市，學校，部門這個組織節點分配權限，當每一層的管理員建立角色分配權限時只能是這個城市權限的子集；
第三步：給角色授權
這里我要將所有的權限進行打散：系統功能的篩選無非是從：系統名稱-模塊名稱-功能項（這里的功能項已經拆解到按鈕級別了）
第四步：給用戶授權
角色創立了，我們就可以對用戶進行授權，角色和用戶的關系可以是一對一，也可以是一對多的關系；
總結：
以上就是本人對如何做權限設計的總結分析，僅供大家參考，希望在工作中能夠幫助到大家，也希望大家一起多提意見，指出不足，感謝閱讀！
系統權限設計思路方法總結幾乎所有的管理后臺都會涉及到權限的設計，權限控制是管理后臺的重要功能，可以有效的提高系統的安全性，減少誤操作、數據泄漏等風險的發生。但是，很多產品經理會對權限功能有一點害怕的心理，一方面是由于能參考的實例較少，權限管理算是一個“系統級”的基礎功能，一般系統中只有管理員可以操作，不像其他功能可以通過去其他系統中試用體驗，另一方面，對于權限功能普通用戶無法操作使用，所以存在感較低，做好了也不會出彩，可沒做好就會導致整個流程不通、產品崩潰。
一 RBAC模型
目前，接受度較高的功能權限模型是RBAC（Role-Based Access Control）模型。在RBAC中，權限與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是為了完成各種工作而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合并而賦予新的權限，而權限也可根據需要而從某角色中回收。
1.角色的作用
如果沒有角色的概念，直接用戶對應權限，雖然會更加靈活，但是后臺的數據表設計會變得復雜，操作成本也會很高，同時容錯能力也會變得很差。
而引入“角色”概念后，用戶與角色可為多對一或多對多的關系，當一個用戶的角色為多對多時，當前用戶的權限是多個角色的并集。此時只需要為角色賦予權限，能夠大大減輕管理負擔，同時將用戶與權限解耦，提供更大的靈活性，同時整個設計的容錯能力也提高了很多。
2.引入用戶組
一些大型的平臺上，如果用戶數量較大，新增角色時，需要為大量用戶分配新的角色，工作量巨大，此時可以引入用戶組的概念，將這些用戶拉到同一個用戶組中，然后對整個用戶組進行角色的指定，這就大大減少了角色分配的工作量。
同理如果權限較多時也會存在一樣的問題，對角色進行權限設置時也需要大量的操作，此時可以考慮引入權限組的概念，將關聯性較強的權限大包成組賦予角色，從而減少賦值時的工作量，現實中權限組的使用相對較少，因為系統中的權限一般來講是有限的。需要注意的是即使有用戶組或權限組的存在，也可以允許用戶或權限與角色直接關聯，這個可以視具體業務情況而定。
下圖所示為mac系統中運行添加用戶組，并以用戶組為單位配置權限。
3. 角色繼承的RBAC模型
在一個業務場景中，如果角色需區分：設計主管、設計組長、設計成員，并且管理方式為向下兼容時，則需使用角色繼承的RBAC模型。上層角色繼承下層角色的全部權限，且可額外賦予權限。
此時除了對角色進行定義，還需要管理角色間的關系，通過關系來體現角色的層級關系，從而達到繼承權限的效果。角色的繼承關系主要有兩種：樹形圖和有向無環圖。
繼承關系常常來源于公司團隊的組織結構，此時常將角色與組織結構進行關聯達到繼承角色模型的效果。如下圖所示的趙同學，其角色是“三級團隊負責人”，與其并列的小組中有多個“三級團隊負責人”的角色，但依附于左側的組織結構樹，各級負責人僅有查看和操作自己下屬子節點的權限。
4. 限制的RBAC模型
在一個產品或系統中，部分角色可能是需要隔離的、不允許被同時賦予一個人的。跟大家熟知的“不能既是‘運動員’又是‘裁判員’ ”一個道理。
因此，對于眾多角色中的一組，只能是單選的關系，但多組角色之間可以共同存在。如下圖中，一個用戶可以既為設計師又為管理員，但在設計師角色組中僅能被賦予一個角色，在管理員角色組中也僅能被賦予一個角色。
此外，限制還有可能是數量上的，比如一個產品組中必須有且只有一個管理員，不允許刪除或再分配管理員角色，僅允許將負責人角色變更。
限制的模型不僅僅對分配過程產生影響，有時即使擁有了多種角色，因為不同的角色對同一個功能的使用方式或數據會產生沖突，所以使用時也需要進行限制。如下圖所示為同一時間僅允許以一個身份登錄。
根據不同的業務需求，限制的形式很多。需要注意的是不能僅依賴后端限制，而是要在前端展示清晰的規則和恰當的限制，避免用戶出錯和沮喪。
三、權限的拆分與設計
通過RBAC模型已經能夠很好的搭建起用戶、角色與權限之間的關系了。但具體是什么樣的關系，以及“權限”這個抽象的概念具體如何規劃？
這些都需要分析清楚才能進一步設計出完善的權限系統。
首先需要知道，一般產品的權限由頁面、操作和數據構成。頁面與操作相互關聯，必須擁有頁面權限，才能分配該頁面下對應的操作權限。數據可被增刪改查。
整體關系如下圖所示：
因此，在設計之初我們就需要考慮到未來可能區分角色的地方，盡量解耦、模塊化。對于技術來說，每一個頁面模塊、每一個操作都最好使用獨立的接口。對于設計來說，需要保障所有角色因為權限而屏蔽掉部分操作和數據后，頁面和流程仍能體驗流暢。
保證初期設計支持后，配置權限時，還需要注意以下幾點：
（1）確定是否支持前端配置
如果角色和權限相對固定，則一般將角色與權限的關系可以寫在后臺，改動時需要后端變更且重新上線。這種情況適用于公司內部系統等只有一個使用主體的系統。
如果需要自定義角色或者每個角色在不同使用者的場景下有不同的權限，則需要將角色的定義、角色與權限之間的配置體現在“前端用戶配置頁面” 。這種情況適用于有頻繁變動的自定義角色權限，和有租戶體系的系統。
（2）以基本單元拆分，以業務邏輯配置
一般可將每個對象的“增、刪、改、查”各自作為一個基本的權限單元。打個比方，在“人員管理”中，查看人員列表、添加人員、刪除人員、編輯人員信息最好拆分為4個權限單元。在技術和設計上，我們希望能盡量做到解耦和模塊化。
但是在業務層面有些操作卻是一體的。這些不能拆開的權限在“前端用戶配置頁面”中建議打包成一個整體提供配置。例如：如果我們確定在系統的現有和未來業務中，僅分為普通成員有“人員管理”的查看權限，管理員有操作權限，則可將“增、刪、改”三個基本權限單位合并為“操作”權限進行配置。
（3）頁面權限優先于操作和數據權限
必須配置了頁面模塊權限后，才能配置當前頁面模塊下具體的操作權限，以及頁面模塊的數據展示權限。
【通用數據權限設計——列權限（一數據權限設計界面設計）】 （4）查看權限優先于增刪改權限
正常情況下，一定要先能查看某個模塊或操作，其它的增刪改操作才有意義。因此在設計時，應在獲取查看權限前限制其它權限的配置，或者配置其它權限時默認賦予查看權限。
（5）角色與權限的多種關系
角色與權限的關系不僅是單純“是/否關系”，還包括以某種限制進行操作，和以某種程度訪問數據。
例如在“人員管理”中：
數據范圍：用戶擁有查看人員列表的權限，但僅能查看自己所在的團隊；數據邊界限制（上限等）：添加人員時不能超過20個等。數據字段：HR能查看人員列表中包括職級、薪資等字段，其它角色僅能查看姓名郵箱等字段；
（6）角色與權限的設計表達
在傳達一個系統的權限設計規則時，設計師常常習慣用主觀最直接的方式表達想法，如用“當……時，就……”的句式來表達。但一個平臺中涉及的權限規則是非常多的，當通篇以這樣的形式描述時，表達對象將很難理解。
正確的描述方式：更清晰的是基于開發的語言，和技術模型的結果進行表達。將各角色與權限單元繪制成網格，每個交叉點網格中描述該角色與權限的數據關系和限制。
如下圖所示：
四、需要注意的Tips
1. 隱形的admin
在可自定義角色和權限的系統中，一般需要預留一個admin角色來進行系統的初始配置，用于添加首批的業務人員和配置基本的角色。
有的系統中允許存在上帝視角的admin角色，則其可以作為“超級管理員”顯示在角色配置的列表中。有的系統中不允許這種角色存在，則可將這種角色設置為隱形的狀態，僅賦予維護系統的工作人員。
2. 初始權限的賦予
對于允許用戶自行加入的系統，需要設定一至多個默認的角色，有時可以是僅有最基礎權限的“游客”角色。
初始權限還可以與用戶既有的某些數據字段進行關聯，如添加用戶時獲取到用戶的崗位為“設計師”，則直接賦予“設計師”角色的權限。
3. 人員管理中對自己的處理
在人員管理中，管理員角色處理自己時需要額外注意。因為如果修改或刪除了自己角色后，可能導致系統沒有管理角色，從而無法添加其他成員和正常運行。設計時可添加判斷，當自己為唯一管理角色時，禁止編輯和刪除。
4. 無頁面權限的提示
雖然可以通過頁面權限限制直接隱藏當前用戶沒有權限的頁面，但不能排除用戶獲取到權限外的url地址。當用戶意外訪問到沒有權限的頁面時務必提供“無權限”的提示，避免用戶認為系統bug 。
總結一下，整個權限系統設計就是定義各個節點和節點間關系的過程。
節點包括：
用戶；用戶組；角色；角色組；權限（頁面、操作、數據）；權限組（頁面、操作、數據）；
如何設計ERP系統的數據權限？？按照崗位體系建立數據權限
應用：CRM
優點：1.設置簡單，選擇按照部門選擇
缺點：1.需要維護一套崗位體系
2.不夠靈活，不能看到跨部門數據（可以了解到其他部門的價值）也不能看到上級的數據（有個員工需要根據能力恒定自己的職業規劃，那么他會以上級為參考點，去觀察上級的銷售數據如何）（人事財務需要看到整個部門的數據，他們也不是領導，他們是專員，而且那些人也不是他們的下屬，無論如何都看不到數據）
針對角色設置數據權限（實習公司也是這樣處理：班主任，助教，管理員）
優點：不受崗位框架影響，可以靈活設置，如果短期內沒有負責到這部分數據，我就取消對應角色權限即可，但不用刪除掉這個角色以及權限；再比如可以設置一個角色“宇宙總局xx指揮中心xx副局”，但實際上不存在這個崗位。
再比如，角色可以多層疊加，比如華南地區xxx就可以看到華南地區的數據；華東地區xxx就可以看到華東地區的數據；總局可以看到xx所有數據，但是我們不能讓這個人看到所有數據，只需要讓他負責華南與華東即可，則給他兩個角色就好
怎么設置角色權限呢？
采用數據規則：規則編輯器
如：客戶所在地區等于 AS地區且客戶狀態等于帶續簽，輸出結果：交集
客戶所在地區等于 B地區且客戶狀態等于入住或客戶所在地區等于 K地區且客戶狀態等于簽約，輸出結果：并集
優點：1. 避免與崗位直接綁定，崗位變動則權限變動；
2.避免與崗位直接綁定，僵化管理，沒有角色靈活
3. 可以適合多種特殊化場景（臨時需求居多），用完就釋放權限關系，避免數據泄露
缺點：1.需要維護角色與權限關系
2.數據規則較為復雜，需要進一步管理
3.如果是多層計算，同樣數據規則也很復雜
專化崗位：提供崗位方案如：銷售（A,B,C都是銷售，但A負責a課程的物料，B負責b課程的人群轉化以及轉介紹，C負責d項目的引入）
不專化崗位：提供角色方案如：銷售人事（一個月前負責xx項目的招聘工作，一個月后負責xx項目的培訓工作）
總結：
數據范圍劃分清晰，準確
盡量減少維護成本（弄完一套規則體系后盡量不動維持原態）
設置靈活（可塑，可拆，可整合）
名詞解釋：
直接下屬：轄域下面一層
所有下屬：所有轄域，包括往下一層往下二層往下三層，，，
虛擬上級：一個節點
特殊情況處理：
人員變動：判斷人員是否專化？ if 是，then 崗位；if 不是，then 角色方案。
部門變動（幾乎很少）：
并入新部門：維持與新部門同個權限位置。
拆分：經討論分析，評判每個用戶的角色等級。
移出：撤銷原有權限，載入并維持新權限。
通用數據權限設計——列權限（一）筆者認為WEB系統權限應歸納為功能權限，數據權限（行、列）
二者共同構建出應用系統的權限模型，接下來本文詳細描述下列權限的設計理念。
column_permission：
column_handler ：
本文著重描寫列權限設計的思想，具體祥設參考
通用數據權限設計——列權限（二）
關于數據權限設計和數據權限設計界面設計的內容就分享到這兒！更多實用知識經驗，盡在 m.apearl.cn

通用數據權限設計——列權限（一 數據權限設計界面設計）

通用數據權限設計——列權限（一數據權限設計界面設計）