中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

用戶權限管理是平臺類產品的基礎，怎樣設計平臺的用戶權限對后續的場景和拓展至關重要。本文通過簡單的例子總結幾點“用戶角色權限”設計思路供大家參考。

我是在2016年的一個B端管理項目中第一次接觸到用戶權限設計，因為當時是測試+需求分析的職責，所以只是把這里面的功能梳理明白，知道怎么用，并沒有深入思考。

轉崗產品之后，經常會在社群里看到有人問類似于用戶管理怎么做，權限設置怎么控之類的問題，這類問題幾句話也說不明白。

所以今天把自己對這部分的理解整體梳理出來，既能作為部門新入職同事的培訓材料，同時也希望對讀到這篇文章的你帶來一點幫助。

01 為什么進行用戶權限設計？

其實用戶權限設計對于C端產品也經常遇到，比如普通用戶、VIP用戶可能看到的功能就不一樣，或者同樣的頁面看到的數據也不一樣。不過更廣泛的應用還是在B端產品，或者C端產品的管理后臺（平臺管理端）

我們以B端產品為例，平臺提供了200個功能菜單，500個功能按鈕，但是使用者的身份不同，或使用目的不同，有的人可能只用到其中的一小部分功能。

或者對于企業來說，不同人員的分工不同，相同部門但不同級別的人員可操作權限不同、可查看的數據不同等等，這些實際的使用場景都最終指向了產品中靈活的、可自定義配置的權限管理功能。

這樣說可能比較寬泛，我們代入一個實際的場景（能理解的可以直接跳過看下一小節）。

一家兩百人的互聯網企業，分為研發部、銷售部、財務部、人事部，這家企業采購了一個數字化辦公軟件。

• 人事部用它對企業的人員信息、招聘信息、員工的入職、轉正、調崗、離職等進行管理；
• 財務部用它制定公司的成本預算、記賬報賬、核算并發放工資、歸檔發票等；
• 而全體員工也都使用平臺進行OA辦公，線上流程發起及審批；
• 企業高管則通過平臺的各類統計功能監控、查看企業的日常經營數據。

在這個場景中，平臺的功能頁面可能有幾百個，但是針對不同的部門人員，登錄之后看到的功能菜單是不盡相同的，或者同一個菜單的操作權限也是有差異的。

• 比如【入職信息查詢】頁面，hr和行政都能查看，但是hr有【入職】的按鈕，行政卻沒有；
• 比如財務部的財務專員A和B，一個負責研發部預算，一個負責銷售部預算，雖然他們都能訪問預算功能，但看到的數據也是不一樣的；
• 而C作為財務部總監，全公司的預算數據都可以看到。

以上提到的場景都是實際應用中最常見的，我們一起來看看如何進行設計吧

02 用戶權限設計的幾個關鍵詞

我習慣于把權限分為以下幾類：

1）頁面權限

即功能菜單的權限，以一級菜單->二級菜單->三級菜單->四級菜單的級別依次呈樹形排列。勾選上的菜單即可訪問，同時被選擇菜單的上級也默認被選擇（好比沒有單元門，你怎么找到家門？）。

2）按鈕權限

按鈕通常分為“增、刪、改、查”四大類，增的類型有很多，涉及的業務面也很廣，比如新增員工信息、新增預算信息、新增發票信息等，都屬于每個頁面權限下的“增”。對于四類操作，一定不是擁有這個頁面就一定擁有所有操作權限，因為很多人可能只有查的權限。所以要做好權限控制，一定要做按鈕的控制。

以上兩部分又可統稱為功能權限。

同時我準備了兩個常見的功能權限配置樣式，拋磚引玉，希望能給你帶來一點思路：

方案1

方案2

3）數據權限

最常見的數據控制手段是基于“組織架構樹”，組織架構（部門/分支機構）中的上級可以查看本級及下級的所有數據，或者可以指定某個組織的數據。

4）應用權限

這是后續衍伸出來的功能組集合。我們可以把一個功能組抽象為一個應用。比如按照上面的例子，可以把產品內的功能合并成以下幾類：包含了人事服務、財務服務、辦公服務、假勤服務、數據服務、客戶服務等幾大應用。我們可以先整體為這家企業賦予某些應用的權限，再在這些應用下為用戶分配不同的功能權限。

當然，如果我們把它定義為頁面權限中的一級菜單，也是可以的，只不過當平臺內的功能越來越多時，一級菜單的個數也會很多，菜單的級別也會很深。所以再單獨抽象一個新的功能組概念，不僅從理解上更清晰，看起來也高大上了一些~而且這些功能組后續還能作為增值服務為B端客戶設置開通、付費等衍伸場景。

