最近在构思对自家的社区电商平台进行重构,其中的大头就是权限系统,原有的权限体系已经不能满足需求了,所以根据客户状况及参考了其他一些大神的方案,对整个社区电商平台的权限系统进行了设计。 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. 总结 作为一个社区电商平台,这可能不是最完美的权限系统设计方式,但可能是比较适合我们当前需求的方案。如何设计一套权限系统应该由产品的业务特征决定,如果一个产品是完全自营的,就不会有代理商的概念;如果是传统的线下零售转线上,可能就要预设很多级的角色以满足原有的组织架构。 另外,一个权限系统也不是越复杂、颗粒度越高越好,有些权限系统将功能权限颗粒度细化到了每个接口,这样"看似完美"的设计,最大的优势其实是最容易实现。对于那些需要运营进行权限配置、甚至对外开放的系统而言,在实际操作过程中,由于业务是由接口组合实现的,就有了运营看不懂该怎么配置,或某几个业务是共用同一个接口。于是运营进行一些业务操作时没问题,但是进行另外一些业务操作时报错。 还有前文提到过的,一开始为何就不设计成多级甚至支持无限级的权限系统呢,毕竟研发也要成本,且用不上的层级可能也会带来操作者的疑惑、增加学习和操作成本。 只有根据自己产品的使用场景需要、考虑使用者的用户体验,才能设计出好的权限系统。