最近公司系統調整，前期因為需求的不穩定，所以角色權限這一塊沒有完全的確定一個固定方案，現在需要重新設計一套可用性比較廣的的角色權限方案，再以此為基礎對現有系統進行一定程度的改造。需要能滿足一下幾個目的：
1 能夠對資源進行細顆粒度的控制（粗顆粒，即只控制到菜單、按鈕、方法。細顆粒度控制到數據級別，比如同樣是角色“”班主任“”，可見的學生都是自己班上的，無法看到別的班級的學生）
2 能夠靈活配置：用戶到角色可以多對多，角色到權限也可以多對多
3 角色授權：用戶可以創建子角色，並對子角色進行授權，可以授權到細粒度級別，並選擇被授權的時間段，但被授權角色的權限不能超過原用戶的權限（一個角色是否能夠創建子角色由系統管理員分配，創建的子角色的權限是不包含這個繼續授權。如果一個用戶有多個角色，能授權的功能范圍是被管理員標為“允許授權”的部分。）這個功能主要用於臨時授權，系統主要角色還是通過系統管理員設置（第三點需求思考后發現不同的業務場景下的具體授權模式區別可能會很大，所以暫時先不考慮在內，以后由具體的需求再進行改造）
方案最核心的是資源表（權限表）的設計，以往的資源表對資源的控制方法是一個頁面資源是數據庫中的一條記錄，或者更細一點，一個按鈕是一條記錄，這樣做維護和擴展不是很方便，后期系統如果要統一擴展某一個操作類型（比如所有表單支持批量導出），修改的工作量會很大。或者是取消某一個角色在某一個功能域內的所有update權限，需要去對這個域內的資源進行完全遍歷才能達成。代碼寫起來也很繁瑣，容易出錯。重新設計的資源表以頁面資源為一個主體，系統所有資源都以這種方式管理，每一個頁面會包含crud和一些其他的操作在內，為了方便管理對所以資源進行一個分級（不分級也沒有影響）：
0級為根資源，為所以1級資源的父資源（留作后期擴展）
1級資源為主菜單資源（菜單只有可見和不可見兩種，所以只具有read操作）
2級資源為子菜單資源
3級及以后資源為頁面資源（也可將子菜單的可見與否與頁面資源的read權限進行合並）
添加新資源時，level為父資源的level+1
每個資源都具有多個種類的操作權限，如果將一個權限作為一個字段不但管理不方便，而且也完全無法擴展，所以我將所以權限合並到一個字段，統一管理。字段用二進制顯示，預先設置為小於256，也就是最大表示11111111（這個可以靈活擴展），具體設計如下：
從右邊數第1位表示資源是否具有read的功能，1表示有，0表示無；
從右邊數第2位表示資源是否具有create的功能，1表示有，0表示無；
從右邊數第3位表示資源是否具有update的功能，1表示有，0表示無；
從右邊數第4位表示資源是否具有delete的功能，1表示有，0表示無；
從右邊數第5位表示資源是否具有設置數據范圍的的功能，1表示有，0表示無；（如果一個資源的管理權限是帶范圍的，就像這一位設為1，比如上面班主任看班級成員信息的頁面）
舉例：00001111 表示這個資源具有crud權限，它可能是一個常用的信息管理頁面。00000001表示這個資源只具有讀的功能，它可能是一個新聞頁面
這樣做的好處是可以非常方便的了解一個資源所具有的權限。修改和擴展也很方便，比如如果要使整個系統對某一個資源的某一種操作關閉，只需將其中表示該操作的字符位從1變為0就行了。
如果資源有其他的權限類型需要管理，可以繼續添加字符位，比如常用的批量導出數據，在頁面添加這個操作按鈕和后台代碼后，我們將這個操作控制字符位放在從右邊數第六位，可以並不影響以前的權限功能；包括范圍設置也可能不止一個維度，如果其他資源有從另一個維度來進行范圍划分（比如一個部門內部繼續按小組來划分），也可以繼續增加范圍權限的字符位。
備注： 這個資源表是從整個系統資源來考慮，所以要保持系統的一致性，比如我們設定第一個字符位為read權限，那么整個系統的所以資源都要按照這個規則來，全部保持一致。如果有新的操作類型，可以新增定義，但不要修改原來定義的含義。
配合資源表的是角色-資源表，角色-資源表的權限字段定義方案還是按照資源表中的定義，但是是資源表的子集，比如資源表中某一個資源的操作權限是00000111，那么在角色-資源表中對應的值可以是00000111，或者00000101，而不能是00001111；因為該資源定義時就不包含刪除操作。1表示該角色對於該操作具有權限，0表示該角色對於該操作不具有權限。
采取這個二進制方式最大的好處是能方便的解決權限的合並問題，比如一個人M具有兩個角色A,B，這兩個角色對資源X分別具有0000101和00001011的操作權限，那么我們通過“或”的操作就能快速將兩個甚至多個角色的權限合並，此例中合並的后的值為00001101，表示用戶M對資源X具有讀、修改和刪除的權限。代碼中是根據字符位來判定權限，寫業務邏輯的員工不需要操心這個權限的來源是一個角色還是多個角色。很好的進行了抽象。
資源和權限表的設計只能解決目的二，對於目的一還是沒有解決。考慮到實際的應用場景一般對於數據范圍的划分是針對同一角色同一職責，比如所以班主任的職責是一樣的，所以從設計上並不適合給它每一個班主任划分不同角色，那么我們就用同一角色來管理他們的操作，另外再用一張表來維護他們的數據范圍。將這個范圍控制給到用戶，而不是角色。利用現有的范圍信息表（比如班級表，部門表等等），給需要的用戶分配一個范圍ID（班級ID），在簡單的業務情況下，可以直接將班級ID作為用戶表的一個字段，當我們需要修改用戶的工作范圍時，只需要更改他的班級ID就行了，而不需要修改他的角色類型。這種設計模式也更符合我們業務的實際情況，大多數工作調動很多都是平級調動，比如從一個班級調到另一個班級，而工作性質和權限是不變的。
所有用到的表的關系如下：
總結：目前這種設計只是適用於簡單的常用權限設計，應該還有更優化的方法。並且隨着業務情況的變化還應該有更多的變化，以后遇到再補充。