网站内容管理系统后台 设计(入坑广告产品经理：一个角色管理+角色的权限管理)

　　网站内容管理系统后台 设计(入坑广告产品经理：一个角色管理+角色的权限管理)

　　上一篇文章《进坑广告产品经理》强调了权限设计的重要性。刚遇到朋友问了相关问题，今天写一篇文章来聊一聊~

　　一、RBAC 权限设计模型（即文章的封面图）

　　RBAC（Role-Based Access Control），中文是基于角色的访问控制，是目前最广为接受的权限模型。在 RBAC 中，权限与角色相关联，权限与用户无关。用户通过成为角色的成员来获得角色对应的权限。因此，如果一个用户有多个角色，他就拥有多个角色的功能权限。

　　偷偷从网上找了一张模型图：

　　二、如何设计产品

　　了解RBAC后，很多人认为一个后端用户权限系统大致可以分为三个模块：用户管理、角色管理、权限管理，对吧？

　　然而，现实往往并没有那么简单。用户管理与公司的行政部门或业务线密切相关，相应部门或业务组的用户具有非常相似的基本功能需求和权限。所以这里我建议再增加一个模块：部门管理，作为一组用户管理。

　　好的，文章 重点来了。一个后台权限系统应该有四个模块：部门管理、用户管理、角色管理和权限管理。为了让用户更好的理解角色和权限，在实际的产品设计中（角色管理和角色授予权限相结合），使用流程如下：（以下内容会按照流程一步步讲解）

　　1.部门管理

　　顾名思义，就是用户在后端所在的部门，可以按照行政关系（部门结构）和业务部门（业务关系）进行划分和设计。因为用户的信息会携带部门的信息，所以同一部门或同一业务的用户可以被赋予相同的角色来获取权限。

　　产品设计如下：

　　部门管理-产品设计

　　在部门管理中，可以清楚地看到各个部门或业务之间的关系，也很容易规划不同部门之间的数据权限。

　　2.角色管理+角色权限管理

　　在整个部门结构中，每个部门的作用是什么？同一部门是否有多个角色？因此，需要进行角色管理（添加、编辑、删除角色）来管理各个部门的角色以及角色的数据权限范围。例如：在运营部门，有运营总监（可以查看整个部门负责人的数据）、运营组长（可以查看运营组A的所有数据）、运营专员（可以查看）查看*敏*感*词*）。那么一个运营部门至少有三个角色：运营总监、运营团队领导和运营专家。这三个角色也对应着三种不同的权限。

　　角色是根据业务管理需求添加的固定标签。每个角色对应明确的系统权限。一般不会随意更改其拥有的系统权限，也不会随着用户的添加和删除而更改角色。变化，稳定性强于用户管理。

　　通过“关联权限”为角色赋能，即角色权限管理。

　　产品设计如下：

　　添加角色产品设计

　　角色赋能相关权限

　　3.用户管理

　　部门设置好了，角色和权限也设置好了，那么用户就要加上角色名，才能获得相应的权限。

　　因此，通过“添加用户”和“编辑用户”赋予用户登录、部门和角色权限。

　　这个操作非常顺利。部门-角色-权限-用户拥有他们应该拥有的一切。可以创建、编辑和删除它们。一切都可以免费查看，但是！是的！权限的个人管理没了？回过头来看，角色赋能-管理权限接口，如果取消“行业”功能怎么办？我能做什么？这时候就需要对权限进行管理，于是就有了一个看起来像电脑的权限管理模块。

　　4.权限管理

　　用于功能权限管理。这里的权限可以理解为平台中是否存在该功能，以及该功能是否区分数据范围。

　　产品设计如下：

　　权限管理模块专业度高，只适合给超级管理员展示。总经理只需具备三个模块：“用户管理”、“部门管理”、“角色管理”。

　　如果页面固定，功能固定在平台，权限管理甚至可能不存在。

　　好吧，罗里说完。至于我懂不懂，我就无视了，哈哈哈！

　　至于角色权限继承、角色互斥、临时角色、黑白名单等产品设计问题，在这个权限体系中是不存在的。下次有机会再讲讲这方面的产品设计~欢迎有相关设计的同学交流产品。

　　请勿盗图，不接受复制粘贴转载本文内容。