系统权限的反思
一、系统权限设计现状
目前大部分的应用系统，包含销售管理系统在内，系统权限的设计方案均采用的是RBAC模型，所谓RBAC就是：用户、角色、系统功能，用户属于某些角色、角色拥有某些系统功能；虽说不同系统间，可能存在差异，但差异的地方更多的在于“系统功能”细化的程度，有的到页面级，有的到数据级，有的到操作按钮级，但本质是一样的。
示例如下图所示：
此权限设计模型，在销售系统建设初期，系统功能和使用人员规模都不大的情况下，此模式完全够用。
但随着销售业务不断迭代，系统功能和使用人员范围也在不断扩大，此时此刻就面临以下一些问题和场景：
1> 场景一：客户档案台账及客户下单历史，此功能无论是销售人员、财务人员、商务人员、产品运营人员、甚至审计人员都需要查看，这样的场景下，我们很自然的想设置一个“客户台账查询及下单历史查看”角色，这个角色同时拥有“客户台账查询”、“客户下单历史查询”功能，这样凡是需要查看的人员均指向这个角色即可。（这属于为【功能集合授权】）
【功能集合授权】方案：
优点：无论公司那些人需要这样的权限，加入这个角色就可以了；
缺点：当人员出现调动、离职等情况时，需要手动从此角色中移除；
2> 场景二：某天有位同事在OA上申请开通 客户档案查询、订单台账查询、申请单台账查询等权限，并且申请也已审批通过，我们很自然的分别在“客户档案查询”、“订单台账查询”、“申请单台账查询”角色中都加上这位同事。后来他们同部门同组的其它同事也纷纷申请开通这些权限。此时困难就出现了，若他们部门的每位同事均按上述相同方法处理也不是不可以，但总觉得别扭。因为这是很明显的，要根据岗位职责进行权限划分的。所以应对建立一个【XXX岗位】这样一个角色，凡是属于此岗位的人员，直接具备了相同的权限。（这属于【岗位集合授权】）
【岗位集合授权】方案：
优点：人员按岗位进行区分，很容易跟HR组织关联（【这样才有可能实现权限的自动化设定】），若人员调动，离开此岗位，权限自然就没有了。
缺点：若没有大规模组织结构调整，此方案在配置权限时，会轻松很多，也不太容易出错。但是一旦出错就是大范围的误。
上述两种场景，在销售管理系统运转到目前阶段，业务范围和使用人群在不断扩大，上述两种场景现在已开始同时出现。我们需要尝试重构销售系统的权限架构。
RBAC模式是基础，但我们可以尝试在此基础上改进适用我们自己的模式。
二、我们要解决的问题是什么？
1> 现在公司处于高速发展阶段，铁打的营盘流水的兵，所以公司人员调岗、流动很大，也很频繁，我们首先要解决的问题是如何让人员入职后，系统自动匹配权限，尽量减少运维人员干预？
2> 当人员职级上下浮动变化时，某些特殊业务权限，如何设定？例如产品政策支持，业务员提交后，需要大区经理审批，若此区组的区域经理是L6以上，则可代大区经理审批，否则由大区经理自己审批。职级的变动影响权限的设定。
3> 若再出现上述【功能集合授权】和【岗位集合授权】的业务场景时，如何处理？
4> 临时授权用户，如何处理？曾经出现过 OA系统给外部人员开通临时授权的情况，那么销售系统会不会也出现给某些人员开通临时查看权限呢？如果有，怎么支持？
三、我们可以尝试采用如下方案：
1.更多采用【岗位集合授权】：
a) 更多采用【岗位集合授权】的方式，系统权限划分尽量按照部门、岗位进行划分；
b) 将设定的岗位角色，与HR系统的组织结构进行自动关联，人员随着HR人员组织自动进行入、调、离；（根据业务设定岗位角色与组织结构自动关联的范围）
2、对非组织结构中的，特殊业务权限，进行规则设定和配置：
a) 将此类角色，标识为特殊角色，同时配置相应的规则，如是否满足L6，若是，则加入此角色。（即：【动态岗位集合授权】）
3、【功能集合授权】和【岗位集合授权】方案，可按照如下原则进行取舍：
a) 若是业务上需要设定权限，不同业务部门都需要同一个权限，我们还是尽量按照【岗位集合授权】来划分，这样应对将来变动性、自动性将会更强一些。只不过当下配置的角色可能会多一点。
b) 若是系统所需，例如“系统管理员”、“客户档案管理员”等，这样的角色就只能按照【功能集合授权】方式进行处理。
4、针对临时授权的问题，首先销售系统要在权限设置上具备此能力。
a) 临时授权需走审批流；（此时需要考虑外部人员，销售系统可内置几个查看账号，此账号的密码为动态密码）
b) 临时角色要临时授权期限，当期限到达后，此角色自动失效。
若按照这些方案执行的话，我们仍需考虑【岗位集合授权】的硬伤，如何避免大范围的权限错误。
