背景
在电商庞大的后台系统中，商品、订单、仓储是最核心的3个部分，其中商品又是重中之中；商羚商品模块，作为商羚商户端核心模块，业务、交互极其复杂；尤其商品发布，面对不同的商家用户，不同的业务场景，不同的商品来源，所拥有的操作权限不同，即使同一个商家用户，对不同的商品，可能会存在不同的操作权限；如何设计商品发布页面，做到快速开发迭代，可扩展性强，对于前端开发是一个不小的挑战。
现状
由于一期做商羚商品的时候，未考虑后期业务的扩展，当时的设计相对比较简单，按照现有业务快速实现功能。对于商品发布页面来说，此时的业务场景只有2中，创建和编辑，但其实可以统称编辑，此时没有任何权限，任何商家用户进入发布商品页面，对任何信息都有编辑操作权限；所有，当初设计只是把发品页面按功能进行楼层划分，分别为基本信息楼层、规格参数楼层、商品详情楼层、售后信息楼层；
京东智采商品：随着业务的发展，商羚商品需要接入VOP商品池，简单理解就是商家想卖VOP商品，把商品VOP商品池采集到商羚商品池，商品上会进行一个打标，标识是VOP商品，商家进入编辑页面编辑VOP商品时，有一些信息是不能编辑，有部分信息可以编辑；此时其实已经开始有了权限控制的概念引入，即商品来源。此时在做开发的时候，代码层面，只是通过点单的if判断来区别，每个楼层都写了一些if判断来进行逻辑及展现层面的区分隔离；
开普勒商品：业务引入开普勒商品，同VOP商品一样，商家可以把开普勒商品池的商品采集到商羚商品池，同样会在商品维度打上开普勒标识，商家也同样拥有一些权限的控制；当前权限控制仍然为商品来源，采用了VOP的解决方案，就完成上线了；直到此时，商品发品页面的权限控制复杂读尚可进行维护，未出现点什么问题；
KA商家：随着业务的不断壮大，商羚业务有了新的业务方向，即KA客户；针对KA客户，商羚需要做一些个性化的需求，举一个简单的例子，如物流教育客户，在商品发品页面，对于支付方式的诉求是不一样的，标准版商家是默认不选择货到付款，而物流教育则需要默认勾选货到付款；对于标准版商羚、KA客户使用的商羚，对于前端来说，是同一套代码，并且是同一个部署环境，那又应该如何实现个性化的功能；到此，出现了权限控制的另一个类型，即商家维度；
一商多店：商家可以开通总店、分店，登录总店、分店的用户有不同的权限，此时权限控制也属于商家维度；
现有功能权限梳理
整体页面功能如下：
1、从现有功能模块维度进行总结，可以划分为店铺来源、商品来源、个性配置3大类：
2、从页面功能分析，页面权限包括：隐藏、显示、可编辑、不可编辑、只读等权限，最终可总结为：hide、editable、disabled、readonly等字段；
3、最终分析整个功能页面，可以看到权限控制如下：
实现
发布商品页面分为四个模块：基本信息楼层、商品规格楼层、商品详情楼层、售后楼层，在此基础上，统一增加权限楼层，对各模块进行权限控制，大致框架如下：
本次主要增加了权限楼层的控制，对页面的各模块进行控制，如果有新需求进来，尽量做到只修改权限楼层的代码即可快速实现功能；
示例：基本信息楼层
对每一个功能楼层都有一个标准版的权限，如图1；其中basicFloor.statusMsg 定义当前整个基本信息楼层的权限，productName、video等字段定义其中每一个功能项的权限，他们优先级 字段 > 楼层；增加 basicFloor.statusMsg 字段的目的，可以统一设置整个楼层的权限，例如当整个楼层不可编辑的时候，则只需要配置 basicFloor.statusMsg = 'disabled'，即可完成配置。
当具体进入商品编辑页面时，每个模块会自动调用权限控制的函数，如图2；入参为店铺类型、商品类型，里面根据入参及KA配置，决定当前楼层的编辑权限；
至此权限控制已经完成，每个楼层根据权限显示对应功能，以后新需求进来，只需要配置相应的权限即可完成；
后记
本次权限控制在店铺来源、商品来源及一些个性化的配置来实现，针对商羚特定业务的来考虑，方案不一定完美，后续会持续进行完善。
