chore: 上传当前工作区修改

This commit is contained in:
2026-07-10 15:19:26 +08:00
parent bd9ca09983
commit a6a92ffeb2
35 changed files with 3031 additions and 778 deletions

View File

@@ -1730,3 +1730,976 @@ pm run build通过仅有既有警告。
- `work/ProductionManagement/DesignReportTask/05-验收证据.md`
- `work/ProductionManagement/DesignReportTask/06-决策记录.md`
- `gptlog-process/gpdlog.md`
### 验证结果
- 数据库脚本发布成功。
- 表和过程对象存在,过程修改时间为 `2026-06-30 18:01:39``2026-06-30 18:01:40`
- 下拉验证:`设计报工_物料查询 @过滤=N'5960'` 可返回物料,`设计报工_人员查询 @过滤=N'孙'` 可返回人员。
- 业务规则事务验证通过,测试数据已回滚。
- `npm run build` 通过,仅有项目既有 warning。
- 未分配菜单权限。
## 2026-07-09 DesignReportTask 菜单权限、物料下拉和表单规则调整
### 用户反馈
1.`DesignReportTask` 下的四个页面增加权限,账号代码为 `1`;数据库为 `192.168.2.92 / YL_MESDB`,目标表为 `[dbo].[登录基础数据_二级菜单]`
2. 修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`:新建设计任务弹框中,物料编码和父件物料编码没有默认选项,必须输入后触发才有选项。
3. 检查 `DesignReportTask` 下四个页面是否都有物料编码、父件物料编码默认选项问题,并统一修改。
4. 新建设计任务去掉指派对象必填项;物料名称和父件物料名称由选择编码后带出,禁止手工修改;检查四个页面是否都有此问题并处理。
5. 后续每次 GPT/Codex 执行完毕后,必须把中文执行日志追加到 `gptlog-process/gpdlog.md`,日志包含提问、结论和完整执行过程。
### 执行过程
1. 使用 `rg` 搜索 `DesignReportTask`、菜单表和相关路由配置,确认四个页面路径:
- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`
2. 读取 `src/router/getRouter.js``src/router/menuComponentModule.js`,确认系统从菜单表动态生成路由,菜单行里的 `path``componet``name` 必须和页面组件对应。
3. 读取既有菜单脚本,包括:
- `db_backups/add_formality_confirm_report_menu_20260626.sql`
- `db_backups/add_product_pass_rate_workstation_menu_20260630.sql`
- `db_backups/add_timely_kit_tracking_result_menu_20260629.sql`
4. 使用用户提供的数据库连接信息连接 `192.168.2.92 / YL_MESDB`。为避免凭据落盘,日志不记录数据库密码明文。
5. 查询 `[dbo].[登录基础数据_二级菜单]` 表结构,确认:
- `IDD` 是自增主键。
- `id` 是前端菜单树使用的手工编号。
- `pid` 是父菜单编号。
- `componet` 为现有字段名,系统按该字段加载组件。
6. 查询账号代码 `1` 的菜单记录,确认“生产管理”父菜单为 `id=3`
7. 查询账号代码 `1` 下是否已存在 `DesignReportTask` 相关菜单,确认执行前不存在 `设计任务``设计报工``设计工时校验``设计工时报表` 四条菜单。
8. 新增可重复执行脚本:
- `db_backups/add_design_report_task_menu_account1_20260709.sql`
9. 菜单脚本逻辑:
- 固定只处理账号代码 `1`
- 查找账号 `1` 的“生产管理”父菜单。
- 不存在时插入四条菜单。
- 已存在时修正 `pid``path``componet``name``title``icon``模块代码``是否启用`
10. 执行菜单脚本,成功新增四条菜单:
- `id=248``pid=3``设计任务``DesignReportTask/Task/index``/ProductionManagement/DesignReportTask/Task/index`
- `id=249``pid=3``设计报工``DesignReportTask/Report/index``/ProductionManagement/DesignReportTask/Report/index`
- `id=250``pid=3``设计工时校验``DesignReportTask/Check/index``/ProductionManagement/DesignReportTask/Check/index`
- `id=251``pid=3``设计工时报表``DesignReportTask/HoursReport/index``/ProductionManagement/DesignReportTask/HoursReport/index`
11. 回读菜单表,确认四条菜单各只有一条记录,`pid` 都为 `3``是否启用` 都为 `1``模块代码` 等于各自 `id`
12. 使用 `Test-Path` 校验四个前端组件文件均存在。
13. 读取 `Task/index.vue`,确认新建设计任务弹框中:
- `物料编码` 使用 `queryMaterialOptions` 远程查询。
- `父件物料编码` 使用 `queryParentMaterialOptions` 远程查询。
- 原逻辑只在输入关键字触发 `remote-method` 后才请求物料数据。
14.`Task/index.vue` 中新增 `loadDefaultMaterialOptions()` 方法,内部调用:
- `queryMaterialOptions('')`
- `queryParentMaterialOptions('')`
15.`Task/index.vue``created()``openAdd()``openEdit()` 中调用 `loadDefaultMaterialOptions()`,保证页面查询区、新建弹框和编辑弹框打开时都有默认物料列表。
16. 执行 `npm run build` 验证,构建通过,仅有项目既有 asset size、entrypoint size、browserslist warning。
17. 继续检查 `DesignReportTask` 下四个页面:
- `Task` 页面存在物料编码和父件物料编码远程下拉。
- `Report` 页面原本查询区的物料编码和父件编码是普通输入框。
- `Check` 页面原本查询区的物料编码是普通输入框。
- `HoursReport` 页面原本查询区的物料编码是普通输入框。
18. 修改 `Report/index.vue`
- 将查询区“物料编码”从输入框改为远程下拉。
- 将查询区“父件编码”从输入框改为远程下拉。
- 增加 `materialOptions``parentMaterialOptions`
- 增加 `loadDefaultMaterialOptions()``queryMaterialOptions()``queryParentMaterialOptions()``formatMaterialLabel()`
-`created()` 中预加载默认物料和父件物料列表。
19. 修改 `Check/index.vue`
- 将查询区“物料编码”从输入框改为远程下拉。
- 增加 `materialOptions`
- 增加 `loadDefaultMaterialOptions()``queryMaterialOptions()``formatMaterialLabel()`
-`created()` 中预加载默认物料列表。
20. 修改 `HoursReport/index.vue`
- 将查询区“物料编码”从输入框改为远程下拉。
- 增加 `materialOptions`
- 增加 `loadDefaultMaterialOptions()``queryMaterialOptions()``formatMaterialLabel()`
-`created()` 中预加载默认物料列表。
21. 执行 `npm run build` 验证四个页面物料下拉改动,构建通过,仅有项目既有 warning。
22. 检查四个页面是否存在“指派对象必填”和“物料名称、父件物料名称可编辑”的问题:
- `Task/index.vue` 有新建/编辑设计任务弹框,存在 `指派对象``assigneeIds` 必填校验,也存在可编辑的 `物料名称``父件物料名称` 输入框。
- `Report/index.vue``Check/index.vue``HoursReport/index.vue` 没有新建设计任务弹框,也没有可编辑的 `物料名称``父件物料名称` 表单项,只有查询条件和表格展示。
23. 检查数据库脚本 `db_backups/create_design_report_task_module_20260630.sql`,确认 `设计报工_任务_新增``设计报工_任务_编辑``@指派对象ID``@指派对象` 参数允许为空,后端无需修改。
24. 修改 `Task/index.vue`
- 删除 `rules.assigneeIds` 必填校验。
- 保留 `formData.assigneeIds` 数组字段和 `handleAssigneeChange()`,支持用户选择指派对象但不强制要求。
-`formData.物料名称` 输入框增加 `disabled`
-`formData.关联父件物料名称` 输入框增加 `disabled`
25. 使用固定字符串搜索确认:
- `请选择指派对象` 必填提示已不存在。
- `assigneeIds` 只剩表单数据字段和选择逻辑,不再作为必填规则。
- `Task/index.vue``物料名称``父件物料名称` 表单输入框均已禁用。
- 其它三个页面仅有表格展示的 `物料名称`,没有对应可编辑输入框。
26. 执行 `npm run build` 验证表单规则和禁用输入框改动,构建通过,仅有项目既有 warning。
27. 查看 `git status --short`,确认当前工作区还存在用户或既有修改:
- `doc/设计报工任务模块.docx`
- `src/views/PlanManagement/SelfMakePlando/index.vue`
- `doc/~$报工任务模块.docx`
- 本轮相关的 `DesignReportTask` 页面改动和菜单脚本。
28. 按用户要求补录本次会话日志到 `gptlog-process/gpdlog.md`,并确认后续执行完毕后继续追加中文日志。
### 修改文件
- `db_backups/add_design_report_task_menu_account1_20260709.sql`
- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`
- `gptlog-process/gpdlog.md`
### 结论
- 账号代码 `1` 已获得 `DesignReportTask` 下四个页面菜单权限,四条菜单均挂到“生产管理”下并启用。
- `Task` 页面新建/编辑设计任务弹框打开时,物料编码和父件物料编码已有默认选项。
- `Task``Report``Check``HoursReport` 四个页面涉及物料查询的下拉均已支持默认选项。
- 新建设计任务的“指派对象”不再必填。
- 新建设计任务的“物料名称”和“父件物料名称”只能由选择编码后带出,前端禁止手工修改。
- `Report``Check``HoursReport` 页面不存在新建设计任务弹框,也不存在可编辑的物料名称或父件物料名称输入框,无需做同类表单禁用修改。
- 多次执行 `npm run build` 均通过,仅有项目既有资源体积和 browserslist 过期 warning。
- 已建立后续日志规则:每次 GPT/Codex 执行完毕后,将中文执行日志追加到 `gptlog-process/gpdlog.md`
### 验证结果
- 菜单表回读结果确认 `设计任务``设计报工``设计工时校验``设计工时报表` 各 1 条,账号代码均为 `1``pid=3``是否启用=1`
- 四个前端组件文件均存在。
- 搜索确认 `请选择指派对象` 必填提示已删除。
- 搜索确认 `物料名称``父件物料名称` 的可编辑表单问题只存在于 `Task/index.vue`,且已加 `disabled`
- `npm run build` 通过。
## 2026-07-09 补录 2026-07-01 至 2026-07-08 项目修改日志
### 用户反馈
- 用户要求把 7 月 1、2、3 日的修改,以及 7 月 6、7、8 日本项目的修改追加到 `gptlog-process/gpdlog.md`
- 要求遵守既定日志规则:每次 GPT/Codex 执行完毕后,将中文执行过程日志追加到 `gptlog-process/gpdlog.md`,内容包含提问、结论和完整执行过程。
### 执行过程
1. 读取 `gptlog-process/gpdlog.md` 末尾,确认当前日志已包含 2026-06-30 设计报工模块日志和 2026-07-09 DesignReportTask 权限、下拉、表单规则调整日志。
2. 使用 `rg` 搜索 `2026-07``七月``7月``07-0` 等关键词,确认现有总日志中没有按 2026-07-01 至 2026-07-08 单独补录的完整章节。
3. 使用 `git log --since "2026-07-01" --until "2026-07-09"` 查询 Git 历史,确认可追溯提交主要为:
- `c4a2f6e`2026-07-07 17:30:12`feat: update production reporting workflows`
- `6d93e40`2026-07-08 10:38:56`feat: 增加结算工时和历史工时选择`
- `bd9ca09`2026-07-08 16:52:29`feat: 增加设备数据导出`
4. 使用 PowerShell 按 `LastWriteTime` 查询 2026-07-01 至 2026-07-08 的项目文件修改时间,排除 `.git``node_modules``dist` 等目录。
5. 文件时间显示的关键记录:
- 2026-07-02`src/views/PlanManagement/TimelyKitTrackingResult/index.vue`
- 2026-07-03`AGENTS.md`
- 2026-07-06`src/views/ProductionManagement/OutsourceMange/index.vue`
- 2026-07-07`src/views/QualityManagement/CheckTask/processReceive.vue``src/views/ProductionManagement/SettlementWorkhours/index.vue`、多个 20260707 SQL 脚本、`src/views/ProductionManagement/ProductPassRateWorkstation/index.vue`
- 2026-07-08`src/views/PlanManagement/SelfMakePlandone/index.vue``src/views/PlanManagement/WorkstationPlan/index.vue``src/views/DeviceManagement/Devicedata/index.vue``src/views/DeviceManagement/DeviceDataHistory/index.vue``doc/设计报工任务模块.docx``dist.zip`
6. 查询 2026-07-01 至 2026-07-04 的 Git 提交记录,未发现该日期范围内的 Git 提交。
7. 读取 `AGENTS.md`,确认其内容为日志记录规则:每次 GPT/Codex 执行完毕后,将中文完整执行过程日志追加到 `gptlog-process/gpdlog.md`
8. 读取 2026-07-07 提交 `c4a2f6e` 的文件清单和关键 diff确认该提交覆盖 24 个文件,包含设计报工模块、结算工时、产品合格率、及时齐套跟踪结果、外协管理、质检收检和数据库脚本。
9. 读取 2026-07-08 提交 `6d93e40` 的 diff确认其重点是排产相关页面增加结算工时和历史工时选择。
10. 读取 2026-07-08 提交 `bd9ca09` 的 diff确认其重点是设备实时数据和设备历史数据增加导出 Excel 功能。
11. 对无 Git 提交但有文件修改时间的 7 月 1、2、3、6 日,按“可追溯证据”记录,不把无法确认的内容写成确定提交。
12. 将本次补录内容追加到 `gptlog-process/gpdlog.md`
### 2026-07-01 修改补录
- 通过 Git 历史和文件修改时间检查,未发现 2026-07-01 当天有可追溯的项目代码或文档修改记录。
- 现有日志中出现的 `2026-07-01` 主要是设备信息维护日期字段的测试数据,例如入账日期测试值,不代表 2026-07-01 当天发生了项目文件修改。
### 2026-07-02 修改补录
- 文件修改时间显示 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` 在 2026-07-02 11:50:48 修改。
- 后续该变更随 2026-07-07 提交 `c4a2f6e` 入库。
- 主要修改内容:
1. 调整 `getRouteProcessName(process)`
2.`process.工序名称``process.指派对象` 组合显示工序路线名称。
3. 如果工序名称中已经包含半角或全角括号形式的指派对象,则不重复追加。
4. 如果存在指派对象且工序名称未包含该指派对象,则显示为 `工序名称(指派对象)`
- 结论:及时齐套跟踪结果页面的路线工序显示更明确,能在工序名称旁体现指派对象。
### 2026-07-03 修改补录
- 文件修改时间显示仓库根目录新增或修改 `AGENTS.md`,时间为 2026-07-03 09:52:09。
- 当前 `AGENTS.md` 内容为本项目日志记录规则:
1. 每次 GPT/Codex 执行完毕后,须将完整执行过程日志追加到 `gptlog-process/gpdlog.md`
2. 日志包含提问、结论和完整执行过程。
3. 写入日志必须使用中文。
- 当前 `git status` 显示 `AGENTS.md` 仍为未跟踪文件。
- 结论7 月 3 日主要是建立项目级日志记录约束文件。
### 2026-07-06 修改补录
- 文件修改时间显示 `src/views/ProductionManagement/OutsourceMange/index.vue` 在 2026-07-06 13:36:58 修改。
- 后续该变更随 2026-07-07 提交 `c4a2f6e` 入库。
- 主要修改内容:
1. 外协管理操作列中,“发料”按钮增加 `v-if="scope.row.单据状态 != '已取消'"`
2. 外协管理操作列中,“收料”按钮增加 `v-if="scope.row.单据状态 != '已取消'"`
- 结论:已取消单据不再展示发料、收料操作,避免对取消状态单据继续执行业务操作。
### 2026-07-07 修改补录
- Git 提交:`c4a2f6e`
- 提交时间2026-07-07 17:30:12。
- 提交说明:`feat: update production reporting workflows`
- 提交规模24 个文件,约 3713 行新增、35 行删除。
#### 数据库脚本
1. `db_backups/create_design_report_task_module_20260630.sql`
- 新增独立设计报工模块数据库脚本。
- 创建 `MES_设计报工_任务``MES_设计报工_记录``MES_设计报工_校验记录`
- 创建设计报工物料、人员、项目、任务、开始、结束、完成、删除、工时校验、工时报表等过程。
- 脚本说明中明确:不写入现有生产报工表、不上传 SAP、不新增菜单权限。
2. `db_backups/exclude_unfinished_assembly_orders_from_close_query_20260707.sql`
- 修改 `计划排产_生产订单关闭_查询全部订单`
- 在“可关闭”逻辑中识别未结束装配订单。
- 对存在装配开始但未结束记录的订单进行排除,避免未结束装配订单被误判为可关闭。
3. `db_backups/optimize_settlement_workhours_query_20260707.sql`
- 优化 `生产管理_结算工时_查询`
- 增加合同号、产品编码、订单号、工位、开始日期、结束日期、数据条数等筛选参数。
- 使用临时表组织任务、基础工时数据和汇总结果,提高查询结构清晰度。
4. `db_backups/fix_settlement_workhours_query_restore_workhour_rows_20260707.sql`
- 修复结算工时查询,恢复从 `View_生产工时视图` 关联回来的工时报工行。
- 使用 `TaskAID`、开始时间等关键字段组织报工明细和操作人拼接。
- 继续保留结算工时汇总需要的报工工时、辅助工时、完成数、单件工时等字段。
#### 前端页面
1. `src/views/PlanManagement/SelfMakePlando/index.vue`
- 增加“历史工时”入口。
- 新增历史工时弹框。
- 通过 `生产管理_结算工时_查询` 按产品编码查询历史工时。
- 展示任务描述、生产订单号、工位、报工工时、辅助工时、完成数、结算报工单件工时、结算辅助单件工时、操作人等字段。
2. `src/views/PlanManagement/SelfMakePlandone/index.vue`
- 增加与 `SelfMakePlando` 类似的“历史工时”入口和弹框。
- 通过产品编码查询历史结算工时数据并展示。
3. `src/views/PlanManagement/TimelyKitTrackingResult/index.vue`
- 路线工序名称增加指派对象显示,避免只看工序名无法区分指派对象。
4. `src/views/ProductionManagement/OutsourceMange/index.vue`
- 已取消单据隐藏“发料”和“收料”按钮。
5. `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue`
- 新增导出按钮。
- 引入 `xlsx`
- 支持把主表和明细导出为 Excel。
- 导出字段包含关闭日期、生产订单号、物料、计划数量、完成数量、不良数量、合格率、工序、工位、检验说明等。
6. `src/views/ProductionManagement/SettlementWorkhours/index.vue`
- 新增导出按钮。
- 引入 `xlsx`
- 导出结算工时树表数据,并在末尾写入报工工时、主辅工时和合计工时汇总。
- 将“主辅工时”列名调整为“辅助工时”。
- 增加展开/收起状态记录,导出时只导出当前展开明细。
7. `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- 新增设计任务页面。
- 支持设计任务查询、新建、编辑、删除。
- 支持项目号、物料编码、图号、父件编码、预计时间、状态等查询条件。
8. `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- 新增设计报工页面。
- 支持任务开始、结束、完成。
- 遵守未结束不能完成、已有报工记录不能删除等独立设计报工规则。
9. `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- 新增设计工时校验页面。
- 支持单条校验和批量校验。
10. `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`
- 新增设计工时报表页面。
- 支持按操作人、日期、任务形成树形工时报表。
11. `src/views/QualityManagement/CheckTask/processReceive.vue`
- 质检收检流程中对部分调试输出做调整。
- 对采购订单行匹配条件保留工序名称和未关闭行状态判断。
12. `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue``src/views/ProductionManagement/SettlementWorkhours/index.vue`
- 两个报表类页面均增加 Excel 导出能力,统一使用 `xlsx`
#### 工作文档和日志
- 更新 `work/ProductionManagement/DesignReportTask/README.md`
- 更新 `work/ProductionManagement/DesignReportTask/01-项目功能内容.md``06-决策记录.md`
- 复制或更新 `work/ProductionManagement/DesignReportTask/设计报工任务模块.docx`
- 追加 `gptlog-process/gpdlog.md`
#### 结论
- 7 月 7 日主要是生产报工、结算工时、设计报工、订单关闭判断、产品合格率导出等生产业务流程集中更新。
- 设计报工模块的表、过程、四个页面和工作文档在该提交中完成入库。
- 结算工时查询和展示能力得到增强,后续 7 月 8 日继续在排产页面使用这些结算工时数据。
### 2026-07-08 修改补录
#### 提交一:增加结算工时和历史工时选择
- Git 提交:`6d93e40`
- 提交时间2026-07-08 10:38:56。
- 提交说明:`feat: 增加结算工时和历史工时选择`
- 涉及文件:
- `src/views/PlanManagement/SelfMakePlando/index.vue`
- `src/views/PlanManagement/SelfMakePlandone/index.vue`
- `src/views/PlanManagement/WorkstationPlan/index.vue`
##### 主要修改内容
1. `SelfMakePlando/index.vue`
- 调整历史工时弹框列顺序。
- 将结算报工单件工时、结算辅助单件工时前置展示。
- 单件工时展示时乘以 60便于按分钟口径查看。
- 保留生产订单号、工位、操作人、报工工时、辅助工时、完成数等字段。
2. `SelfMakePlandone/index.vue`
- 将原“历史工时”按钮列注释掉。
- 保留页面其他业务列。
3. `WorkstationPlan/index.vue`
- 工位排产表增加“结算工时”和“结算单件工时”列。
- 工位汇总和日期汇总增加结算工时合计。
- 单任务行增加结算单件工时选择按钮。
- 新增历史工时弹框,按产品编码调用 `生产管理_结算工时_查询`
- 历史工时弹框中支持选择“报工”或“辅助”的单件工时。
- 选择后调用 `MES_OrderPlanned_EditTaskPlanned` 保存到任务的 `结算单件工时`
- 增加 `calcStandardHours``calcSettlementHours``formatHistoryPieceHours``canSelectHistoryHour` 等辅助方法。
- 扩展表格最小宽度和列样式,适配新增结算工时列。
##### 结论
- 7 月 8 日上午主要增强排产侧的结算工时使用能力,支持从历史结算工时中选择单件工时并回写排产任务。
#### 提交二:增加设备数据导出
- Git 提交:`bd9ca09`
- 提交时间2026-07-08 16:52:29。
- 提交说明:`feat: 增加设备数据导出`
- 涉及文件:
- `src/views/DeviceManagement/Devicedata/index.vue`
- `src/views/DeviceManagement/DeviceDataHistory/index.vue`
##### 主要修改内容
1. `Devicedata/index.vue`
- 设备实时数据页面增加“导出”按钮。
- 引入 `xlsx`
- 增加 `exporting` 状态,导出时按钮 loading。
- 将当前表格数据导出为 Excel。
- 导出字段包含序号、设备名称、参数名称、数值、单位、更新时间。
- 导出文件名格式为 `设备实时数据_yyyyMMdd_HHmmss.xlsx`
2. `DeviceDataHistory/index.vue`
- 设备历史数据页面增加“导出”按钮。
- 抽出 `buildQueryParams(pageSize, pageCurrent)` 复用查询参数构建。
- 普通查询继续按分页查询。
- 导出时使用总条数作为页大小,一次性查询全部历史数据后导出。
- 导出字段包含序号、设备名称、参数名称、数值、采集时间。
- 导出文件名格式为 `设备历史数据_yyyyMMdd_HHmmss.xlsx`
##### 结论
- 7 月 8 日下午主要补齐设备实时数据和历史数据的 Excel 导出能力。
#### 其它 2026-07-08 文件时间记录
- `doc/设计报工任务模块.docx` 文件时间显示为 2026-07-08 18:27:31当前 `git status` 显示该文件仍处于修改状态。
- `dist.zip` 文件时间显示为 2026-07-08 09:10:41属于构建或发布压缩产物本次补录仅记录文件时间不作为源码变更结论。
### 本次补录修改文件
- `gptlog-process/gpdlog.md`
### 本次补录结论
- 已将 2026-07-01、2026-07-02、2026-07-03、2026-07-06、2026-07-07、2026-07-08 的可追溯项目修改追加到总日志。
- 2026-07-01 未发现可追溯项目文件修改,已在日志中明确说明。
- 2026-07-02、2026-07-03、2026-07-06 根据文件修改时间和后续提交 diff 补录。
- 2026-07-07、2026-07-08 根据 Git 提交记录和文件 diff 补录。
- 本次操作只修改日志文件,没有修改业务代码和数据库。
### 本次补录验证结果
- `git log` 已确认 2026-07-07 和 2026-07-08 的三个提交。
- `Get-ChildItem` 文件时间检查已确认 2026-07-02、2026-07-03、2026-07-06、2026-07-08 的相关文件。
- `AGENTS.md` 已读取并确认内容为中文日志记录规则。
- `gptlog-process/gpdlog.md` 已追加本节补录内容。
## 2026-07-09 DesignReportTask 项目号来源修正
### 用户反馈
- 用户指出项目号来源错了。
- 正确来源应为 `SAP.SBO_YL.dbo.VIEW_OPRJ.项目代码`
- 要求检查 `DesignReportTask` 下四个页面是否都有这个问题,并全部修改。
### 执行过程
1. 使用 `rg` 搜索 `DesignReportTask` 下四个页面和数据库脚本中的 `项目号``projectNo``projectOptions``queryProjects``设计报工_项目查询`
2. 确认原始实现问题:
- `db_backups/create_design_report_task_module_20260630.sql``设计报工_项目查询` 原来从 `dbo.MES_设计报工_任务` 的已有项目号取值。
- `Task/index.vue` 已有项目号远程下拉,但来源依赖错误过程,并且新建弹框中允许 `allow-create` 手工创建项目号。
- `Report/index.vue``Check/index.vue``HoursReport/index.vue` 的项目号查询条件是普通输入框,没有统一使用项目号来源下拉。
3. 连接目标数据库 `192.168.2.92 / YL_MESDB`,检查 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ]`
4. 查询确认 SAP 项目视图字段:
- `项目代码`
- `项目名称`
5. 抽样查询 SAP 项目视图,确认存在 `CW-260001``CW260002``HT230075-1` 等项目代码。
6. 新增数据库增量脚本:
- `db_backups/update_design_report_project_source_20260709.sql`
7. 增量脚本重建 `dbo.设计报工_项目查询`
- 来源改为 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ]`
- 返回 `项目号 = 项目代码`
- 同时返回 `项目名称`
- 支持按 `项目代码``项目名称` 模糊过滤。
8. 同步修改 `db_backups/create_design_report_task_module_20260630.sql` 中的 `设计报工_项目查询`,避免以后重跑完整脚本时又恢复为错误来源。
9. 执行 `db_backups/update_design_report_project_source_20260709.sql` 到目标库,执行成功。日志中不记录数据库密码明文。
10. 验证存储过程:
- `设计报工_项目查询 @过滤=N''` 可返回 SAP 项目代码和项目名称。
- `设计报工_项目查询 @过滤=N'CW-260001'` 返回 `CW-260001`
11. 修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- 查询区项目号下拉显示从 `项目号` 改为 `项目号 | 项目名称`
- 新建/编辑弹框项目号下拉显示从 `项目号` 改为 `项目号 | 项目名称`
- 去掉新建/编辑弹框项目号下拉的 `allow-create`,避免手工录入非 SAP 项目代码。
- 打开新建/编辑弹框时重新调用 `queryProjects('')`,保证默认项目列表可用。
- 增加 `formatProjectLabel()`
12. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- 将查询区项目号从普通输入框改为远程下拉。
- 新增 `projectOptions``queryProjects()``formatProjectLabel()`
- 页面创建时预加载 SAP 项目代码列表。
13. 修改 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- 将查询区项目号从普通输入框改为远程下拉。
- 新增 `projectOptions``queryProjects()``formatProjectLabel()`
- 页面创建时预加载 SAP 项目代码列表。
14. 修改 `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`
- 将查询区项目号从普通输入框改为远程下拉。
- 新增 `projectOptions``queryProjects()``formatProjectLabel()`
- 页面创建时预加载 SAP 项目代码列表。
15. 使用 `rg` 检查四个页面:
- 四个页面均有 `queryProjects()`
- 四个页面项目号均使用 `设计报工_项目查询`
- `Task/index.vue` 中不再存在 `allow-create`
16. 更新工作文档:
- `work/ProductionManagement/DesignReportTask/README.md`
- `work/ProductionManagement/DesignReportTask/01-项目功能内容.md`
- `work/ProductionManagement/DesignReportTask/02-项目程序开发详细步骤.md`
- `work/ProductionManagement/DesignReportTask/03-推进台账.md`
- `work/ProductionManagement/DesignReportTask/04-任务矩阵.md`
- `work/ProductionManagement/DesignReportTask/05-验收证据.md`
- `work/ProductionManagement/DesignReportTask/06-决策记录.md`
17. 文档更新内容:
- 项目号来源从“待确认”改为 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ].[项目代码]`
- 记录 `设计报工_项目查询` 使用 SAP 项目代码。
- 记录四个页面项目号查询条件统一为远程下拉。
- 将任务矩阵 `DRT-009` 改为已完成,并新增 `DRT-020`
- 将决策记录中“项目号临时实现”标记为已废弃。
18. 执行 `npm run build`,构建通过,仅有项目既有资源体积和 browserslist 过期 warning。
19. 查看 `git status --short`,确认本轮涉及的新增和修改文件,同时发现工作区还有不属于本轮操作的一批 `work/DeviceManagement/DeviceInformation` 删除状态,未做回退。
### 修改文件
- `db_backups/update_design_report_project_source_20260709.sql`
- `db_backups/create_design_report_task_module_20260630.sql`
- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`
- `work/ProductionManagement/DesignReportTask/README.md`
- `work/ProductionManagement/DesignReportTask/01-项目功能内容.md`
- `work/ProductionManagement/DesignReportTask/02-项目程序开发详细步骤.md`
- `work/ProductionManagement/DesignReportTask/03-推进台账.md`
- `work/ProductionManagement/DesignReportTask/04-任务矩阵.md`
- `work/ProductionManagement/DesignReportTask/05-验收证据.md`
- `work/ProductionManagement/DesignReportTask/06-决策记录.md`
- `gptlog-process/gpdlog.md`
### 结论
- 项目号来源已从错误的 `MES_设计报工_任务` 历史数据改为 SAP 项目视图 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ]``项目代码`
- `设计报工_项目查询` 已发布到目标库,并返回 `项目号``项目名称`
- `DesignReportTask` 四个页面的项目号查询条件已统一使用 SAP 项目代码远程下拉。
- `Task` 页面新建/编辑项目号不再允许手工创建非 SAP 项目号。
- 工作文档中的项目号“待确认”和“临时实现”口径已更新。
### 验证结果
- SAP 视图字段验证:存在 `项目代码``项目名称`
- 存储过程验证:`设计报工_项目查询 @过滤=N'CW-260001'` 返回 `CW-260001`
- 前端代码检查:四个页面均存在 `queryProjects()``formatProjectLabel()`
- 前端构建:`npm run build` 通过,仅有项目既有 warning。
## 2026-07-09 DesignReportTask 项目号远程搜索补强
### 用户反馈
- 用户反馈:项目号也要像物料编码一样,需要远程搜索。
### 执行过程
1. 复查 `DesignReportTask` 四个页面中项目号控件配置。
2. 初次使用 `rg` 检查时PowerShell 对引号和管道符解析导致命令报错,随后改用 `Get-Content``Select-String` 读取页面内容。
3. 确认当前四个页面已使用 `remote-method="queryProjects"`,但项目号下拉需要进一步补强为和物料编码一致的使用体验:
- 页面打开时加载默认项目。
- 用户输入关键字时通过 `queryProjects` 远程查询。
- 清空选择后恢复默认项目列表。
- 打开下拉且本地列表为空时自动加载默认项目列表。
4. 修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- 设计任务查询区项目号下拉增加 `@clear="loadDefaultProjectOptions"`
- 新建/编辑弹框项目号下拉增加 `@clear="loadDefaultProjectOptions"`
- 两个项目号下拉均增加 `@visible-change="handleProjectVisibleChange"`
- 新增 `loadDefaultProjectOptions()`,内部调用 `queryProjects('')`
- 新增 `handleProjectVisibleChange(visible)`,下拉打开且 `projectOptions` 为空时加载默认项目列表。
- `created()``openAdd()``openEdit()` 改为调用 `loadDefaultProjectOptions()`
5. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- 查询区项目号下拉增加清空后加载默认项目和打开时自动补加载逻辑。
- 新增 `loadDefaultProjectOptions()``handleProjectVisibleChange()`
- `created()` 改为调用 `loadDefaultProjectOptions()`
6. 修改 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- 查询区项目号下拉增加清空后加载默认项目和打开时自动补加载逻辑。
- 新增 `loadDefaultProjectOptions()``handleProjectVisibleChange()`
- `created()` 改为调用 `loadDefaultProjectOptions()`
7. 修改 `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`
- 查询区项目号下拉增加清空后加载默认项目和打开时自动补加载逻辑。
- 新增 `loadDefaultProjectOptions()``handleProjectVisibleChange()`
- `created()` 改为调用 `loadDefaultProjectOptions()`
8. 使用 `Select-String` 检查四个页面,确认均存在:
- `remote-method="queryProjects"`
- `@clear="loadDefaultProjectOptions"`
- `@visible-change="handleProjectVisibleChange"`
- `loadDefaultProjectOptions`
- `handleProjectVisibleChange`
9. 第一次执行 `npm run build`124 秒超时,未返回编译结果。
10. 使用 240 秒超时时间重新执行 `npm run build`,构建通过,仅有项目既有资源体积和 browserslist 过期 warning。
### 修改文件
- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`
- `gptlog-process/gpdlog.md`
### 结论
- `DesignReportTask` 四个页面的项目号均已按物料编码的远程搜索口径补强。
- 项目号现在支持默认列表、输入远程搜索、清空恢复默认列表、打开空列表时自动加载。
- 项目号数据仍来自已修正的 `设计报工_项目查询`,即 SAP 项目视图 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ].[项目代码]`
### 验证结果
- 四个页面均检查到项目号远程搜索相关配置。
- 第二次 `npm run build` 构建通过,仅有项目既有 warning。
## 2026-07-09 DesignReportTask 操作列按钮横向显示
### 用户反馈
- 用户反馈:操作列下的功能按钮不要纵向显示,容易误触,改成横向;检查 `DesignReportTask` 下四个页面是不是都有这个问题,并全部修改。
### 执行过程
1. 检查 `DesignReportTask` 下四个页面:
- `Task/index.vue` 存在操作列,按钮为“编辑 / 删除”。
- `Report/index.vue` 存在操作列,按钮为“开始 / 结束 / 完成”。
- `Check/index.vue` 存在操作列,按钮为“校验 / 已校验”。
- `HoursReport/index.vue` 未发现操作列,因此没有纵向按钮问题。
2. 第一次按精确标签搜索操作列未命中,随后改用 `rg` 关键字和 UTF-8 读取方式定位具体模板位置。
3. 修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- 操作列宽度从 `130` 调整为 `150`
- 将“编辑 / 删除”按钮包裹到 `design-action-buttons` 容器内。
- 新增横向 `inline-flex` 样式,设置不换行、居中、固定按钮间距。
- 覆盖 Element UI 相邻按钮默认左边距,避免按钮被默认样式挤到纵向排列。
4. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- 操作列宽度从 `180` 调整为 `210`
- 将“开始 / 结束 / 完成”按钮包裹到 `design-action-buttons` 容器内。
- 新增与 `Task` 页面一致的横向按钮样式。
5. 修改 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- 操作列宽度从 `90` 调整为 `100`
- 将“校验 / 已校验”按钮包裹到 `design-action-buttons` 容器内。
- 新增与其他页面一致的横向按钮样式。
6.`HoursReport/index.vue` 进行检查,确认页面只有报表树形表格和查询条件,没有操作列,未做代码修改。
7. 使用 `rg` 检查三个已修改页面,确认都已存在 `design-action-buttons` 模板和样式。
8. 执行 `npm run build`构建通过输出仅包含项目既有资源体积过大、Browserslist / baseline 数据过期 warning。
### 修改文件
- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- `gptlog-process/gpdlog.md`
### 结论
- `Task``Report``Check` 三个有操作列的页面已统一改为横向按钮排列,避免按钮纵向堆叠导致误触。
- `HoursReport` 页面没有操作列,本次无需修改。
### 验证结果
- 已检查到三个页面均存在 `design-action-buttons` 横向按钮容器。
- `npm run build` 构建通过,仅有项目既有 warning。
## 2026-07-09 DesignReportTask 设计报工多人开始结束逻辑
### 用户反馈
- 用户要求修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- 业务规则:
- 一个任务允许多个人员分别点击开始和结束。
- A 点击开始后B 也可以点击开始。
- A 点击结束时,只记录 A 自己的开始时间和结束时间。
- B 点击结束时,只记录 B 自己的开始时间和结束时间。
- 点击完成时必须判断所有已点击开始的人员都已点击结束。
- 如果有人开始后未结束,需要提示具体是谁未结束,且不更新任务状态。
- 只有所有开始记录都已结束后,才允许完成任务。
### 执行过程
1. 读取 `Report/index.vue`,确认当前前端逻辑使用 `未结束报工数` 控制按钮:
- `canStart` 要求 `未结束报工数 === 0`,导致 A 开始后 B 不能开始。
- `canEnd` 只判断任务是否存在未结束记录,不能保证只结束当前操作人的记录。
- `canComplete` 在存在未结束记录时直接禁用按钮,无法按用户要求点击后提示未结束人员。
2. 检查 `db_backups/create_design_report_task_module_20260630.sql`,确认数据库过程也存在同样限制:
- `设计报工_任务_开始` 原来只要任务存在任意未结束记录就禁止开始。
- `设计报工_任务_结束` 原来取任务最新一条未结束记录,不区分当前操作人。
- `设计报工_任务_完成` 原来只提示任务存在未结束报工,未返回具体人员。
3. 查询目标库 `YL_MESDB``MES_设计报工_记录` 表字段,确认已有 `操作人ID``操作人``开始时间``结束时间``工时秒数``报工状态` 等字段,支持按人员拆分报工记录,无需改表结构。
4. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- 查询参数增加 `当前操作人ID``当前操作人`
- 表格增加“未结束人员”列。
- `canStart` 改为只判断当前用户是否存在未结束报工。
- `canEnd` 改为只在当前用户存在未结束报工时可点击。
- `canComplete` 改为任务未完成且已有报工记录即可点击。
- `completeTask` 增加前端判断:如果 `未结束报工数 > 0`,提示 `未结束报工人员`,不调用完成过程。
5. 新增增量脚本 `db_backups/update_design_report_multi_person_work_20260709.sql`
- 更新 `设计报工_任务_查询`,返回 `当前用户未结束报工数``未结束报工人员`
- 更新 `设计报工_任务_开始`,只禁止当前人员重复开始,允许其他人员同时开始。
- 更新 `设计报工_任务_结束`,只结束当前人员自己的未结束记录;若其他人员仍未结束,任务状态保持 `执行中`
- 更新 `设计报工_任务_完成`,如果存在未结束记录,返回“以下人员还未点击结束:人员名单”,不更新任务状态。
6. 同步更新完整建库脚本 `db_backups/create_design_report_task_module_20260630.sql`,确保后续重建模块时不会丢失多人报工逻辑。
7. 使用 `sqlcmd -f 65001` 将增量脚本发布到 `192.168.2.92 / YL_MESDB`,未在日志中记录数据库密码。
8. 第一次事务验证时发现人员名单拼接使用 XML 方法会受到当前 SQL 执行环境 `QUOTED_IDENTIFIER` 设置影响,过程执行报错。
9. 将人员名单拼接从 XML 方法改为 SQL Server 2019 支持的 `STRING_AGG`,重新更新增量脚本和完整建库脚本。
10. 重新发布增量脚本到目标库。
11. 使用事务创建临时测试任务并回滚,验证流程:
- 测试 A 点击开始成功。
- 测试 B 点击开始成功。
- 查询结果显示 `报工次数=2``未结束报工数=2``当前用户未结束报工数=1``未结束报工人员=测试A、测试B`
- 测试 A 点击结束成功。
- A 结束后点击完成失败返回“以下人员还未点击结束测试B”。
- 测试 B 点击结束成功。
- A/B 都结束后点击完成成功。
- 事务最终回滚,测试数据未保留。
12. 执行 `npm run build`,前端构建通过,仅有项目既有资源体积和 Browserslist / baseline 数据过期 warning。
13. 查询数据库确认 `GPT-TEST` 临时测试任务残留数为 0并确认 `设计报工_任务_完成` 已发布为包含 `STRING_AGG` 的新定义。
### 修改文件
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `db_backups/update_design_report_multi_person_work_20260709.sql`
- `db_backups/create_design_report_task_module_20260630.sql`
- `gptlog-process/gpdlog.md`
### 结论
- 设计报工页面已支持同一任务多人分别开始、分别结束。
- 当前人员只能结束自己的未结束报工记录,不会误结束其他人员记录。
- 完成任务时会检查所有开始记录是否都已结束;如仍有人未结束,会提示具体人员并阻止任务完成。
- 数据库过程已同步发布到目标库,完整建库脚本也已同步更新。
### 验证结果
- 数据库事务验证通过,测试数据已回滚且无残留。
- `npm run build` 构建通过,仅有项目既有 warning。
## 2026-07-09 DesignReportTask DID 3 完成误判复查与防护
### 用户反馈
- 用户反馈:刚测试 DID=3 任务,点击完成时另一个人没有点结束也提示完成了;完成后另一个人点不了结束。
### 执行过程
1. 查询目标库 `192.168.2.92 / YL_MESDB` 中 DID=3 的真实数据:
- `MES_设计报工_任务` 中 DID=3 状态为 `已完成`
- `MES_设计报工_记录` 中 DID=3 只有 1 条记录,操作人为“超级管理员”,且该记录已有结束时间。
- DID=3 未查询到第二个人的未结束报工记录。
2. 复查数据库过程定义:
- `设计报工_任务_完成` 已包含“以下人员还未点击结束”的拦截逻辑。
- `设计报工_任务_结束` 已按当前人员查找未结束记录。
3. 结论判断:
- DID=3 完成成功的直接原因是数据库中没有“另一个人”的开始记录。
- 另一个人点不了结束,是因为 DID=3 没有该人员可结束的未结束记录,且任务已完成。
4. 为避免页面旧数据或并发操作再次造成误判,修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `completeTask` 改为异步方法。
- 点击完成时新增 `getLatestTask(DID)`,先实时调用 `设计报工_任务_查询` 获取最新任务状态。
- 完成前使用实时返回的 `未结束报工数``未结束报工人员` 判断,不再只依赖表格旧行数据。
- 如果实时查询发现有人未结束,提示具体人员并停止调用完成过程。
- 如果实时查询发现任务已完成,提示“任务已完成”并刷新表格。
- 如果任务没有已结束报工,提示不能完成。
- `canEnd` 改为只要当前用户存在未结束报工就允许点击结束,不再因为任务状态是 `已完成` 就禁用,用于修复历史异常状态下“已完成但仍有未结束记录”的结束入口。
5. 新增数据库防护脚本 `db_backups/fix_design_report_complete_guard_20260709.sql`
- 重新发布 `设计报工_任务_开始``设计报工_任务_结束``设计报工_任务_完成`
- 开始、结束、完成均对对应 DID 的任务行使用事务锁,避免完成与开始/结束并发造成状态误判。
- 完成过程在事务内重新查询未结束人员,存在未结束记录时返回具体人员并不更新任务状态。
- 结束过程允许历史异常状态下“任务已完成但当前人员仍有未结束记录”的人员继续结束自己的记录。
6. 第一次事务验证时发现过程内部直接 `ROLLBACK TRANSACTION` 会回滚外层测试事务。
7. 修改防护脚本事务写法:
- 没有外层事务时由过程自己开启并提交事务。
- 存在外层事务时使用 `SAVE TRANSACTION` 保存点。
- 失败时只回滚过程自己的保存点,不破坏调用方外层事务。
8. 使用 `sqlcmd -f 65001` 发布防护脚本到目标库,日志中未记录数据库密码。
9. 使用事务验证多人未结束完成拦截:
- 测试 A 开始成功。
- 测试 B 开始成功。
- 测试 A 结束成功。
- 此时点击完成返回失败提示“以下人员还未点击结束测试B”。
- 查询显示任务仍为 `执行中``未结束报工数=1``当前用户未结束报工数=1``未结束报工人员=测试B`
10. 使用事务验证历史异常状态:
- 临时创建一个状态为 `已完成` 但测试 B 仍未结束的任务。
- 查询显示 `未结束报工数=1``当前用户未结束报工数=1`
- 测试 B 点击结束成功。
- 结束后查询显示 `未结束报工数=0`,任务保持 `已完成`
11. 两组事务验证均已回滚,查询确认 `GPT-GUARD``GPT-BAD` 测试数据残留为 0。
12. 执行 `npm run build`,构建通过,仅有项目既有资源体积和 Browserslist / baseline 数据过期 warning。
13. 查询 DID=3 当前未结束记录数为 0确认 DID=3 没有可让另一个人结束的未结束记录。
### 修改文件
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `db_backups/fix_design_report_complete_guard_20260709.sql`
- `gptlog-process/gpdlog.md`
### 结论
- DID=3 本次完成成功是因为数据库里并没有第二个人的未结束开始记录。
- 已补充前端完成前实时查库,避免表格旧数据导致误判。
- 已补充数据库事务锁防护,完成过程会在最终更新状态前重新检查未结束人员。
- 已允许历史异常状态下,当前人员仍有未结束记录时可以点击结束自己的记录。
### 验证结果
- DID=3 当前未结束记录数为 0。
- 多人未结束完成拦截验证通过。
- 历史异常已完成状态下结束验证通过。
- 测试数据无残留。
- `npm run build` 构建通过,仅有项目既有 warning。
## 2026-07-09 清空 DesignReportTask 设计报工业务数据
### 用户反馈
- 用户要求:清空设计相关的数据。
### 执行过程
1.`DesignReportTask` 设计报工模块业务数据范围处理,未清理菜单权限、存储过程和表结构。
2. 确认需要清空的三张业务表:
- `dbo.MES_设计报工_任务`
- `dbo.MES_设计报工_记录`
- `dbo.MES_设计报工_校验记录`
3. 清空前查询目标库 `YL_MESDB` 当前数据量:
- `MES_设计报工_任务`2 行。
- `MES_设计报工_记录`2 行。
- `MES_设计报工_校验记录`1 行。
4. 清空前先导出本地备份,备份目录:
- `db_backups/design_report_data_backup_20260709_110417/`
5. 备份文件包括:
- `MES_设计报工_任务.json`
- `MES_设计报工_记录.json`
- `MES_设计报工_校验记录.json`
- `_summary.json`
6. 使用事务按依赖顺序清空数据:
- 先清空 `MES_设计报工_校验记录`
- 再清空 `MES_设计报工_记录`
- 最后清空 `MES_设计报工_任务`
7. 清空后执行 `DBCC CHECKIDENT`,将三张表自增标识重置为 0。
8. 再次查询三张业务表行数,确认均为 0。
9. 查询三张表当前标识值,确认均为 0。
### 修改文件
- `db_backups/design_report_data_backup_20260709_110417/MES_设计报工_任务.json`
- `db_backups/design_report_data_backup_20260709_110417/MES_设计报工_记录.json`
- `db_backups/design_report_data_backup_20260709_110417/MES_设计报工_校验记录.json`
- `db_backups/design_report_data_backup_20260709_110417/_summary.json`
- `gptlog-process/gpdlog.md`
### 结论
- `DesignReportTask` 设计报工模块三张业务表已清空。
- 清空前数据已备份到本地 `db_backups/design_report_data_backup_20260709_110417/`
- 表结构、存储过程、菜单权限未清理。
- 三张表自增编号已重置,后续新增数据将从 1 开始。
### 验证结果
- `MES_设计报工_任务` 当前 0 行。
- `MES_设计报工_记录` 当前 0 行。
- `MES_设计报工_校验记录` 当前 0 行。
- 三张表当前标识值均为 0。
## 2026-07-09 DesignReportTask 已完成任务禁止开始补充判断
### 用户反馈
- 用户反馈:当任务状态为完成时,点击开始应该提示失败;现在任务已经被另一个人点击完成后,还能点击开始。
### 执行过程
1. 检查 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
2. 确认页面原有 `canStart(row)` 会根据当前表格行的 `单据状态` 禁用开始按钮,但如果另一个人完成任务后当前页面未刷新,当前行仍可能是旧状态,导致用户仍能点击开始。
3. 查询数据库过程 `dbo.设计报工_任务_开始`,确认后端已包含“任务已完成,不能开始”的拦截逻辑。
4. 修改 `Report/index.vue``startTask(row)`
-`startTask` 改为异步方法。
- 点击开始时先调用已有 `getLatestTask(DID)` 实时查询数据库最新任务状态。
- 使用实时返回结果覆盖当前表格行数据。
- 如果实时状态为 `已完成`,提示“任务已完成,不能开始”,刷新表格,并停止调用开始过程。
- 如果当前人员已经存在未结束报工,提示“当前人员已存在未结束的报工记录”,并停止调用开始过程。
- 只有实时状态允许开始时才调用 `设计报工_任务_开始`
5. 使用事务临时创建一个状态为 `已完成` 的测试任务,并调用 `设计报工_任务_开始` 验证后端返回:
- `result=0`
- `message=任务已完成,不能开始`
6. 验证事务回滚后测试数据残留数为 0。
7. 执行 `npm run build`,构建通过,仅有项目既有资源体积和 Browserslist / baseline 数据过期 warning。
### 修改文件
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `gptlog-process/gpdlog.md`
### 结论
- 已完成任务点击“开始”时,前端会先实时查库。
- 如果任务已被其他人完成,会立即提示“任务已完成,不能开始”,不会再调用开始过程。
- 后端开始过程也已确认存在同样拦截,前后端均有保护。
### 验证结果
- 后端模拟已完成任务点击开始,返回“任务已完成,不能开始”。
- 测试数据无残留。
- `npm run build` 构建通过,仅有项目既有 warning。
## 2026-07-09 DesignReportTask 设计任务删除失败逻辑修正
### 用户反馈
- 用户反馈:设计任务删除的结果逻辑不正确。任务 1 点击删除并确认时提示“删除成功”,实际应该提示“删除失败”。
### 执行过程
1. 检查 `src/views/ProductionManagement/DesignReportTask/Task/index.vue``deleteTask(row)`
- 原逻辑确认后直接调用 `设计报工_任务_删除`
- 前端只按返回 `result` 判断成功或失败。
2. 查询目标库中 DID=1 的真实数据:
- DID=1 当前状态为 `已完成`
- DID=1 存在 3 条 `MES_设计报工_记录`
- DID=1 存在 3 条 `MES_设计报工_校验记录`
3. 检查数据库删除过程 `dbo.设计报工_任务_删除`
- 原过程只判断是否存在报工记录。
- 对任务不存在、已完成状态、删除 0 行、校验记录等场景保护不足。
4. 修改 `Task/index.vue`
- 删除确认后先调用新增的 `getLatestTask(DID)` 实时查询数据库最新任务。
- 如果任务不存在,提示“删除失败:任务不存在或已被删除”。
- 如果 `报工次数 > 0`,提示“删除失败:该任务已有设计报工记录,不能删除”。
- 如果任务状态为 `已完成`,提示“删除失败:任务已完成,不能删除”。
- 如果任务状态不是 `待开始`,提示对应状态不能删除。
- 只有实时查询确认可删除时,才调用 `设计报工_任务_删除`
- 删除调用增加异常捕获,接口异常时提示“删除失败”。
5. 新增数据库脚本 `db_backups/fix_design_report_delete_guard_20260709.sql`
- 重新发布 `dbo.设计报工_任务_删除`
- 只允许 `待开始` 且无报工记录、无校验记录的任务删除。
- 任务不存在、已有报工、已有校验、已完成、非待开始状态、删除 0 行均返回 `result=0`
- 删除成功时才返回 `result=1`
6. 同步更新完整建库脚本 `db_backups/create_design_report_task_module_20260630.sql` 中的删除过程定义。
7. 发布删除防护脚本到目标库 `YL_MESDB`,日志中未记录数据库密码。
8. 验证 DID=1 删除:
- 执行 `设计报工_任务_删除 @DID=1` 返回 `result=0`
- 返回消息为“删除失败:该任务已有设计报工记录,不能删除”。
- DID=1 任务仍存在。
9. 使用事务临时创建一个 `待开始` 且无报工记录的测试任务,验证可删除场景:
- 删除过程返回 `result=1``message=删除成功`
- 事务内删除后任务残留为 0。
- 回滚后测试数据残留为 0。
10. 执行 `npm run build`,构建通过,仅有项目既有资源体积和 Browserslist / baseline 数据过期 warning。
### 修改文件
- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- `db_backups/fix_design_report_delete_guard_20260709.sql`
- `db_backups/create_design_report_task_module_20260630.sql`
- `gptlog-process/gpdlog.md`
### 结论
- 任务 1 这类已有报工记录的设计任务,现在删除时会提示删除失败。
- 前端删除前会实时查库,不再只依赖表格旧数据。
- 后端删除过程已补充完整保护,只允许未开始且无关联业务记录的任务删除。
### 验证结果
- DID=1 删除返回失败,提示“该任务已有设计报工记录,不能删除”。
- 可删除的待开始测试任务仍能正常删除。
- 测试数据无残留。
- `npm run build` 构建通过,仅有项目既有 warning。
## 2026-07-09 DesignReportTask 增加类别字段
### 用户提问
- 用户要求:设计报工模块增加字段“类别”,类型为文本输入。
### 执行过程
1. 检查 `DesignReportTask` 下四个页面:
- `Task/index.vue`
- `Report/index.vue`
- `Check/index.vue`
- `HoursReport/index.vue`
2. 确认“类别”应作为设计任务主数据字段保存,并在各业务查询中展示和筛选。
3. 修改 `Task/index.vue`
- 查询区增加“类别”文本输入框。
- 表格增加“类别”列。
- 新建/编辑设计任务弹框增加“类别”文本输入框。
- 表单初始数据增加 `类别`
- 任务查询参数增加 `类别`
- 新增、编辑保存参数增加 `类别`
- 删除前实时查询任务详情时补充 `类别` 参数,避免过程参数不一致。
4. 修改 `Report/index.vue`
- 查询区增加“类别”文本输入框。
- 表格增加“类别”列。
- 报工任务查询参数增加 `类别`
- 开始/结束/完成前实时查询任务详情时补充 `类别` 参数。
5. 修改 `Check/index.vue`
- 查询区增加“类别”文本输入框。
- 表格增加“类别”列。
- 工时校验查询参数增加 `类别`
6. 修改 `HoursReport/index.vue`
- 查询区增加“类别”文本输入框。
- 表格增加“类别”列。
- 工时报表查询参数增加 `类别`
- 树形标题中优先显示“类别 | 任务描述”,方便按类别识别任务。
7. 修改完整建库脚本 `db_backups/create_design_report_task_module_20260630.sql`
- `MES_设计报工_任务` 表增加 `[类别] nvarchar(100) NULL`
- 增加 `COL_LENGTH` 兼容判断,旧库缺少字段时自动 `ALTER TABLE`
- 以下过程增加 `@类别` 参数、返回字段和筛选条件:
- `设计报工_任务_查询`
- `设计报工_任务_新增`
- `设计报工_任务_编辑`
- `设计报工_记录_查询`
- `设计报工_工时校验_查询`
- `设计报工_工时报表_作业者工时_查询`
8. 新增增量脚本 `db_backups/add_design_report_category_field_20260709.sql`
- 用于直接更新现有数据库,不重建已有业务对象。
- 增加任务表“类别”字段。
- 重建上述 6 个查询/新增/编辑相关过程。
9. 将增量脚本发布到目标数据库 `192.168.2.92 / YL_MESDB`,日志中不记录数据库密码。
10. 数据库验证:
- 检查 `MES_设计报工_任务``类别` 字段存在,结果为 `1`
- 检查 6 个相关存储过程均包含 `@类别` 参数和 `[类别]` 字段,结果均为 `1`
- 第一次事务验证时误按旧理解传入了 `@任务状态`,数据库返回该参数不存在;随后查询真实过程签名并按真实参数重新验证。
- 第二次事务验证中执行新增,返回 `result=1``message=新增成功`、验证 DID 为 `6`,新增类别为 `结构`
- 同一事务内执行编辑,返回 `result=1``message=编辑成功`,编辑后类别为 `电气`
- 事务回滚后验证数据残留数量为 `0`
11. 前端静态检查:
- 使用 `rg``Select-String` 确认四个页面均存在“类别”查询输入、表格列和查询参数。
12. 执行 `npm run build`
- 构建通过。
- 仅有项目既有资源体积超限 warning以及 Browserslist / baseline-browser-mapping 数据过期提示。
### 修改文件
- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
- `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
- `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`
- `db_backups/create_design_report_task_module_20260630.sql`
- `db_backups/add_design_report_category_field_20260709.sql`
- `gptlog-process/gpdlog.md`
### 结论
- 设计报工模块已增加“类别”文本字段。
- 新建设计任务和编辑设计任务可以录入、保存、修改“类别”。
- 任务管理、设计报工、工时校验、工时报表四个页面均支持按“类别”筛选并展示“类别”列。
- 数据库表和相关存储过程已同步更新到目标库。
### 验证结果
- 数据库字段存在,相关存储过程均已包含“类别”。
- 新增/编辑事务验证通过,测试数据已回滚,无残留。
- `npm run build` 构建通过,仅有项目既有 warning。
## 2026-07-10 DesignReportTask Check 和 HoursReport 菜单权限补录
### 用户提问
- 用户要求给 `DesignReportTask``check``HoursReport` 添加账号代码 `1` 的二级菜单权限。
- 目标数据库为 `192.168.2.92 / YL_MESDB`,目标表为 `[dbo].[登录基础数据_二级菜单]`
- 数据库账号信息由用户提供,本日志不记录数据库明文密码。
### 执行过程
1. 读取当前项目目录,确认存在 `gptlog-process/gpdlog.md``db_backups``DesignReportTask` 相关历史记录。
2. 使用 `rg` 搜索 `登录基础数据_二级菜单``DesignReportTask``HoursReport``check`,确认项目内已有设计报工模块和历史菜单处理记录。
3. 确认本机存在 `sqlcmd`,路径为 SQL Server ODBC 170 工具目录下的 `SQLCMD.EXE`
4. 读取 `db_backups/add_design_report_task_menu_account1_20260709.sql`,确认历史脚本中四个页面的菜单定义:
- `DesignReportTask/Task/index`:设计任务
- `DesignReportTask/Report/index`:设计报工
- `DesignReportTask/Check/index`:设计工时校验
- `DesignReportTask/HoursReport/index`:设计工时报表
5. 第一次直接读取脚本和日志时发现 PowerShell 默认编码显示中文乱码,随后改用 `Get-Content -Encoding UTF8` 重新读取,确认脚本内容和日志中文正常。
6. 使用 `sqlcmd -f 65001` 连接目标库,查询账号代码 `1``DesignReportTask/Check/index``DesignReportTask/HoursReport/index``设计工时校验``设计工时报表`,执行前未查询到对应记录。
7. 同步查询账号代码 `1` 的一级父菜单,确认“生产管理”父菜单存在且启用,`id=3`
8. 查询 `[dbo].[登录基础数据_二级菜单]` 表结构,确认:
- `IDD` 为 identity 字段。
- `id` 不是 identity需要手工维护。
- 菜单字段包含 `pid``path``componet``name``title``icon``账号代码``模块代码``是否启用``操作时间` 等。
9. 查询当前最大 `id``249`
10. 查询账号代码 `1` 下已有 `DesignReportTask` 菜单,确认已有:
- `id=248``设计任务``DesignReportTask/Task/index`,已启用。
- `id=249``设计报工``DesignReportTask/Report/index`,已启用。
11. 在事务中补录并启用两条缺失菜单:
- `id=250``pid=3``path=DesignReportTask/Check/index``componet=/ProductionManagement/DesignReportTask/Check/index``name=DesignReportCheck``title=设计工时校验``icon=PayStateSearch``账号代码=1``模块代码=250``是否启用=1`
- `id=251``pid=3``path=DesignReportTask/HoursReport/index``componet=/ProductionManagement/DesignReportTask/HoursReport/index``name=DesignReportHoursReport``title=设计工时报表``icon=DimensionsSummaryReport``账号代码=1``模块代码=251``是否启用=1`
12. 事务提交后 SQL 返回汇总:插入 `2` 条,更新启用 `2` 条,父菜单 `parent_id=3`
13. 再次查询账号代码 `1` 下所有 `DesignReportTask` 菜单,确认共有四条并全部启用:
- `248`:设计任务
- `249`:设计报工
- `250`:设计工时校验
- `251`:设计工时报表
14. 本次未修改前端代码和业务表结构,只修改了目标数据库中的二级菜单权限记录,并追加本日志。
### 结论
- 账号代码 `1` 已补齐 `DesignReportTask``Check``HoursReport` 两个页面的二级菜单权限。
- 两条菜单均挂在账号代码 `1` 的“生产管理”父菜单下,父菜单 `id=3`
- 当前账号代码 `1``DesignReportTask` 四个菜单 `Task``Report``Check``HoursReport` 均存在且 `是否启用=1`
### 验证结果
- `设计工时校验``id=250``pid=3``是否启用=1`
- `设计工时报表``id=251``pid=3``是否启用=1`
- 最终复查查询返回 `DesignReportTask` 四条菜单,编号为 `248``251`
## 2026-07-10 上传所有修改到远程
### 用户提问
- 用户要求:上传所有修改到远程。
### 执行过程
1. 检查 Git 工作区状态,确认当前存在已修改、已删除和未跟踪文件。
2. 确认当前分支为 `snapshot/local-save-20260625-154806`
3. 确认远程仓库为 `origin`,地址为 `http://154.8.160.151:3000/meswork/MES_Manage_View_V20.git`
4. 查询最近一次提交,当前 HEAD 为 `bd9ca09 feat: 增加设备数据导出`
5. 使用 `git status -sb` 确认当前分支跟踪 `origin/snapshot/local-save-20260625-154806`
6. 使用 `git branch -vv` 确认本地分支已绑定同名远程分支。
7. 使用 `git diff --stat` 汇总已跟踪文件改动,确认包含设计报工模块前端、数据库脚本、文档、日志和设备资料目录删除等改动。
8. 使用 `git ls-files --others --exclude-standard` 汇总未跟踪文件,确认包含 `AGENTS.md`、设计报工相关增量 SQL 脚本和数据备份 JSON。
9. 执行 `git fetch origin` 刷新远程状态。
10. 第一次执行上游分支检查时PowerShell 将 `@{u}` 解析为哈希字面量导致命令失败;随后改用引号包裹 `@{u}` 重新执行。
11. 重新确认上游分支为 `origin/snapshot/local-save-20260625-154806`
12. 使用 `git rev-list --left-right --count HEAD...'@{u}'` 确认本地与远程提交差异为 `0 0`,提交前不存在分叉。