簡單來說，壹個用戶有幾個角色，每個角色有幾個功能權限。這樣就構建了“用戶-角色-權限”的授權模型。在這種模型中，用戶和角色之間以及角色和權限之間通常是多對多的關系。如下圖所示:
壹個後臺用戶角色權限系統總可以大致分為三個模塊:用戶管理、角色管理和權限管理。
角色權限系統屬於策略設計的範疇，它的設計考驗的是壹個PM對業務的理解和對其後臺所有功能的熟悉程度。在做角色權限系統之前，壹定要對業務流程和後臺的所有功能模塊有深入的了解。如果不了解，要向相關同事咨詢，避免角色權限體系設計出現錯誤和邏輯漏洞。
用戶管理中的用戶主要是功能系統的用戶。這些用戶是員工個人，而這些個人往往是從行政關系(部門結構)和業務部門(業務結構)兩個維度來劃分的。用戶管理就是這兩個維度的初始分組或員工分組。按行政部門或業務條線部門劃分，對應部門或群組內的用戶具有基本相似的系統功能使用需求和權限級別；
註:以上圖例顯示的是按管理關系劃分的用戶管理模式。
註:以上圖例顯示了按業務線關系劃分的用戶管理模式。
角色通常是系統根據業務管理需求預設的固定標簽。每個角色都對應明確的系統權限，其擁有的系統權限壹般不會隨意更改，角色也不會隨著用戶的增加或刪除而改變，比用戶管理更穩定。
如果角色與組織部門在行政關系下存在綁定關系，用戶進入組織部門後，會自動添加到相應的角色中，並擁有該角色的所有系統權限。
例如，財務人員小張加入財務部後，可以查看財務數據報表和相應的操作權限(如操作財務審批等。)部門員工無需額外授權即可在相應的財務報表系統中查看；
商業是不斷創新發展的。隨著業務的發展，會設置和創造越來越多的新角色。
比如公司新推出了壹個企業團餐項目，項目部從各個部門找了多名員工組成項目組，這個項目的業務權限只授權給這些員工查看和操作。那麽，在這個項目中，將創建壹個新的角色“財務1”，系統高級管理員將把從財務部門選取的財務小張添加到角色“財務1”中，這樣就可以查看到小張燦了。該權限的授予不能通過自動綁定用戶的管理關系來實現；
權限可以是唯壹的，也可以是繼承的。每個角色都有自己的權限集，角色繼承實際上就是繼承父角色的權限。壹般來說，壹個角色在繼承其父角色所有權限的基礎上，還擁有壹些自己的權限。系統角色繼承往往存在於對用戶分級管理清晰的團隊或公司中；
角色互斥的業務背景:當壹個業務流程由於風險控制需要分成幾個步驟時，需要為這些不同的步驟授權不同的角色，這些角色需要互斥。
比如，在大額財務報銷的審批流程中，財務人員小張擁有審批人權限後，不能授予小張審核確認的權限，避免壹人完成大額報銷帶來的財務風險；
臨時角色通常是為特殊群體設置的。比如公司有專門的拜訪團隊，就要給這些特殊的客戶壹些臨時的身份去體驗某些功能。那麽把這些人加入到部門的組織架構中顯然是不合適的，因為這些人只是臨時安置者，而不是企業員工；
其次，這些客戶需要體驗的功能操作往往跨越多個業務模塊和產品線(更復雜)。壹般公司沒有現成的固定角色滿足客戶要求的所有操作權限，所以需要為這些客戶設置臨時角色，並支持給予臨時角色最大限度的權限選擇；
顧名思義，黑名單不能有任何權限，白名單可以有相應的權限。這個需要根據業務需求專門設置。
權限管理從三個不同的粒度層次考慮:功能菜單、功能操作和數據參數。具體粒度取決於公司架構和團隊規模。如果業務屬性不壹定要求將權限控制到非常精細的級別，那麽就沒有必要將權限的粒度拆分到壹個具體的操作或者壹個按鈕。畢竟後臺產品的核心是業務管理平臺，主要目標是輔助業務的管理和推廣。
註:圖為某後臺產品的部分截圖，可以看到功能菜單頁面、功能操作按鈕和數據字段。
對於後臺產品來說，劃分用戶對功能菜單的權限，實際上是壹種粗粒度的管理方式。在這種模式下，用戶壹旦被授權，就可以使用菜單欄下的所有數據查看權限和功能操作權限。
功能操作層的權限比功能菜單的權限更深。在這種情況下，不同角色的用戶可以進入同壹個菜單頁面，在後臺查看相同的數據字段信息，但是可以進行不同的功能操作。
數據字段級是細粒度的拆分，會實現不同角色的用戶進入同壹個菜單頁面背景時，可見的數據字段是不壹樣的。比如銷售人員進入銷售績效管理後臺，可以看到自己的績效提升數據，但是財務人員看到的是業務工單的費用字段。這些字段* * *存在於菜單頁面中，只是受到不同角色和權限的限制。
數據是指系統中某類只有權限才能操作的數據，比如客戶數據，但是不同渠道的客戶需要進行劃分，分配給不同的管理者進行管理。例如，壹個員工有編輯客戶數據的權限，但是沒有權限就不能操作對應的已編輯的客戶數據。
以壹個從無權限限制到訪問用戶角色權限管理系統的推廣活動的背景為例。詳情如下:
註:以上是某產品的推廣管理後臺截圖。
在推廣活動後臺接入權限系統之前，幾乎所有的系統權限都是裸奔，所有業務線成員都可以查看後臺運營活動和運營結果數據，可以進行相對敏感的操作。這種情況顯然存在壹定的管理風險，因此後臺系統需要對權限管理系統進行系統的管理和控制；
在訪問權限管理系統的過程中，需要對功能模塊的權限元素進行分解(分解到壹定的粒度)，因此需要根據業務特點判斷需要分解的粒度是在功能菜單、功能操作還是數據字段級別，只有在粒度劃分清楚後，權限管理系統才能根據粒度對不同的角色授予權限；
促銷活動接入權限管理系統後，對應角色的用戶再次登錄後臺時，首先後臺會檢查用戶的角色是否具有功能模塊的權限，以及角色權限對應的操作權限和數據字段權限，檢查結果經過服務器處理後顯示給產品端的用戶。此時，同壹用戶在後臺可見的、可執行的操作，可能與訪問權限管理系統之前有很大的不同，這就是權限管理系統基於用戶角色帶來的變化。
1.壹個用戶有多個角色。多個角色之間存在互斥關系怎麽辦？
如果某個用戶已經被添加到某個角色範圍，那麽在給當前角色添加有獨占權限的角色時，系統會判斷互斥，後續角色將無法成功添加該用戶；
2.在業務發展過程中，如何保證不同角色之間的權限劃分清晰？
隨著業務的快速發展，會增加不同的角色和更多的功能模塊，這些角色和功能權限的關系會越來越混亂。此時，產品經理和業務方需要及時面對業務的發展變化，及時梳理業務調整的範圍並做出相應的改變；
3.用戶權限管理系統的核心難點是早期的產品設計嗎？
用戶權限管理系統最難的不是前期的產品設計，而是後續的運維，因為權限體系的結構往往不會隨意變化。然而，隨著業務的快速發展，角色和功能模塊出現了。為了防止角色和功能權限之間的關系變得混亂，在建立新的角色和分配權限時，需要進行清晰和仔細的調整。
下午好~今天是2020年倒數第二天~朋友們打算怎麽過除夕？今天很多城市下雪，請註意保暖。
我在這裏如約和大家分享數學AI思維課的各種分析文章。
我的兩個孩子數學基礎很好，我二年級的弟弟也在同時學習美國奧數。作為壹個“過去的人”和壹個教育工作者，今天分享的6款app都是我印象比較好的產品，各有特色。
我認同的是，好的AI類產品整體