科室人员受理

科室人员受理和质控办受理实现逻辑类似，视图方面也类似。在开发过程中，笔者化身CV工程师，就是将质控办的代码copy过来，然后再结合科室人员受理的业务功能进行细微上的改动的。这里仅介绍科室人员与质控办受理的不同之处。

业务功能介绍

科室人员受理的事件状态分为：待整改、待评价和已评价。 顾名思义，待整改状态的事件为质控办所派发到该科室的事件，待评价状态的事件就是已经整改完成，等待质控办进行评价的事件，而已评价的事件就是质控办已经点评的事件。这也是为什么笔者在上一篇博客没有介绍质控办待评价和已评价事件详情功能的原因，实际开发流程中，科室人员和职能部门人员都没有对派发事件进行整改，哪里有什么事件可以供质控办去评价呢？
待整改事件详情。 根据需求文档，科室人员需要在待整改事件中进行 （1）根因分析 、（2）整改措施 和 （3）会议记录 的填写。
如果有会议相关的附件需要上传，也可以进行 （4）附件上传。有上传那就有附件预览和删除功能。 并且也提供给科室人员一个对 （5）整改确认完成 的按钮。
当然，与导师交流过这方面的需求，导师指出事件被派发到的涉事部门是能够查看别的部门的填写情况的（如果他们填写了），故也需提供一个 （6）查看其他部门填写情况（根据实际开发流程，这里并没有实现该功能，而是在后面实现完职能部门的业务功能后才实现的，这里先不做介绍） 的按钮。
此外，编写的内容一多，那就少不了 （7）暂存功能。既然有暂存功能，那用户上传的附件，在加载暂存数据的时候必然是要有 （8）下载相关附件 的。
待评价事件详情。 与待整改事件详情类似，可以查看到自己填写的内容、上传的相关附件以及其他部门的填写情况。
已评价事件详情。 在待评价事件详情的基础上，多一个质控办点评的内容。

设计步骤

首页视图。 这里就不做说明了，与我的上报首页视图类似。
查看事件详情视图。 结构与其他的查看事件详情类似，但内部视图是根据上面所写到的需求进行编写的。
待整改事件详情——根因分析、整改措施、会议记录填写及数据校验
待整改事件详情——附件上传、下载、预览、删除。 附件相关功能在之前的博客中介绍过，故不再具体说明了。而这里附件下载使用的是两个不同的API，但是结构是一致的。需要关注的是两个附件下载，一个附件下载是事件报告的附件，另一个是会议相关附件，是不同的附件。
视图代码
附件上传、下载、预览和删除方法

两个不同的附件下载请求
待整改事件详情——暂存。 暂存功能和编写不良事件报告的暂存功能逻辑一致，只是暂存的字段发生了一点变动而已。但都需要向服务器发起暂存请求。
待整改事件详情——加载暂存数据。 由于后端业务逻辑的设计，暂存的数据存放在对应ID的事件下，故需要加载暂存数据，即向服务器发起根据ID查询事件详情请求。即使用的方法就是根据ID查看事件详情方法。
待评价事件详情。 在待整改事件详情的基础上，将所有字段修改为不可编辑状态即可。
已评价事件详情。 在待评价事件详情的基础上，添加一个点评内容视图即可。