戏说权限：（一）权限基本概念

话说这个权限系列文章，拖了有一年多了吧。一直想写，就是人太懒[皱眉]。今天趁着大半夜的美好时光，先开下头。

要说明的一点，这篇文章是给产品看的，主要梳理权限架构中的逻辑和思路，不涉及代码层面内容。另外会有一个较为完整的权限方案会在文章中，逐步拆解给大家。文末也会给大家提供相关的原型文件，供大家下载参考学习。（这方案也是在工作中产出的一部分，只是我司一直未使用，搁置有快一年多了吧，所以，不会有侵权问题，请放心参考。）

事前声明，本文中的所有逻辑参考了网络上一些权限文章（虽然我觉得大多数写得很一般），另外关于数据权限部分，核心参考了销售易的数据权限处理思路。甚至产品原型界面也会有几分相似。
（销售易的大佬应该不会对我这种小人物投诉维权的吧。嗯，应该不会，知识是应该分享的。）

好了，废话已经说了很多了，进入正题。

1.权限到底是什么？

既然要做权限体系架构，至少得了解权限是什么吧。

权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。——【百度百科】

看懂了么，我知道你没看懂，百度百科没说人话。

权限的本质就是为了满足人与人之间不同的管理需求而产生的。准确的说，是界定人与系统功能之间的关系。

还没看懂？

举个大家都懂的栗子，你在淘宝买完东西后，卖家会操作一个“发货”的功能。那么这个发货的功能，只有库管员可以做，对于卖家的客服，是没有权利去做这件事情的。那么，在这时，就需要有权限的管理。以界定“发货”这个功能属于库管员，而不是属于客服。（除非你给客服也分配了“发货”功能）

2.权限具体分为哪些种？

权限既然是界定人与系统功能直接关系。那么这里面有人，也会有系统功能，我们依照这个维度来人。

对于人来说，每个公司都有自己的组织架构。所以，人的管理要依托于组织架构。（什么？你不知道什么是组织架构？你家老大叫CEO对吧，你们部门叫产品部是吧，有个产品总监吧，手下有小弟吧，一层一层的管理结构，就是公司的组织架构）

对于系统功能而言，需要分为功能权限和数据权限。（你又不理解了吧。。。）

功能权限：主要控制系统的功能，比如修改、删除。你能不能删除这个信息，全看你有没有这个权限了。比如，你是否能微博删帖。。。

数据权限：主要控制系统可查看数据的范围。比如说公司的销售A组，负责的城市是北京，那么A组的成员就只能看到北京的数据，B组的成员负责的是上海，那么B组的成员只能看到上海的数据。

3.本系列要讲解的顺序

绝大多数小的公司或者小的业务，其实纯粹的功能权限就能满足需求。所以，我们会优先讲解功能权限。（你百度能搜到的最多的RBAC权限管理，也会在这节讲解，期不期待？惊不惊喜？）

再次，涉及到较为复杂的管理系统时，特别是管理层级较多，且对数据安全性有较高要求时，会需要涉及数据权限。所以，我们第二节会讲解数据权限。

组织架构，这就完全是大公司更多回去玩的了。将组织架构与权限架构完全关联起来。这样就能满足从上到下，一层一层的不同权限的管理和设置了。

4.权限架构的一些小提醒

首先呢，权限体系属于整个系统架构中的基础部分，所以，能早做就别晚做。因为当系统整体搭建起来用之后，你再去搞权限，你会发现，困难程度和周期会上升不止一个层次。因为你改动的会是最底层的东西。

关于权限，如果公司不大，不要考虑太多，功能权限足以满足，不要好高骛远。如果必须区分数据权限，若有资源，则搭建一个数据权限管理体系，若资源不足或时间紧张，数据权限写死在系统也能接受。（绝大多数系统都是这么干的，所以，不用有什么压力）

关于组织架构，理论上来讲，有没有其实没什么太大影响。就是对成员统一管理（权限和资料）会变得非常方便，如果没有组织架构，你就得一个人一个人去改，略麻烦。所以，组织架构也是一个可考量的东西。如果你公司人很多，那你必须要考虑。如果你公司就没几个人，那就不需要了。

权限体系随着业务的发展，肯定也会有不同的变化。但是，只要基础架构搭好，变化都会在可控范围内。

ok~ 休息了，下篇讲解功能权限相关。安_{（我类个去，居然一点了，睡觉睡觉}）