電腦動態壁紙桌面(九模仿學習-動態更改大屏數據)
電腦動態壁紙桌面文章列表:
九模仿學習-動態更改大屏數據
可視化大屏里的數據，我們正常應該來自于后臺數據庫，所以我們要完成這個內容。因為是做演示部分，我們做表單提交，建議表單會了之后，嘗試用ajax提交，框架也可以改為springboot等框架。
首先我們的數據應該是來源于后臺的，在Action的部分，我們要查詢所有的數據。我們先以大屏左上角的圖為例。
先在action中完成測試數據，就是目前還不連接數據庫
然后在請求的方法中添加我們的測試數據
數據已經準備好，接下來要將數據放到頁面中
首先在index.js中將柱狀圖的代碼移動到jsp中。這個頁面里寫ajax比較好，但是我們使用的是表單所以要將數據拿走。
移動之后代碼到模塊二
然后看jsp中移動過來的代碼。
放入代碼后
然后我們需要把動態數據加進來。${td}就是我們后臺返回的測試數據，這個地方就是將數據放到一個managerdata的數組中。
打印測試一下，方便我們調試代碼，可以不寫
接下來是第二個測試數據
需要把靜態數據改為我們動態的數據，所以上面的兩個變量我們都要使用了。
首先是x軸的數據
然后是y軸的數據
然后我們測試運行下，可以看到數據是我們后臺的數據，說明前后端聯系上了。
我們開始準備數據庫，先準備數據
然后action中準備DAO
在applicationContext.xml中添加配置
我們準備測試代碼
運行看是不是數據庫的數據
出現問題：數據沒有
返回查看代碼發現這個地方錯了
修改后重新運行，數據正確了
此時我們可以根據我們的后臺管理完成數據的變動，比如打開管理后臺，更改數據
這有個地方糾正 之前有個地方不小心改錯了，之前寫成zztlKsh.jsp了，現在改為zztlMoRe.jsp
更改數據
查看可視化屏幕，可以發現已經更改了。
從交互流程和狀態兩方面，分析拖放功能設計
拖放功能指用戶選中圖片、列表項或卡片等元素，拖放到頁面的其他位置或其他產品中，它的設計非常多樣化，應用場景也很多，本篇文章就從交互設計流程和和狀態兩方面來分析拖放設計，感興趣的朋友快來看看吧。
大家好，這里是設計夾，今天為大家分享的是「拖放設計」。
拖放(drag and drop)指用戶選中圖片、列表項或卡片等元素，拖放到頁面的其他位置或其他產品中。
這種交互方式在移動端表現為長按拖動，在PC端表現為單擊并用鼠標拖動，最后放到目標位置上。
一、拖放設計的使用場景
拖放式UI/UX的設計非常多樣化，并被用在多種場景中。基于設計需求的不同，每個產品可能會要求不同的拖放設計。
1. 移動項目
這種拖放類型最常見也最常用，我們將桌面上或者頁面中的靜態項目拖放到指定的區域，進而完成操作。
例如在一些文檔處理網站中，我們可以接將電腦桌面上的文件直拖拽到網頁中，完成上傳文件的過程。
又或者電腦桌面上的文件夾，被拖放到回收站中。
2. 重新排序
這種類型在網站設計中比較常見，這里的拖動目標在頁面中是動態顯示的，并且會在釋放拖動后顯示項目最終的位置。
頁面中有多個卡片，可以長按拖動來調整卡片的位置，達到重新排序的目的。
在拖動頁面中的列表或者卡片重新調整順序時，這里介紹兩種拖動交互方式。
第一種交互方式是在拖動某個列表時，這個列表仍然在原位置顯示，只是顏色會變淺。拖動到某個位置時，會顯示一個指示條，其他列表的位置保持不動。
這樣做的優點是能減少列表之間的相互移動，方便開發設計。
第二種交互方式是被拖動的列表會從原來的位置挪開，拖動到某個位置時，能直接在這個位置上顯示出來，同時其他列表的位置也會動態變化。
這種拖動交互的反饋更直接，也是當前用的比較多的交互方式。
二、拖放功能設計流程、狀態分析
為了方便大家更好理解，我們將拖放的交互分為拖放前、拖放中、拖放后三個過程，整體分析前、中、后的狀態以及拖放過程中會涉及到的其他場景。
1. 拖放前
在拖動前，被拖動的元素處于初始化的狀態。那么我們如何讓元素看起來是可以拖放的呢？
除了必要的文字提示，最常用的方法是在列表或者卡片上展示代表拖放的icon，告訴用戶這些元素支持拖動。
在PC端中，當鼠標懸停在可拖動的項目上時，還可以通過改變鼠標的樣式(抓手、指針等)，告訴用戶項目可以拖動。
在改變鼠標樣式的基礎上，為拖動icon增加一個懸浮狀態，這樣能更好地表達拖動的意思。
當鼠標點擊或在手機上按下要拖動的元素時，被拖動的元素往往會有一個狀態的變化，比如列表增加陰影效果或者拖動圖標顏色變化，表明觸發了拖動。
2. 拖放中
觸發拖動后，接下來就到了拖動中流程。
通過鼠標或手指移動，被拖動的元素也會跟著移動，進而將元素拖動到指定的位置上。
如果當前的列表支持多選，可以選擇多個列表項，然后一起拖動。
在多個列表共同拖動的情況下，最好能有一個顯示多選數量的徽標，這樣能清楚地展示出多選的數量。
當需要把項目拖動到指定區域的場景中，隨著被拖動的項目越來越靠近指定區域，該區域的視覺反饋可以越來越強，起到很好的指示作用。
如果拖動的項目違反了規則，可以直接給出錯誤反饋。
例如我們想把四個列表一起拖到屏幕上的指定區域，如果不符合拖放規則，在拖動到該區域時給出錯誤提示，方便用戶了解規則。
3. 拖放后
拖放完成后，可以直接顯示一個拖放成功的提示，清晰地告知用戶操作成功。
例如把四個列表一起拖動到指定區域后，除了顯示操作完成，還可以把拖放的列表數量一起顯示出來，讓提示更嚴謹。
如果把四個列表一起拖動到指定區域后，每個列表還需要依次上傳，這個時候最好能提供上傳狀態的提示：
上傳中(進度)、已完成、上傳失敗等，讓拖動上傳的過程更加可視化。
三、最后
以上分析了拖放功能的使用場景和狀態，希望通過這些內容幫助大家了解「拖放」功能在設計中的用法，進一步提升體驗！
專欄作家
作者：Clippp，微信公眾號：Clip設計夾。每周精選設計文章，專注分享關于產品、交互、UI視覺上的設計思考。
本文原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。儲空間服務。
辦公還是游戲？這些顯示器你不容錯過
對于臺式機而言，一個好的顯示器是必不可少的；而對于筆記本電腦，一個好的顯示器顧然不是必需品，但卻能極大地提升筆記本的使用體驗。假如你在近期有購置電腦顯示器的計劃或是想對市面上主流的顯示器有所了解，那么你一定要看一看這篇文章，相信一定能給你帶來幫助。
那么接下來就讓我來推薦幾款不同的顯示器吧。
HKCS24Pro可壁掛辦公液晶臺式電腦顯示屏
對于許多有辦公需求的人來說，HKC近期正在預售的S24Pro會是一個很不錯的選擇。
在外觀上，23,8英寸的S24Pro采用了三面窄邊框的設計，屏占比高達92%，配合IPS面板設計帶來的178°超廣可視角度，相對比起市面上主流的14英寸寸和15.6英寸的筆記本電腦，S24Pro有著難以想象的廣闊視野。
在畫質體現上，S24Pro支持HDR10圖像解析，在接受HDR圖像輸入和輸出HDR圖像上都有著出色的表現。同時作為一款為辦公打造設計的顯示器，S24Pro有著90?I-P3和100%sRGB的廣色域覆蓋，在色彩表現上有著一流的水準。無論是簡單的日常辦公，還是專業剪輯，它都能提供純凈、準確的色彩呈現效果，成為你辦公時的利器。75Hz的屏幕刷新率更是讓它相比市面上普通的60Hz顯示器有著更加絲滑的屏幕流暢度。
此外，在輸入輸出上，S24Pro配備有HDMI、DP以及VGA等主流視頻接口，同時還支持Auioout音頻輸出接口，滿足日常辦公的需求可謂是綽綽有余。
除了不錯的性能之外，HKC在S24Pro的設計上還有著不少人性化的地方。對于許多需要長時間在電腦前學習、辦公的人來說，長時間面對屏幕所造成的眼部疲勞和損耗無疑是一大痛點。S24Pro作為專為辦公設計的顯示器自然不會忽略這點。針對這個問題，S24Pro通過了SGS低藍光認證，采用了不閃屏的DC調光方案，能夠降低長時間使用電腦屏幕對眼睛的傷害，緩解辦公時的眼部疲勞。
同時，S24Pro還設有獨特的電子書模式。使用該模式時，字體的顯示會變黑變粗，提供類紙張的閱讀效果，讓你在辦公學習時能夠更加清晰地閱讀文檔，同時緩解長時間閱讀帶來的眼部疲勞。
有時候我們雖然買到了好的顯示器，卻難有一個好的使用場景，一張不合適的書桌或者狹小的座位空間等等這些都會成為顯示器擺放時的難題。合理的顯示器擺放能帶來舒適的使用體驗，反之則會對身體造成不良影響，長期以往甚至會損害頸和背部。而S24Pro使用了人體工學支架，可以隨意上下升降、左右旋轉、調節俯仰和橫豎旋轉，支持VESA壁掛，可以根據不同的辦公環境來調節合適的屏幕擺放位置和角度，適應每個人不同的使用習慣，帶來舒適的體驗。
當然，如果你覺得23.8英寸還是不夠大，可以考慮一下升級款的HKCS27Pro，其在保留了S24Pro優秀的性能和設計之余，將23.8英寸的屏幕尺寸升級到了27英寸。
微星MSIG241電腦游戲電競顯示器
說完了辦公顯示器，那么接下來肯定要說一說游戲顯示器了，這里我推薦微星的G241顯示器。
說到對于游戲顯示器的挑選，大家第一時間想到的肯定是要挑選高刷新率和低延遲的顯示器。工欲善其事必先利其器，對于游戲玩家來說，想要有好的游戲發揮，好的游戲外設是必不可少的。在游戲時，除了鼠標、鍵盤和耳機以外，一塊好的顯示器同樣重要。對于FPS、RTS、MOBA類游戲來說，顯示器的高刷新率能讓游戲的畫面更加順暢，更好地觀察游戲人物的動作；而對于一些體育、競速類游戲，顯示器的高刷新率能大大減少游戲畫面中的運動模糊，提供更加舒適的游玩體驗。G241作為電競顯示器，144Hz的高刷新率對于游戲體驗上的提升自然是巨大的。同時其1ms的響應時間幾乎可以說是無延遲，讓玩家在游戲時能夠有更快的反應時間。
除此之外，為了更好地提升使用者的游戲體驗，微星在設計G421時還在額外功能的設計上下了一番功夫。比如增設了暗部動態提升功能，在開啟之后能夠智能地提升暗部的亮度，增加暗部細節，這不僅提升了游玩時的觀看體驗，還讓藏在暗處的敵人和游戲細節變得更加的顯眼。
另外，在玩射擊游戲時，一些游戲的槍械在不開鏡時是不帶有準星的，或者游戲本身自帶的準星不合適、難以自定義。而這時我們就可以使用G421自帶的準星功能，一鍵開啟準星，轉身一變成為讓人膽寒的“槍神”。
除了自帶準星之外，G421本身還預設了多種游戲顯示模式，可以針對不同的游戲來優化畫面，可謂是十分地人性化了。
同時G421還支持AMD的FreeSync技術，假如你的電腦搭載了AMD的顯卡，在開啟FreeSync之后能夠很好平衡顯示器和顯卡之間的連接和輸入輸出效率，避免造成畫面撕裂。過去我們在游玩一些對電腦的圖形處理能力較高的游戲時，往往會出現畫面撕裂的現象。百度解決的辦法，給出的答案不是開啟垂直同步，就是鎖幀。前者會使游戲產生操作延遲，后者會強制降低幀數到特定的水平以下，這兩種處理辦法其實都不能算得上完美。而G421所支持的FreeSync無疑是給這種窘況提供了第三種答案。
拋開游戲上的表現不談，G421在其他方面的表現同樣優秀。23.8英寸窄邊框設計、178°可視角度IPS面板和1920*1080分辨率都讓其在實際使用時有著不錯的觀感。接口方面，G421提供了1個DP接口，兩個HDMI接口和一個音頻接口，足夠滿足日常的使用。在顯示器的操作上面，G421使用了5維導航按鍵，用小搖桿來替代傳統按鍵，大大縮減了按鍵在顯示器布局上的占比，更加簡潔。同時，考慮到在公共場所的使用情況，G421還配備了Kensington安全鎖插槽。
微星MSIG2722大屏幕臺式電腦顯示器
當然，作為一名游戲玩家，對于外設硬件的追求總是越高越好的。假如你的預算充足，希望能有更好的選擇，不妨看看微星的G2722。
游戲性能上，相對比G421，G2722在各方面都有了極大的提升。除了帶有暗部動態提升功能、屏幕1ms低延遲響應外，屏幕尺寸提升到了27英寸，顯示器刷新率提高到了170Hz。同時，對于FreeSync技術的支持也提升到了FreeSyncPreium的檔次，在游戲體驗上可謂是全方位的升級。
屏幕設計上，G2722的屏幕使用了霧面設計，在光線強烈時不會產生反光現象，給眼睛帶來額外的負擔。同時G2722的屏幕還使用了不閃屏技術，并且支持經過TUV認證的防藍光技術，大大降低了長時間游戲時的用眼負擔。
而在外觀上，除了窄邊框的設計之外，G2722還特地在外殼上做出了金屬拉絲的質感，配合RBG燈效，可謂質感十足，單從外觀上就能給人一種電競游戲的氛圍。
G2722可以說是G421的Pro版本，在外觀、性能上都有極大的升級，假如你覺得G421的參數規格還是不足以滿足你對于游戲體驗上的追求，那么G2722是非常值得考慮的。
以上就是對于電腦顯示器的一些推薦，不知道這里面是否有大家心儀的款式。早買早享受，有顯示器購買需求的小伙伴們快下單吧！
電競玩家最關鍵的配件，顯示器該如何選購
顯示器，作為PC最重要的一個輸出端，負責了人的視覺體驗與輸入反饋。近年來隨著高刷技術的普及和制造工藝的進步，電競顯示器也走進了千家萬戶，擁有一臺電競顯示器也成為了多數玩家的需求。那么市面上這么多的電競顯示器究竟選哪款好呢？今天就為大家推薦三款電競顯示器，讓你在游戲里先人一步，看透對手，制勝殺敵。
HKC馬卡龍系列顯示器TG271Q
惠科（HKC）作為國內的老牌顯示器廠商，最近推出了馬卡龍系列顯示器，這款TG271Q便是其中的一員。單看顏值，這款顯示器就已經處于不敗之地了，采用的全身純白設計，背后極具設計感的圓環設計，可多角度的旋轉支架……
當然在它的完美顏值之下，不能忽略的是它的性能。其采用FastIPS面板，在降低了響應速度的同時，刷新率達到了170Hz，為電競助力。電競跟上了，那么畫質也要跟上，分辨率來到了2KQHD，色域也滿足了90%的DCI-P3，在創作方面也能夠滿足需求，滿足多樣的需求。
卓威ZOWIEGEARXL2546K
卓威作為電競裝備的老牌廠商，其實力毋庸置疑。最近它就推出了旗艦級顯示器XL2546K。這款顯示器作為CSGOMajor的比賽用機，必然是經過無數頂尖FPS玩家考驗過的。其支持XLsetting，讓你通過云端同步設置，與職業選手同步。同時，S-Switch裝置還支持多種預設，讓它適配任何場景。
XL2546K搭載的DyAc 技術還可以提高動態畫面清晰度，減少拖影，更好的去掃射，有更好的定位手感。而暗部增強等技術就更不用多說了。
值得一提的是，XL2546K隨機還附贈了一個遮光面板，讓畫面不受光線影響，可以說是處處為電競所打造。
微星(MSI)MEG381CQRPlus
可能大家都沒有想到，原本做電腦DIY硬件的微星也做上了顯示器。這款MEG381CQRPlus便是它的旗艦之作，用堆料打敗一切，家里有礦的典型代表。采用21：9的準4K屏幕，還帶175Hz刷新率，2300R能夠讓你更加沉浸……光看正面參數就已經接近無敵。
當然，它在堆料的同時，也沒有忽略人機工程。配備設置了獨立的操控旋鈕和液晶屏，組成HMI交互系統，快速完成燈光、預設調節。機器還通過了HDR600認證，提供了更多的動態范圍和圖像細節，畫面栩栩如生。微星為其單獨開發的OSD面板擁有多種游戲功能，方便快捷。
總結：這三款顯示器分別對應了不同的價位段，別看他們價位差得多，但是卻各有特色。HKC顏值超高又有實力不凡、卓威則對電競有著強大技術支撐、微星則有強悍的面板數據和人機交互，可以說各有千秋。如果有小伙伴想要再近期購入顯示器，可以考慮上面這幾款，絕不會讓你失望的。
萬字長文：深入淺出RBAC權限設計
權限管理是B端中常見的話題，它規定了用戶各自的角色和可使用的職能，也對數據的安全提供了保障。本篇文章中作者結合自身經驗，從四部分講述關于權限管理的設計經驗與設計方法。
權限管理是B端產品繞不開的話題，本文總結了我對權限管理的設計經驗與設計方法，共分為4個部分：
權限管理的概念梳理
RBAC權限設計的一般步驟
設計功能權限的三板斧：基礎版（權限、角色、用戶管理）、進階版（部門、職位、菜單管理）、拓展（版本管理）
如何設計數據權限
所有內容均根據自身思考實踐及經驗借鑒而來，如有錯誤歡迎指正。
第一章：權限管理的概念梳理
一、權限是什么
權限包括了功能權限和數據權限：
功能權限是系統執行權限控制的基本單元，包括頁面權限、菜單權限、按鈕權限等
數據權限包括基礎數據、業務數據、資源數據等
針對功能模塊劃分用戶權限是一種粗顆粒度的劃分方式，表現在不同用戶可以查看相同的數據，但可執行的操作不同，如線上數據庫的數據只有超管可以刪除，其他人只能查看；針對數據劃分用戶權限是一種細顆粒度的劃分方式，表現在不同用戶進入同一頁面/菜單時，可見的數據有差異，如運營經理可以看到部門所有數據，運營人員只能看到自己創建的數據。做權限設計時，首先要分清功能權限和數據權限的界限，不要為了圖方便將二者揉起來。
二、為什么需要權限管理
三、權限設計的核心思想
權限管理是用來控制用戶可以訪問而且只能訪問某些資源的系統，根據該定義，我們可以繪制出如下示意圖：
可以看出，用戶和資源形成了錯綜復雜的映射關系，很難管理。要解決這一問題，有兩種方法：一是減少用戶/資源數，顯然不切實際，這樣就只剩下了一種方法——減少映射關系。
在詳細介紹該方法前，我們先來看看數據庫中是如何解決查詢慢的問題的。大家可以思考一個問題，在【35、27、48、12、29、38、55】這組數列中如何快速找到數字55？
大部分人的第一反應就是一個個遍歷，這樣一共需要查詢7次。而對數據庫工程師來說，首先會找到一個媒介來構建這組數列的表示關系（見下圖-平衡二叉樹），然后再通過簡單的判斷只用3次就可以找到55了。這個媒介就是數據庫中的索引，在數據量巨大的時候，利用索引進行查詢的優勢十分明顯。
如果這個例子不好理解，大家還可以聯想下字典中的索引、書籍中的目錄或是圖書館中的書架標簽，核心思想都是抽象出對象的公共屬性，再進行分類管理。
利用這一思想，我們再來回看如何減少用戶和資源的映射關系。
判斷用戶與用戶之間是否有公共屬性？
找到對權限有影響的公共屬性，比如部門、職位等
不斷抽象出中間媒介
對于資源也是同理。
經過以上步驟，原本雜亂無章的映射關系就變得既簡約又有層次（見下圖），我們只要把權限賦予到抽象出來的虛擬媒介上，就能夠大大降低管理的復雜程度。
四、權限管理模型的演進
了解了權限設計的核心思想后，我們以CMS系統的更新為例來闡述權限管理模型的演進。
1. ACL：基于用戶的權限管理模型
小王是一家創業公司的產品經理，負責一款CMS系統的設計。起初，網站的所有內容都由公司唯一的運營小紅負責，所以小王就對小紅的賬號開啟了所有權限。
這種直接將權限綁定在用戶賬號上的方式就叫做基于用戶的權限管理（ACL）。
2. RBAC：基于角色的權限管理模型
隨著運營部門不斷發展壯大，每次有新員工入職，小王都要為其單獨配置權限，而且無法批量修改，十分繁瑣。同時小王發現運營部門分工明確，部分人員負責內容審核，需要為他們開啟審核管理的權限；部分人員負責產出內容，需要為他們開啟內容管理的權限……這就導致小王經常會做一些重復性的工作。于是小王就想在現有的用戶層上再抽象出一層——角色層，只要對角色設置權限，屬于該角色的人員就自動擁有這些權限。
這種將權限綁定在角色上，再給用戶賬號賦予角色的方式就叫做基于角色的權限管理（RBAC），該模型于1992年由美國國家標準與技術研究院組織開發，是目前最通用的權限管理模型，節省了很大的權限維護成本。
GerorgeMason大學的教授Ravi Sandhu于1996年對RBAC模型進行改進，提出了RBAC96模型族，包括RBAC0、RBAC1、RBAC2和RBAC3四個模型。上圖代表RBAC0模型，也是其他3個模型的基礎。
a. RBAC1：角色繼承的RBAC模型
在CMS系統使用了一段時間后，小王發現了一個新問題——系統中存在的角色太多了，因為只要有權限不一樣的用戶加入系統，就需要新建一個角色，當用戶權限分得很細的時候，甚至比ACL還繁瑣，于是小王就想著手解決這一問題。
點他發現角色之間存在著類似組織架構一樣的上下級關系，比如COO>運營經理>運營主管>運營組長>運營人員>運營實習生，并且上級擁有下級的所有權限，同時可以額外擁有其他權限，于是他在現有的角色基礎上又抽象出一層角色等級。
這種在角色中引入上下級關系的RBAC模型就叫做角色繼承的RBAC模型（RBAC1），通過給角色分級，高級別的角色可繼承低級別角色的權限，一定程度上簡化了權限管理工作。
另外角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系要求角色繼承關系是一個絕對偏序關系，允許角色間的多向繼承，即下級角色可以擁有多個上級角色，上級角色也可以擁有多個下級角色。而受限繼承關系則要求角色繼承關系是一個樹狀結構，角色間只能單向繼承，即下級角色只能擁有一個上級角色，但是上級角色可以擁有多個下級角色。
b. RBAC2：角色限制的RBAC模型
過了一段時間，運營經理小紅向小王反饋，她的賬號竟然可以看到公司的財務賬單，經過核查，是小王由于粗心導致給小紅的賬號多綁了一個財務經理的角色。為了徹底規避這種風險，小王就讓開發加了一條判斷：當角色是運營經理時不能同時是財務經理。
這種針對角色進行限制的模型就叫做角色限制的RBAC模型（RBAC2），可以把限制具體地分為靜態職責分離（SSD）和動態職責分離（DSD）：
SSD：
互斥角色：同一用戶只能分配到一組互斥角色集合中至多一個角色，比如用戶不能同時擁有會計和審計兩個角色
基數約束：一個用戶可擁有的角色數目受限；一個角色可被分配的用戶數量受限；一個角色對應的權限數目受限
先決條件角色：用戶想要成為上級角色，必須先成為下一級角色，比如游戲中的轉職
DSD：允許一個用戶具有多個角色，但在運行時只能激活其中某些角色，比如BOSS直聘，一個用戶既可以是招聘者也可以是應聘者，但同時只能選擇一種身份進行操作
c. RBAC3：統一的RBAC模型
RBAC3=RBAC1 RBAC2，既引入了角色間的繼承關系，又引入了角色限制關系。
d. 組：完善的RBAC模型
現有的權限管理模型雖然已經對“角色”進行了層級優化，但并沒有優化“用戶”方，這就意味著每入職一個新員工，小王得單獨為其設置權限，還是很麻煩，于是他利用抽象的思想將相同屬性的用戶進行歸類。在公司里，最簡單的相同屬性就是“部門”了，如果給部門賦予了角色和權限，那么這個部門中的所有用戶都有了部門權限，而不需要為每一個用戶再單獨指定角色。
用戶可以分組，權限同樣也可以分組。在權限特別多的情況下，可以把同一層級的權限合并為一個權限組，如二級菜單下面有十幾個按鈕，如果對按鈕的操作沒有角色限制，可以把這些按鈕權限與二級菜單權限合并為一個權限組，然后再把權限組賦予角色就可以了。
“組”概念的引入完善了RBAC模型，在簡化操作的同時更貼近了實際業務，便于理解。
3. ABAC：基于屬性的權限管理模型
為了內容的安全，運營經理小紅向小王提了一個需求：負責內容管理的人員不可以在公司以外的地點發布內容。這可難倒了小王，因為現有的RBAC權限模型僅能對頁面/功能/數據賦予權限，沒法執行如此精細的權限控制。在查閱相關資料后，小王找到了該問題的解決方法——基于屬性的權限管理模型（ABAC）。
ABAC是通過動態計算一個或一組屬性是否滿足某種條件來進行授權判斷的，包括用戶屬性（如性別年齡）、環境屬性（如時間地點）、操作屬性（如編輯刪除）和對象屬性（如一篇文章）。
跟RBAC相比，ABAC能夠實現非常靈活的權限控制，可擴延展性也很高，幾乎能滿足所有類型的需求。但是設計起來比較復雜，而且對于單一屬性可以通過編寫簡單的判斷邏輯代替，所以還沒有被廣泛應用。
五、權限管理與權限體系
權限管理是指為解決某一具體的權限分配問題而采用的方法，比如解決文件的權限分配問題可以采用ACL模型，解決不同年齡段的用戶可訪問不同類型的電影問題可以采用RBAC ABAC。
而權限體系是指整個系統內采用的權限管理方法的集合。
本系列文章聚焦于單系統內的RBAC權限管理。
六、權限設計的誤區
1. 唯RBAC論
盡管RBAC已經被廣泛應用，但還是要避免一上來就這么做。權限的設計需要評估數據量和業務復雜度，如果預估的數據量特別少，業務又很簡單，那完全可以用其他方式。
2. 唯自由配置論
不要認為把權限設置得靈活可配用戶就滿意了，實際上用戶沒有那么聰明，他會為角色名稱而糾結，看到一系列的權限配置也會不知所措。如果你的業務能夠抽象出一些固定角色和統一權限，那就把他們內置起來。
3. 權限越多/越細越好
權限不是功能列表，一味地細化而不注重實際業務，只會增加開發工作量，也不利于用戶配置。可以僅選擇常用的功能點作為權限配置，也可以將多個功能點抽象為一個權限點，如將“增刪改”三個功能抽象為一個“管理”權限點。
第二章：RBAC權限設計的一般步驟
一、梳理角色
1. 羅列所有角色
角色是一種抽象的身份，RBAC離不開角色，因此第一步就是從業務中找到所有可能涉及到的角色。
如果你做的是企業內部管理系統（如ERP、OA），可以參考組織架構找到所有角色（如產品經理、產品助理、項目負責人）；其他系統可以通過業務流程找到相關角色，如開展一次線上筆試按流程需要出題老師、題目審查老師、考場管理員、助理、監考老師、巡考老師、考生、閱卷老師。
2. 找到各角色之間的關系
找到所有角色后，第二步就是找出各角色之間的聯系。常見的有繼承、互斥和共享關系，還可根據實際業務找到角色之間的其他關系：
等級/繼承：產品總監、產品經理、產品助理、產品實習生
互斥：財務和審計不能是一個人
共享：閱卷老師和監考老師可以是同一個人
串行：先由產品經理進行設計再由開發人員開發
并行：前端后端一起開發
……
3. 分析角色是否需要內置以及是否需要隱藏
分析哪些角色我們可以事先定好，哪些角色可由用戶自定義。內置角色適用于角色通用且固定、使用頻率高的情況，目的是為了簡化用戶的操作步驟。常把“管理員”角色進行內置，也可根據實際業務選擇，比如線上考試系統，“考生管理”菜單就屬于內置角色，添加到該列表中的賬號只能是“考生”。
同樣還要考慮角色是否需要展示給用戶，比如一些系統的“超級管理員”就不需要展示給用戶。
二、梳理權限
1. 梳理功能權限
權限分為功能權限和數據權限，其中功能權限又可分為菜單權限和按鈕權限。
梳理功能權限一個最簡單最實用的辦法就是用“功能列表”（下圖以“有贊”為例）。
2. 梳理數據權限
數據權限就是系統中存在的數據、資源能夠被誰查看和管理。說到數據權限，就不能不提數據庫。
1）表/對象
表是包含數據庫中所有數據的數據庫對象，不同的業務數據存在于不同的表中，如下圖從上到下依次為考生表、考場表和考官表。
2）數據
表中存放著二維數據，由行和列組成，如下圖的考生表，每一行代表一個考生，每一列代表考生的一個屬性。
通過表和數據之間的關系，可以把數據權限分為以下四種情況：
（1）基于系統的數據權限
即系統中的所有表都能被大家看到并管理，也可理解為沒有數據權限，比如管理員A、B都能看到并管理所有考生、考官、考場數據。
（2）基于對象的數據權限
即按表劃分數據權限，比如管理員A只負責管理考生，管理員B只負責管理考場。
（3）基于行的數據權限
即按表中的數據行劃分數據權限，比如管理員A只能管理B學校的考生，但不能管理C學校的考生；或者A部門的經理只能看到A部門職員的周報。
（4）基于列的數據權限
即按表中的數據列劃分數據權限，比如管理員A只能看到考生的姓名，而管理員B可以看到考生的姓名、手機號和身份證號。
在梳理數據權限時，可根據實際業務對對象、行和列的數據權限自由組合，比如針對學校A的管理員只能查看學校A的考生及考官的姓名和電話號碼，無法查看身份證號這個需求，就使用到了基于行和列的數據權限。
三、連接角色與權限
1. 連接角色和功能權限
得到功能列表后，需要跟角色關聯在一起，可直接在表后添加角色列，再根據業務對角色是否擁有該功能權限做判斷。
2. 連接角色和數據權限
數據權限一般是一系列的規則，可通過文字描述附在上表后。
3. 分析與整理
所有的權限都需要進行分配，但不是每個權限都值得讓用戶來配置。
在上一步完成后，我們就建立起了所有角色和權限的聯系，但上表還不能直接使用，在詳細設計之前，還要分析出哪些權限需要用戶手動分配，哪些不需要？哪些功能權限可以合并，以便減少用戶操作次數？什么場景下數據權限需要可配置？等等這些必須得根據具體的業務進行判斷。
仍以“有贊”為例，上圖是配置“線索管理”功能權限的實際頁面，可以看到它只為用戶提供“查看、編輯、轉讓、放棄、添加資料項、辦理試聽”這幾個功能，其他的功能權限要么都歸屬于“查看”（添加、辦理報名等），要么合并到一個功能里（“批量轉讓”合并到“轉讓”）。
理論上是可以把所有的功能權限拿出來讓用戶配置，但是考慮到用戶體驗，對權限進行分析和整理是非常有必要的。
第三章：設計功能權限的三板斧
通過上述分析，我們得到了最終的角色與權限的關系，接下來就進入到如何設計界面的環節。
設計功能權限離不開最基本的三要素：用戶管理、角色管理、權限管理；根據業務的不同，可能還會涉及更復雜的三要素：部門管理、職位管理、菜單管理，在這些之上還會配置不同的版本滿足不同的客戶需求，這就需要版本管理，下文將會對如何設計這些管理功能進行詳細的介紹。
一、三板斧-基礎版
1. 權限管理
權限管理是為角色賦予權限，權限可以內置，也支持用戶自定義，權限的配置需要跟角色綁在一起，當權限較簡單且相對固定時，可由后端人員寫死在代碼里或者寫死在配置文件里。
2. 角色管理
在“梳理角色”步驟中，我們列出了系統中涉及到的所有角色，“角色管理”就是對這些角色進行線上化的鏡像和管理。
按角色的來源可分為用戶自定義角色和系統內置角色：
自定義角色：角色的名稱和權限都可由用戶自由配置，并可任意修改。
內置角色：角色的名稱和權限由系統內置好，用戶僅可查看無法修改。
設計“角色管理”主要有三個頁面：
角色列表頁：展示系統中的所有角色，至少應顯示角色名稱以及查詢、刪除（自定義角色）、查看（內置角色）、新增、編輯等操作。
添加角色頁：必須輸入不可重復的角色名稱，可選填狀態、備注、排序等信息。交互方式上可根據頁面內容的豐富程度選擇彈窗或抽屜的形式。
配置權限頁：可在創建角色的同時配置權限（見上圖），也可在創建角色后配置權限（見下圖），兩種方式沒有本質區別。
另外在一些系統里，綁定權限的這個載體不叫“角色”，而是其他的名字，比如在釘釘中叫“管理組”，這里我們要清楚它其實就是“角色”。
3. 用戶管理
“用戶管理”是用于管理用戶信息的，如更改用戶角色、創建或刪除用戶、更改密碼和用戶信息。
設計“用戶管理”主要有兩個頁面：
用戶列表頁：展示系統中所有的用戶。應支持新增、編輯、刪除、導出、導入及批量操作。
添加用戶頁：根據業務選擇創建時需要的字段。添加用戶時，必須為用戶設置角色，可選角色為“角色列表”中存在的自定義角色和內置角色。
同“權限分配”一樣，“角色分配”也可以單獨放在用戶列表中的操作里，這樣的交互更專一，但實際沒有什么不同。
4. 注意事項
1）用戶與角色
需要根據實際業務確定一個用戶可以綁定多少個角色。如果可以綁定多個角色，角色之間有沒有繼承、互斥等關系，功能權限如何劃分，這些情況都要提前考慮到。
另外，如果有內置角色，別忘了在內部的“運營管理平臺”上設計專門針對“內置角色”的管理功能。
2）角色間的關系
上文中我們列出了角色之間的關系（等級/繼承、互斥、共享等），現有的“角色管理”僅能通過一個用戶綁定多個角色的方式實現“角色共享”，但沒法實現角色間的繼承和互斥。
角色間如果有繼承關系，可通過下文的“角色組（職位）管理”實現；如果有互斥關系（如會計和審計），對于內置角色可以在代碼中寫死判斷，對于自定義角色，可以讓用戶另外設置互斥規則。
3）權限組
上文說的分析與整理，其實就是建立權限組，將不必要的權限進行合并，可以簡化用戶操作。
經過以上步驟，一個基本的權限系統就設計完成了，足夠應付80%的場景。
二、三板斧-進階版
如果是做OA系統的權限管理，或者對靈活度有較高的要求，那么可以了解下進階版的權限管理三板斧。
1. 部門管理
“部門管理”有三種使用場景。第一種是為了構建企業的組織架構，在這種情況下，部門管理與功能權限沒有關系，僅用于歸類用戶以及分配數據權限。
與功能權限有關系的是下面兩種場景：
第二種場景是為了承擔“用戶組”的作用。在上文介紹RBAC中，如果用戶量很多時，將每個用戶與角色權限匹配會十分麻煩，這時就需要將用戶的共有屬性做抽象，在企業中，用戶的共有屬性可以用部門來表示。
第三種場景是為了承擔“角色”的作用，可以為部門直接賦予功能權限，部門中的用戶繼承該部門的功能權限。若用戶也擁有其他角色的權限（如下圖的用戶2），則實際的功能權限為二者的并集。
另外在分配部門權限時，還需要考慮子部門與父部門的權限關系：可以選擇同父部門的權限保持一致，也可以選擇子部門繼承父部門的權限，并可在其范圍內進行編輯，還可以設置完全區別于父部門的權限，這取決于業務的復雜程度。
2. 職位管理
“職位管理”有兩種使用場景。第一種是為了完善員工信息，屬于一種屬性，與功能權限沒有關系。
第二種場景與功能權限相關，是為了承擔“角色組”的作用。“角色組”是為了滿足上下級關系而衍生出的概念，比如“產品經理”應該擁有“產品助理”的所有權限，有了上下級后，再來一個“產品總監”的角色，就不用單獨為其設置所有的功能權限，只需將它設為“產品經理”角色的父級，再添加一些特殊的權限即可。
3. 菜單管理
不管是“部門”還是“職位”，解決的都是“用戶”和“角色”怎樣配置更靈活的問題。在RBAC中還有一個“權限”，目前對權限的管理只介紹了可以通過后端人員寫死在代碼里或者寫死在配置文件里，如果功能權限經常變動，并且自由配置的需求極高，有沒有更靈活的辦法來管理權限呢？有！就是“菜單管理”。
“菜單管理”又被稱為資源管理，是系統資源對外的表現形式。有了“菜單管理”，不僅可以讓權限的管理更簡單（不需要后端寫死），還能夠讓系統展示更靈活（能夠改菜單信息）。
“菜單”分為三類：
目錄：在系統內沒有實際頁面
菜單：存在實際頁面
按鈕：菜單中的可操作項
設計“菜單管理”主要有兩個頁面：
1）菜單列表頁：
導航菜單是分上下級的，因此可以用樹狀圖表示，常見的菜單屬性包括菜單名稱、菜單類型（目錄、菜單、按鈕）、圖標、排序、路由地址（瀏覽器訪問菜單的地址）、組件路徑（項目的組件文件的路徑）、權限標識（查看、編輯、添加等）、是否外鏈、啟用狀態和創建時間。除了圖中展示的字段，根據業務需求還可以增加“編號、是否打開新頁面、是否隱藏、是否緩存（切換到其他菜單當前菜單會進行緩存）”等字段。
2）添加菜單頁：
添加目錄：目錄可以是外鏈，即點擊后跳轉到外部地址，必須帶上https://或者http://，如果不是外鏈，則需要填入路由地址，由開發人員給出。
添加菜單：當菜單是外鏈時，規則同目錄，若不是外鏈，則可選填組件名稱、權限標識、組件路徑（具體應跟開發討論系統中是否有涉及）。
添加按鈕：添加按鈕時，輸入權限標識即可。
4. 注意事項
1）誰繼承誰
關于“權限繼承”，細心的讀者會發現我在第一章介紹RBAC時寫過：“高級別的角色可繼承低級別角色的權限”，而在本章中又說：“子部門可以繼承父部門的權限”，是不是沖突了。
其實不然，假設現有AB兩個部門，要在它們之上設立一個部門C，則C部門的權限為AB兩個部門的并集，從這個角度講，部門C繼承了部門AB的權限，且部門C還可單獨設置權限；而如果要給部門A下設一個部門C，部門C會繼承部門A的權限，并可在此范圍內細化權限。兩種說法表達的意思是一樣的，都是子級屬于父級的權限范圍內。
2）功能權限最好不要綁在多個實體上
在上面的介紹中，“部門”、“職位”都可以充當“角色組”直接綁定功能權限，但在實際中卻很少有系統這么設計，根本的原因就是沒有必要——功能權限最好只綁在一個實體上，意思是說，如果系統中已經有了“角色管理”（為角色設置功能權限），就沒有必要再對部門或職位設置功能權限了，同樣如果系統中已經為了部門/職位設置了權限，也就沒有必要再引出“角色”這個概念了。因為在現實工作中，很少有人在部門、職位和角色上有單獨的功能權限，即便是有，也可以通過新建一種“角色”來簡化復雜度。如今大部分的OA系統上，職位和部門更多被用于用戶歸類以及管理數據權限。
3）菜單管理如何實現權限組
需要注意的是，“菜單管理”是精細到系統中最小的操作，可以直接用于分配角色的權限，但如果為了提升用戶體驗，需要給用戶展示出合并后的功能權限時（見下圖），則不可在“菜單管理”中直接設置“查看與操作”的按鈕，而應該在“菜單管理”之上建一層專門用于展示給用戶的功能權限，其中“查看與操作”權限綁定了“新建 編輯 刪除”的按鈕。
5. 拓展：版本管理
對于SAAS軟件，常常會分多個版本來滿足不同層次的客戶需求，不同版本之間的功能權限會有差異。面對這種情況，可以通過“版本管理”來實現靈活管理（此“版本”非產品迭代的版本）。
設計“版本管理”主要有兩個頁面：
版本功能權限配置頁：類似于為角色分配權限，這里可以理解為為版本分配權限。不同的是這里的功能權限會比“菜單管理”中的權限更細致。以“題目管理”為例，一般在“菜單管理”中，只會設置到一級頁面的“添加、導入、刪除、編輯題目”按鈕，但在版本管理中會細化到題目類型，如免費版不能添加“聽力題”，甚至會對功能的可用次數進行限制。有兩種設計方案可以解決這一需求，如果每個版本之間的權限分得又細又多（見本節第一張圖，考試星的版本功能對比），那么最好在菜單管理中覆蓋掉所有子頁面的按鈕，可用次數以單獨的規則進行限制；如果版本之間只是個別的細小功能有差異，則在現有“菜單管理”的功能基礎上添加限制規則即可。
還有一種更復雜的情況，同一版本的不同客戶之間也會有不同的功能權限，那么還需要對每一個客戶配置功能限制。
第四章：如何設計數據權限
上文講過數據權限分為四種情況（劃分依據詳見第二章）：
基于系統的數據權限
基于對象的數據權限
基于行的數據權限
基于列的數據權限
其中”基于系統的數據權限”可以理解為不分數據權限，因為大家看到的和可操作的內容都是一樣的；“基于對象的數據權限”可以通過功能權限來實現，比如為用戶A分配了客戶表的權限，那么A就能夠看到并操作所有客戶，也就相當于為用戶A分配了“客戶管理”的功能權限。因此下文主要討論后兩種情況。
另外，數據權限的分配也可分為內置和用戶自定義兩種。內置數據權限屬于系統中寫死的規則，如本校老師只能看到本校的資源，公共庫中的資源所有學校的老師均可看到，銷售人員創建的線索只有自己能夠管理等等，內置數據權限過于簡單，也不在本文討論范圍內。
一、基于行的數據權限
基于行的數據權限分為兩種情況，一種是為對象（部門/角色）分配數據，如上級部門可以管理下級部門的所有數據；還可以將數據分配給對象，如共享文件。
1. 為對象分配數據
1）無組織架構
對于不涉及組織架構的系統，數據權限的設計比較簡單，在為角色配置權限時，一并展示可分配的數據權限即可。
分配數據權限的前提是分配了對應的功能權限，比如要讓計算機老師只能管理“軟件工程”的所有題目，前提是要給老師開啟“題庫管理”的功能權限，否則老師連“題庫管理”都看不到，何來管理其中的題目數據。當然功能權限不一定非要手動分配，也可以內置，比如藍湖，加入的成員默認開啟了“團隊文件”的菜單，所以在配置時只需要展示數據權限列表。
2）有組織架構
可以通過設置“管理范圍”實現上下級之間的數據權限控制。比如針對上級可以看到下級的題庫這一需求，可以設置一個“部門負責人”角色，并設置管理范圍為“所在部門和下級部門”，然后將公司領導、各部門負責人都添加成這個角色，即可實現該需求。
也可以通過設置“管理范圍”實現跨部門之間的數據權限控制。比如針對研發部負責人可以看到IT部門題目的需求，則可以新建一個角色，管理范圍選擇“特定部門”，并勾選“研發部和IT部”。
還可以通過設置“管理范圍”實現同部門之間的數據權限控制。比如都是產品部，產品組長能看到下屬創建的題目，但看不到產品總監創建的題目，產品助理只能看到自己創建的題目，這時就需要用到職位的層級關系。
2. 為數據分配對象
可以理解為把數據直接共享給某個角色/部門，常用于文件/資源的共享，下圖是釘釘上對文件的權限管理。
二、基于列的數據權限
如果說數據權限是對功能權限在縱向的擴展，那么字段權限就是在橫向的擴展。因為設置數據列權限可以禁止指定角色對某些敏感字段的訪問，如身份證號、交易金額等。
設計“列權限”主要有兩個頁面：
入口：可以在創建角色時一同設置，也可以單獨作為角色的一個操作，還可以放在“角色管理”中對所有角色批量設置，更可以在對應的菜單頁面中進行設置。
列權限設置頁：下圖展示的是對所有角色批量設置列權限的設計，列出有各功能權限的角色和該菜單中的字段，由用戶勾選即可。
全文完。
最后做個總結，本文第一章講了權限管理的基本概念，第二章講了RBAC權限管理在設計前的分析步驟，第三章和第四章分別講了如何設計功能權限（權限、角色、用戶、部門、職位、菜單、版本）和數據權限（基于行和基于列）。文中部分圖片手機看不清，可用電腦端打開，內容如有錯誤歡迎指正。
本文由 @產品亂彈 原創發布于人人都是產品經理，未經作者許可，禁止轉載
題圖來自 unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。