需求类

背景

由于拓展系统设计的问题,在设计数据权限时并未考虑到组织架构变动时对单据归属权产生的影响,如:A部门的员工小王,调到B部门后,小王的单据是归属于小王还是归属于A部门

处理方式

经过与业务和产品的讨论,需要将单据移交到新的部门


处理方式

思考
主数据旧部门禁用后是否还是继续给下游返回?
关于数据权限的设计
1、挂在部门下
2、挂在人员上
参考
https://www.cnblogs.com/jpfss/p/8352031.html
https://www.cnblogs.com/jpfss/p/11045258.html :::

:::danger 通过模拟场景从而找出问题所在
排查问题步骤:
1、复现,通过复现bug总结规律
一开始方向从暂存入手,怀疑暂存数据有问题
尝试几种场景后偶现,开始转移方向
偶然发现产品类型没有勾选,查数据库发现type保存为-1,怀疑是否暂存为-1这个值有问题,并且进行尝试不勾选添加bom后发布,果然没有保存bom
开始抓包,确定-1值何时出现,发现为第一次暂存后出现,翻代码,查到代码写的有问题,绕过校验,继续查看为何出现-1,第一种情况,代码初始赋值,大概看了一眼感觉不太可能,查看数据库表结构,发现设置了默认-1,再次查看代码确认-1不走保存bom的逻辑 ::: :::info 背景:
现象:
bug分析及定位 - 图1

猜想

  1. 操作有误
  2. 代码问题

验证

  1. 数据库

bug分析及定位 - 图2
bug分析及定位 - 图3

  1. 可能的问题原因

基于需求,不同岗位负责的门店不冲突
定位

  1. 入口

bug分析及定位 - 图4

  1. 方法

bug分析及定位 - 图5

  1. 代码行

bug分析及定位 - 图6
bug分析及定位 - 图7
bug分析及定位 - 图8
bug分析及定位 - 图9
bug分析及定位 - 图10
bug分析及定位 - 图11
bug分析及定位 - 图12
bug分析及定位 - 图13
bug分析及定位 - 图14
bug分析及定位 - 图15
bug分析及定位 - 图16
bug分析及定位 - 图17
bug分析及定位 - 图18
bug分析及定位 - 图19
bug分析及定位 - 图20
bug分析及定位 - 图21
bug分析及定位 - 图22
bug分析及定位 - 图23
bug分析及定位 - 图24 :::