最近在构思对自家的社区电商平台进行重构，其中的大头就是权限系统，原有的权限体系已经不能满足需求了，所以根据客户状况及参考了其他一些大神的方案，对整个社区电商平台的权限系统进行了设计。
1. 用户群划分和业务介绍
用户划分
我们是做社区电商的，普通C端用户就是最终端的消费者。分销客是由C端用户“申请”成为，定位是社区或街道的“团长”，当所有用户（包括平台用户与分销客）通过分销客的链接完成交易时，分销客就能获得对应的提成。
商家是商品的提供商，负责上传SKU、处理订单发货、售后等。我们平台主要面向社区，上面的商品不完全是实体的商品，也有很多家政、洗车等服务。
代理商是一个特殊的角色，例如大区代理、省份代理、城市代理。他们帮平台完成很多地区的落地、招商、运营工作，某种程度上他们也是平台的用户，不过只能看到其对应有权限的区域的商家商品、订单信息。
商品客与商家、平台、代理商的关系
当一个用户希望成为分销客时，我们平台是需要用户申请的，如果当地有代理商，则申请会流转给代理商，由代理商根据用户周边情况决定。如果当地没有代理商，则由平台进行审核。而一个商品是否支持分销，由商家和平台/代理商共同决定。分销的模式为分销客可以开设自己的店铺，然后将不同商家的商品添加到自己店铺中，再分享给他人促成购买。
当然，我们也在尝试一些全民分销的活动，尤其是在没有代理商代理的地区，让普通用户都可以尝试将自己看好的商品分享给其他人，一旦促成购买，也有一定的奖励金。
2. 客户端划分
C端：用户和分销商操作，主要载体是微信小程序、公众号H5、我们的APP，支持注册登录下单支付等功能。
B端：由商家及其员工操作，一个商家完成注册后，可以设置多个员工账号，拥有不同的权限，进行上传SKU、订单发货、售后服务、财务结算、优惠促销等操作。主要载体和电脑端网页和手机H5网页，其中手机H5网页的功能是简化后的，有些功能只能在电脑端操作。
平台端：以电脑端网页为主，并尝试兼容在手机上查看数据。用户为平台运营和代理商们。
代理层级我们就设置了两级，之前其实我们就有一级代理商角色，现在是再增加了一级代理商。可能有的朋友会问，那为什么不一步到位：洲际、国家、区域、省份、城市、区/县、镇/街道这样分呢。主要原因就是我们体量有限、代理商并不多，过于复杂且灵活的体系，担心一来会加重研发周期，二来会干扰运营的操作体验，所以最后就选择了省-市两级的代理。
3. 权限划分
权限划分是整个权限体系设计的最大困难点，我们把权限分为了3种：
权限类型
（1）功能权限
可以访问哪些板块、操作哪些按钮。
功能权限划分
（2）数据权限
数据权限继承
数据权限即该用户可以访问哪些数据，例如一个用户可以访问商家管理板块，同时他可以访问广东地区商家的数据，那么综合在一起，他就能在商家管理板块看到广东地区商家的数据了。
重要的数据包括：
商家资料；
商家订单；
分销订单，比商家订单多出了分销者信息；
商品信息；
用户资料；
分销者资料，在用户资料基础上增加了一些实名信息、业绩、余额等内容；
商家员工资料；
代理商资料。
其他常见的数据，但是我没有体现在流程图中的：
商家优惠券；
平台/代理商优惠券；
活动及报名信息；
广告信息；
用户行为数据（登录、驻留时间、访问页面等）。
我们的代理商、分销客都可以拉新，所以当游客通过不同的链接注册后，我们会给予分销客一定的奖励，对于代理商则有一定的手续费返现。分销客和代理商能查看到其拉新用户的“资料摘要”，即简化后的资料信息，我们并不会将一些敏感信息任由他们查看。
查看用户资料的数据权限
平台和代理商都可以招收分销客、商家，分销客和商家的数据权限秉承三个原则：
谁招收谁有权查看；
上级有权查看；
商家、分销客的数据权限
（3）角色权限
用户的权限由其所属的角色决定，一个用户可以关联多个角色。
平台的代理商及角色关系
如果一共用户的角色是省级代理商，则可以访问该代理商及其下属市集代理商的所有数据。但是市级代理商只能访问自己的数据，无法访问到其关联的省级代理商的数据。代理商如果是平级或不平级、但是无关联，数据也不互通。
在实际应用中可能会出现以下特殊场景：
原本一个市级代理商，现在要承包整个省的代理，如何处理？
如果这个市级代理是单独存在的，我们提供了升级功能，这样他下面就能挂载其他市级代理商了。如果这个市级代理原本属于某个省级代理，那我们应该先解绑，然后再升级。
如果一个大区被承包了如何处理？
我们现在并没有这种场景，虽然不排除以后会有。我们现在遇到的场景是我们将不同的片区的代理商，分给不同的运营和商务处理，这样我们就为他们的账号绑定了多个角色权限，这样他们就能查看这个大区所有代理商的数据了。如果以后有华南区、华中区代理商的需求，我们再增加对应层级。
代理商如果自己有更细的层级划分如何处理？
我们提供接口权限级别的ERP对接业务，代理商可以将自己的ERP与我们系统对接，打通订单、商品、优惠券、商家及用户资料等数据，由代理商的ERP系统对下级权限进行细分。
4. 平台用户字段
平台的用户字段
这里以最复杂的平台端的用户来讲解一下用户、功能、数据、角色的关系，关于商家的员工字段将不再赘述。首先，超级管理员是系统自带的，不能创建和修改权限，第一批用户都由超级管理员创建，我们称为“普通管理员账号”，生产工作中都是使用此类账号。
（1）用户基本资料
登录的账号密码、姓名、身份证号、联系方式等信息。
账号密码、姓名、手机必填，姓名和手机可以帮助对应账号自行修改、找回密码。
（2）功能权限
我们预设了一些功能角色，这样不需要每创建一个用户都要勾选一遍功能列表，这是一个很繁琐的事情，同时我们也提供了功能角色的编辑板块，让平台管理员可以根据实际情况新增一些预设角色。
对于代理商来说，预设的角色若是不满足他们的需求，可以自定义他们的员工及合伙人可以使用的功能。代理商看到的功能列表里，只有当前用户所有的功能，只能从中进行筛选，无法查看、无法勾选其没有的权限的功能。
（3）数据权限与角色
我们并没有单独出一个版块来设置订单数据、商品数据之类的访问权限，而是直接选择该用户的角色，是平台还是某个或某几个代理商。因为只要限定了可访问的板块、用户所属角色，例如可以访问商品管理板块且你是一个地区代理，则你可以查看本地区所有的订单数据。
没有必要做成你可以访问订单管理板块、你需要拥有订单数据权限、你是地区代理身份，这样设置三次的方法来确定权限。
数据权限说明
一个用户若有创建用户的功能权限，则可以创建角色小于等于自己所属角色的用户。例如平台角色用户可以创建更多的平台角色用户，也可以创建省级、市级代理用户。一个省级代理可以为自己及其市级代理创建用户，但是无法为其他省级代理、市级代理、平台角色创建用户。
5. 总结
作为一个社区电商平台，这可能不是最完美的权限系统设计方式，但可能是比较适合我们当前需求的方案。如何设计一套权限系统应该由产品的业务特征决定，如果一个产品是完全自营的，就不会有代理商的概念；如果是传统的线下零售转线上，可能就要预设很多级的角色以满足原有的组织架构。
另外，一个权限系统也不是越复杂、颗粒度越高越好，有些权限系统将功能权限颗粒度细化到了每个接口，这样“看似完美”的设计，最大的优势其实是最容易实现。对于那些需要运营进行权限配置、甚至对外开放的系统而言，在实际操作过程中，由于业务是由接口组合实现的，就有了运营看不懂该怎么配置，或某几个业务是共用同一个接口。于是运营进行一些业务操作时没问题，但是进行另外一些业务操作时报错。
还有前文提到过的，一开始为何就不设计成多级甚至支持无限级的权限系统呢，毕竟研发也要成本，且用不上的层级可能也会带来操作者的疑惑、增加学习和操作成本。
只有根据自己产品的使用场景需要、考虑使用者的用户体验，才能设计出好的权限系统。
