网站内容管理系统后台 设计( 权限系统设计的需求背景和需求)

　　网站内容管理系统后台 设计(

权限系统设计的需求背景和需求)

　　Toogee：权限设计通常隐藏在后台系统的深处，让大家都知道，但是面对复杂的业务需求和逻辑关系，就有点视而不见了。

　　这个文章是我之前权限设计的回顾。希望在自己整理的同时，也能给其他朋友带来一些想法。

　　一、权限系统设计的需求背景

　　1. 复杂的业务流程

　　随着业务越来越复杂，以前一个订单只需要一个销售跟进，现在需要五个销售才能完成一个订单的流程（每个销售负责其中一个流程）。

　　此时，我们可以使用授权系统给五位销售人员分别处理各自流程的权限（例如销售人员A只有输入意向订单的权限，销售人员B只有补充客户信息的权限等） ，让每个销售只能查看到传递给自己的信息，简化了繁琐的过程。

　　2. 敏感信息

　　当同级有多个部门时，同一公司内部就会出现竞争。比如销售组1努力挖掘的用户数据，不想让销售组2看到。

　　权限系统可以设置不同部门的数据相互独立，即使是组长也看不到对方的数据。

　　3. 安全运行，权责明确

　　在大型系统中，误操作的后果可能非常严重。

　　权限系统的存在最大程度上避免了此类问题。只要该功能出现在界面上，就可以操作，也不会产生严重后果。

　　4. 页面简洁

　　如果系统不进行权限管理，每个账号登录后看到的界面都是一样的，充斥着各种无关和冗余的信息，甚至需要专门培训，学习成本巨大。

　　通过权限系统的管理，每个账号登录后只能看到与自己相关的信息，可以更快的了解其工作范围内的业务。

　　二、权限体系基本结构

　　权限体系主要由三个要素组成：账号、角色、权限。

　　账号是登录系统的唯一标识，账号代表一个用户。自行注册或由系统管理员统一指派。

　　角色，批量给账号分配权限。在一个系统中，不可能为每个账户自定义权限，所以给同类型的账户分配一个“角色”，以达到批量分配权限的目的。

　　权限分为操作权限、页面权限和数据权限。

　　操作权限是指用户可以进行的操作，如是否添加、删除、编辑等。页面权限是指可以看到的页面。数据权限是指可以查看的数据范围。

　　一个简单的例子如下：

　　△ 权限系统基本结构

　　三、权限系统设计实例

　　1. 示例背景

　　这是一个订单管理系统，销售、客服等角色通过系统完成整个订单流程。

　　系统用户量大，层次复杂，大量销售团队在同一层次上相互竞争。

　　2. 账户管理

　　△ 账户管理

　　目前的情况下创建账户的流程是：管理员在系统中添加一个账户，用户通过自己的邮箱激活。默认角色为“员工”，只分配最基本的权限。

　　为了减少管理员的工作量，同时也支持通过excel上传，可以根据模板对excel格式进行标准化。

　　3. 角色管理

　　当前案例中的角色是“post”，不同“post”的用户拥有不同的权限。

　　角色管理的条目在“授权管理”页面上。它只有添加角色、编辑角色、删除角色和添加角色描述的基本功能。

　　通常主流的后端系统也有复制角色等功能。复制角色是指：创建新角色时，先选择一个已有的权限相似的角色，然后修改新角色的权限。这样就避免了权限过多时每个新角色都必须重新设置的繁琐情况。

　　4. 权限管理

　　在实际设计中，很多系统会选择将页面权限和操作权限合并为功能权限，比如目前的案例：

　　△ 功能权限

　　每个页面都有一个主开关，打开意味着页面权限被分配。对于页面中的所有字段，主要有添加、删除、查看和修改四种操作权限。如果您需要为页面中的某些敏感字段设置单独的操作权限，您可以打开高级设置来配置字段级操作权限。如下所示：

　　△ 功能权限的高级设置

　　在目前的情况下，当有多个团队同级别竞争时，仅靠位置是无法满足数据权限分配的需求的。因此，我们引入了“部门”，以确保同一级别销售团队中彼此的信息是保密和公平的。竞争。

　　此外，上级部门，比如城市经理甚至总经理，应该有权看到他们所负责的部门和下级部门的所有数据。

　　因此，将“部门”的权限组划分为级别，并根据级别进一步分配数据权限。比如基层销售只能看到自己的数据，销售组长可以看到这个部门的数据，总经理可以看到这个部门及其下属部门的数据，总经理可以看到所有的数据。

　　我们把部门的划分放在公司设置页面，作为公司组织架构的介绍。

　　写在最后

　　权限系统的基本结构是这样的，但是实际的权限设计有很大的不同。

　　清楚地理解基本概念，并根据实际需要设计独特且恰到好处的权限系统。也可以参考一些主流后台系统的权限设计，了解其他系统是如何解决类似问题的。

　　小提示：与其孜孜不倦地注册和试用各种后端系统，不如直接去官网找帮助文件。

　　欢迎交流后端系统相关的设计思路。

　　《后台设计好文章推荐》