需求10——故障上报流程

在浏览我之前完成的一些小需求时，我发现了一个非常有价值的需求。这个需求可以让我深入了解系统中关于故障上报的功能。通过完善这个需求，我能够全面掌握整个故障上报的流程。

这个需求主要是关于故障上报流程中出现的问题。当前的流程如下：

1. 员工A上报故障。
2. 维修工进行处理。
3. 按理说，处理完毕后应该由员工A进行验收，但因为员工A没空，所以转交给了员工B。
4. 员工B进行验收，但验收不通过，于是重新发起故障上报。

问题出现在重新发起故障上报的环节：

• 当员工B重新发起故障上报时，系统界面上显示的上报人仍然是员工A，而不是员工B。
• 同样地，故障处理完成后，界面上显示的待验收人也依然是员工A，而不是员工B。

我们希望在这种情况下，能够将第二张故障单的上报人和待验收人都改为员工B，而不是继续显示员工A。

具体来说，当员工B点击“验收不通过”时，第一张故障单已经结束。而当员工B重新发起故障上报时，实际上已经生成了一张新的故障单。

现在的问题是，第一张故障单的处理流程没有问题，但在第二张故障单中，上报人和待验收人仍然显示为员工A。我们希望修改系统，使得在第二张故障单中，上报人和待验收人都显示为员工B。

之后我登录甘有博的账号：

当点击验收不通过的时候，第一张故障单就已经结束了。

当点击“提交”后，第二张故障单就已经完成了。

现在我已经大致了解了整个故障上报的流程，并且明确了问题所在。我们的目标很明确：将第二张故障单的上报人和待验收人改为员工B（甘有博）。

在实际操作中，我发现点击“验收不通过”时，系统并没有立即出现问题，只是新开了一张故障单。然而，当我进行到“提交”这一步时，问题就出现了：

为了找到这个问题的根源，我们需要找到相关的接口，然后进入这个接口看看接口的内部逻辑是什么样的。

还有一种方法找到这个接口，就是你去看前端代码中关于“提交”按钮的事件处理函数，看看点击“提交”按钮的时候，事件处理函数调用了哪个接口。我演示一下：

这个接口已经被成功找到了。进入这个接口的后端：

在查看代码的过程中，我发现 controller 层没有什么问题，所以我继续深入查看 service 层的代码逻辑。通过对 service 层的分析，我们可以进一步定位问题并找到解决方案。

在 service 层，我找到了这样一行代码：

这是将 form 对象转换成 entity 对象的代码。具体的转换思路如下：

1. 属性复制：在转换的过程中，portalForm2Entity 方法会将 form 对象中的属性值复制到 entity 对象中。如果 entity 对象有的属性在 form 对象中不存在，那么这些属性在 entity 中保持默认值（通常是 null）。
2. 后续处理：在转换之后，代码中可能会对 entity 对象的某些属性进一步赋值和处理。如果某些属性没有被进一步处理，这些属性就一直保持 null，并且在保存到数据库时以 null 的形式存储。

了解了 service 层的代码后，我开始思考：这里有没有对上报人的值进行后续处理呢？结果发现，还真没有。代码中只是让待验收人等于上报人，但并没有明确表明上报人是谁。

因此，为了解决这个问题，我们需要在 service 层添加一些逻辑，将上报人设置为当前用户。具体操作如下：

通过上述修改，我们确保每次创建故障单时，上报人都会被设置为当前用户，从而避免了上报人属性是第一张故障单的上报人的问题。

总结

在当前系统中，创建故障单时，上报人属性没有被正确设置，导致上报人属性总是等于第一张故障单的上报人。

为了解决这个问题，我们需要在 service 层添加逻辑，将上报人明确设置为当前用户，以确保每次创建故障单时，上报人属性都是当前用户。

具体的步骤就是，在将 form 对象转换为 entity 对象之后，设置 entity 对象的上报人属性为当前用户。

通过上述修改，每次创建故障单时，上报人都会被设置为当前用户，从而避免了上报人属性是第一张故障单的上报人的问题。