在浏览我之前完成的一些小需求时，我发现了一个非常有价值的需求。这个需求可以让我深入了解系统中关于故障上报的功能。通过完善这个需求，我能够全面掌握整个故障上报的流程。
这个需求主要是关于故障上报流程中出现的问题。当前的流程如下：
- 员工A上报故障。
- 维修工进行处理。
- 按理说，处理完毕后应该由员工A进行验收，但因为员工A没空，所以转交给了员工B。
- 员工B进行验收，但验收不通过，于是重新发起故障上报。
问题出现在重新发起故障上报的环节：
- 当员工B重新发起故障上报时，系统界面上显示的上报人仍然是员工A，而不是员工B。
- 同样地，故障处理完成后，界面上显示的待验收人也依然是员工A，而不是员工B。
我们希望在这种情况下，能够将第二张故障单的上报人和待验收人都改为员工B，而不是继续显示员工A。
具体来说，当员工B点击“验收不通过”时，第一张故障单已经结束。而当员工B重新发起故障上报时，实际上已经生成了一张新的故障单。
现在的问题是，第一张故障单的处理流程没有问题，但在第二张故障单中，上报人和待验收人仍然显示为员工A。我们希望修改系统，使得在第二张故障单中，上报人和待验收人都显示为员工B。
之后我登录甘有博的账号：
当点击验收不通过的时候，第一张故障单就已经结束了。
当点击“提交”后，第二张故障单就已经完成了。
现在我已经大致了解了整个故障上报的流程，并且明确了问题所在。我们的目标很明确：将第二张故障单的上报人和待验收人改为员工B（甘有博）。
在实际操作中，我发现点击“验收不通过”时，系统并没有立即出现问题，只是新开了一张故障单。然而，当我进行到“提交”这一步时，问题就出现了：
为了找到这个问题的根源，我们需要找到相关的接口，然后进入这个接口看看接口的内部逻辑是什么样的。
还有一种方法找到这个接口，就是你去看前端代码中关于“提交”按钮的事件处理函数，看看点击“提交”按钮的时候，事件处理函数调用了哪个接口。我演示一下：
这个接口已经被成功找到了。进入这个接口的后端：
在查看代码的过程中，我发现 controller 层没有什么问题，所以我继续深入查看 service 层的代码逻辑。通过对 service 层的分析，我们可以进一步定位问题并找到解决方案。
在 service 层，我找到了这样一行代码：
这是将 form 对象转换成 entity 对象的代码。具体的转换思路如下：
- 属性复制：在转换的过程中，
portalForm2Entity方法会将form对象中的属性值复制到entity对象中。如果entity对象有的属性在form对象中不存在，那么这些属性在entity中保持默认值（通常是null）。 - 后续处理：在转换之后，代码中可能会对
entity对象的某些属性进一步赋值和处理。如果某些属性没有被进一步处理，这些属性就一直保持null，并且在保存到数据库时以null的形式存储。
了解了 service 层的代码后，我开始思考：这里有没有对上报人的值进行后续处理呢？结果发现，还真没有。代码中只是让待验收人等于上报人，但并没有明确表明上报人是谁。
因此，为了解决这个问题，我们需要在 service 层添加一些逻辑，将上报人设置为当前用户。具体操作如下：
通过上述修改，我们确保每次创建故障单时，上报人都会被设置为当前用户，从而避免了上报人属性是第一张故障单的上报人的问题。
总结
在当前系统中，创建故障单时，上报人属性没有被正确设置，导致上报人属性总是等于第一张故障单的上报人。
为了解决这个问题，我们需要在 service 层添加逻辑，将上报人明确设置为当前用户，以确保每次创建故障单时，上报人属性都是当前用户。
具体的步骤就是，在将 form 对象转换为 entity 对象之后，设置 entity 对象的上报人属性为当前用户。
通过上述修改，每次创建故障单时，上报人都会被设置为当前用户，从而避免了上报人属性是第一张故障单的上报人的问题。