除了權限的分類，為了最終達成設計目標，我們還會引入【角色】的概念。

1）角色

角色是上述幾類權限的集合

我所理解角色的設計目標是：為了解耦，為了可批量配置化（具體關系請看第三小節）。

• 比如財務專員角色，包含了10個頁面，25個按鈕，數據為只能看到研發部；
• 人事專員角色，包含了20個頁面，15個按鈕，數據為全公司。

2）用戶

用戶是平臺的使用者，用戶登錄之后能夠看到的，能夠操作的數據，都來自于我們為這個用戶賦予了哪些角色，這些角色中擁有哪些權限。

• 比如張三和李四都是財務專員角色，就可以在10個頁面中看到研發部的相關數據，并進行25種操作；
• 比如王五和趙六是人事專員角色，就可以在20個頁面中看到全公司的相關數據，并進行15種操作。

當然，如果張三升職了，變成了統管財務和人事的負責人（財務主管），那么我們可以為張三同時賦予兩個角色，張三的功能權限和數據權限就變成了這兩個角色的“并集”。

（請自覺忽略我的“靈魂畫筆”）

03 基本的設計關系

通過【角色】將各類權限匯集起來，批量賦予每個【用戶】，再通過組織架構將每個用戶的數據權限進行篩選。

最終功能權限和數據權限結合，呈現給用戶。

組合的方式也有兩種，我們可以根據自己產品的實際情況進行選擇。

方式1（功能權限+數據權限=角色->用戶）

方式2（功能權限->角色 + 數據權限 =>用戶）

無論哪種方式，都可以保證設計的關聯性和清晰度，還能在修改時減少操作環節。

比如方式1中，企業現在有10個人擁有財務專員的角色，如果要給財務專員增加15個新的功能，并增加對銷售部的數據管理范圍，我們只需要針對【財務專員】這個角色進行一次修改即可生效。

04 進階的設計方法

1. 對于企業多級部門的數據權限配置

上面寫到的是一些簡單的場景，實際應用中，會有很多企業存在多級部門的情況，比如研發部下分為研發一部、研發二部，研發一部又分為產品部、技術部。

對于擁有相同功能權限的張三和李四，在數據權限上張三需要查看研發一部所有數據，而李四只能查看研發一部本級的數據。

所以后期我們可以在數據權限設置時增加對組織架構的設定的三種類型：

1. 只看本級
2. 可查看本級及下級
3. 指定某個級別（部門/機構）

2. 初始化角色（預制角色）

用戶權限設置完成后，我們還需要考慮新用戶的預制角色，我們不能讓用戶從零開始一點點配置，因為這樣不僅費時費力，大部分用戶也配不明白，即便平臺提供了培訓手冊或視頻，但是又有多少用戶會認真看呢？

所以不同的平臺對于新入駐的用戶，要預制一套相對常規的規則。當然不僅是預制角色，其他的業務功能也需要按需預制，畢竟降低用戶的理解難度和操作難度，也是提高入駐率的關鍵方式。

后續我也會單獨整理我們可以采用哪些方法降低B端用戶的上手難度和準入門檻，歡迎持續關注~

3. 有些功能需要單獨維護訪問權限

有些場景不太好通過平臺級的設計來解決，建議還是針對具體的場景進行特色化設計。

比如企業的合同管理功能，人事一部只能看到員工的勞務合同，人事二部只能看到員工的保密協議。這種按業務類型區分的數據分類，參照上文的設計模式就不好實現，所以只能在合同管理功能中單獨增加以類型區分的數據篩選條件。

05 需要強調的兩件事

1. 盡量不要把特色化改動直接掛到“用戶”上

即便遇到一些偶現的用戶權限特殊處理，也盡量采用對角色的新增和配置形成權限集合后，再賦予用戶，而不是在用戶上直接進行修改。

2. 在最終測試驗證環境，一定不要只使用【超級管理員】操作

因為超管一般不會出問題，我們需要使用新維護的角色，代入用戶的實際使用場景，對平臺的功能進行全流程冒煙測試，在這個過程中才能夠發現更多的隱藏問題。

以上就是今天對用戶權限的設計總結。

06 寫在最后

設計思路是一回事，具體的解決方案又是另一回事，希望今天的分享能夠為你帶來一些幫助。

權限設置在后續的工作中和實際場景連接后，會演變出非常多的可能性，所以需要我們結合自身團隊的訴求，產品的目標和現狀，和研發人員一起討論出更合理的設計方案。