## 簡介 數據權限是大家最為需求也是最廣為談資的一個設計理念。我們需要控制不同的角色、機構人員有查看不同數據范圍的權限。如果你動手去設計數據權限，當你去各大平臺、百度、谷歌查找設計思路的時候，會發現很難找到有用的資料，很多設計思路局限性非常大。 為了解決這一類疑難問題，JPower提供了倆種配置方式可配合使用 * web在線配置，達到數據權限自動、動態生效的目的。 * 注解方式，針對一些固定使用的方式，避免大量配置使用 ## 數據權限配置 我們訪問權限管理->數據權限中可配置不同資源的數據權限 1. 在需要的配置的菜單中點擊權限配置，彈出該菜單下的所有配置列表，點擊新增可添加配置    2. **可見字段**代表數據權限最終返回的字段集合，如果是全部則填 * , 如果只需要指定得字段直接填入需要查詢得字段用逗號分隔即可，例如只需要id和name兩個 字段，則填 `id, name` 3. 之所以可以實現自動配置，就是因為我們指定了Mapper層對應執行的方法。所以我們在**權限類名**中把對應的路徑需要指定正確，不能出錯。例如我們要配置客戶端列表的權限，則在**權限類名**中填入該列表查詢SQL所在的mapper全路徑：  4. 還有一點需要注意的是，若分頁、列表等方法不是自己寫的mapper，而是采用的mybatis-plus提供的方法，沒有自定義的方法名，我們需要跟蹤下代碼，可以看到，自帶的page、list等方法，其實是調用了BaseMapper里的方 法。例如追蹤下面截圖中得mapper層執行得方法    所以我們如果需要配置**權限類名**，只需要在`scope_class`(數據權限類名) 字段中存上`com.wlcb.jpower.dbs.dao.tenant.mapper.selectPage`即可。 5. 當字段**權限類型**等于5(自定義)時，字段**權限值域**數據必須要有值，值輸入我們正常sql得where條件后面得部分即可。例如 ``` login_count > 1 and id = '{userId}' and address in ({roleIds}) ``` * 在這個配置的sql里我使用了占位符 {userId} ，沒錯，這么寫在底層就可以直接獲取到當前登錄用戶的 userId字段，除此之外我們還可以用更多的參數，比如 {orgId} 、{roleId} 、{tenantCode} 、 {loginId} 、 {userName} 等等。 * 這些參數可以參考UserInfo類，這個類得所有字段我們都是可以根據占位符來獲得的。  * 需要注意得是如果我們要使用roleIds字段時，我們得自定義sql部分必須是要`in`查詢。例如`role_id in {roleIds}` 6. **所有角色都執行**當配置為**是**時，就沒有必要再對該條數據權限進行角色權限分配了，因為所有得角色都會執行該條數據權限，這樣我們對一些懶人用戶省去了很多配置。 7. 那么下面，我們就需要對我們剛才配置得數據權限分配角色了，我們在 `權限管理->角色管理` 中進行角色得權限分配。   點擊左側菜單時，右邊會顯示我們剛才配置好的數據權限列表，選中我們剛才配置好的數據權限，然后點擊“確定“就配置完成了。 8. 配置好之后，啟動工程，我們使用剛才賦權的角色調用登錄接口獲取到token，使用獲取到的token再調用我們配置好的數據權限mapper所對應的接口。 可以看到接口只返回了3條數據。  控制臺的打印的sql中的where條件部分也有當前登錄用戶的過濾條件  下面我們修改下數據權限配置，配置為自定義sql再進行一次測試。  無需重啟服務，我們再使用剛才的用戶重新調用接口獲取新的token，使用新token再次調用我們剛才的接口。 可以看到接口只返回了1條數據。  控制臺的打印的sql中的where條件部分正好是我們剛才自定義的sql部分  ## 注意項 * **超級管理員不受數據權限影響** * **因為我們的數據權限是在指定菜單后進行配置的，那也就是只有這條權限在配置的菜單下執行時才會生效，在其他菜單下執行則不會生效，如果在其他菜單下也需要執行配置的權限，則需要在該菜單下也配置一次這個權限**