Closed
[需求]: 创建和查询Job支持OperationApplyTime #911
lisiguangAdd on Jul 13Closed at Aug 5
openUBMC-robot
Jul 13 Comments：
Jul 13 Comments：
Jul 13 Assign ZanthoxylumLeaf as responsible person
Jul 13 Added label: sig/sig-interface
openUBMC-robot
Jul 13 Comments：
Jul 13 Comments：
欢迎来到 openUBMC 社区
Hey @aaronlee , 感谢你对社区的贡献.
机器人使用手册
有关指令的使用，可以点击 说明文档 或 论坛 查看详情。开发人员可以在每个PR或Issue下方评论特定指令来触发机器人任务。
联系指引
有疑问可以联系 SIG: sig-interface ,
维护者是： @DataSculptor, @WeliveWelove, @aaronlee, @huanghan ,
优秀贡献者是： @L_Ling, @yelvsub .
Jul 13 associated Kanban: openUBMC 26.09 需求看板
openUBMC-robot
Jul 13 Comments：
Jul 13 Comments：
Issue 工作流介绍
社区的需求和缺陷的工作流状态处于纳管中。
| 类型 | 上个状态 | 下个状态 | 评论命令 | 谁可以操作 |
|---|---|---|---|---|
| 需求 | 待办的 | 已接纳 | /todo2accepted | SIG组: sig-release-management (maintainer) |
| 需求 | 已接纳 | 开发中 | /accepted2developing | 仓库成员角色: Maintainer, Committer, Contributor, Owner |
| 需求 | 开发中 | 转测中 | /developing2testing | 仓库成员角色: Maintainer, Committer, Contributor, Owner |
| 需求 | 转测中 | 待验收 | /testing2UAT | 仓库成员角色: Maintainer, Committer, Contributor, Owner |
| 需求 | 待验收 | 已完成 | /UAT2done | SIG组: sig-QA (maintainer,committer) |
| 需求 | 待办的 | 已挂起 | /todo2suspended | SIG组: sig-release-management (maintainer) |
| 需求 | 已挂起 | 已接纳 | /suspended2accepted | SIG组: sig-release-management (maintainer) |
| 需求 | 待办的 | 已拒绝 | /todo2rejected | SIG组: sig-release-management (maintainer) |
| 需求 | 已拒绝 | 已接纳 | /rejected2accepted | SIG组: sig-release-management (maintainer) |
openUBMC-robot
Jul 20 Comments：
Jul 20 Comments：
Jul 20 Assign ZanthoxylumLeaf as responsible person
openUBMC-robot
Jul 20 Comments：
Jul 20 Comments：
Jul 20 changed custom state from 待办的 to 已接纳
zhaotianli
Jul 21 Comments：
Jul 21 Comments：
PR #639 回顾分析: 【修改描述】编排任务的资源树和创建编排任务的方法新增OperationApplyTime、VisibilityScope属性
仓库: openUBMC/mdb_interface
分支: main → main (zzzzzzz123456/mdb_interface → openUBMC/mdb_interface)
作者: @zzzzzzz123456 (zhengzege)
合并时间: 2026-07-21T11:02:57+08:00
关联设计: 【已评审】编排任务新增OperationApplyTime，支持触发式执行job
1. AI 检视意见追踪
本 PR 经过两轮 AI 检视：
- 平台 AI（gitcode-bot，2026-07-18 10:37）：代码审查报告结论为"无需要报告的问题"，未提出 actionable 修改建议，无后续追踪项。
- 一致性检视 AI（@Richardli25，2026-07-20 11:20）：判定"部分一致"，提出以下 3 条意见。
对一致性检视 AI 提出的意见，后续处理追踪如下：
| # | AI 发现 | 严重度 | 后续处理 | 说明 |
|---|---|---|---|---|
| 1 | TriggerJobs 资源协作方法未实现（设计评审点3） | 严重 | ⏳ 未响应 | AI 检视（07-20 11:20）之后，最终合入 diff 中 Jobs.json 的 methods 仍无 TriggerJobs 定义；PR 标题/描述未补充拆分说明，开发者亦未在评论区给出解释 |
| 2 | VisibilityScope 缺少 default: "Shared" 字段 |
中等 | ⏳ 未响应 | 最终合入 diff 中 VisibilityScope 仅有 example: "Shared"，仍未配置 default 字段（对比 OperationApplyTime 已正确配置 default: ""） |
| 3 | PR 标题/CHANGELOG 未说明 TriggerJobs 由后续 PR 承担 | 建议 | ⏳ 未响应 | PR 标题与 CHANGELOG [1.110.19] 条目均仅描述属性与 CreateJob，未补充 TriggerJobs 拆分关系说明 |
| 指标 | 结果 |
|---|---|
| 一致性检视 AI 意见总数 | 3 |
| 已采纳并修复 | 0 |
| 已回复说明 | 0 |
| 未响应 | 3 |
说明：本 PR 以"部分一致"结论被合入（aaronlee 于 07-20 22:45 给出 /lgtm /approve）。从合入结果推断，评审点3（TriggerJobs）疑似按拆分策略由后续 PR 承担，但开发者未在 PR 评论区对 AI 意见做显式回复，亦未更新 PR 描述说明拆分关系，故均归为"未响应"。建议后续若确属拆分，在对应 PR/Issue 中补充说明，以便追溯。
2. 人工检视补充
- 检视人: @liuyq77 (liuyongqi)、@aaronlee (lisiguang)
- 意见概要:
- @liuyq77（diff_comment，定位
Job.json:233VisibilityScope description 行）：建议"优化描述，可查询修改job信息的接口范围"。 - @aaronlee：评论
/lgtm /approve，整体认可。
- @liuyq77（diff_comment，定位
- 解决状态:
3. 评审贴覆盖情况
评审贴链接：【已评审】编排任务新增OperationApplyTime，支持触发式执行job
| # | 评审点 | 是否涵盖 | 说明 |
|---|---|---|---|
| 1 | 新增资源协作属性 OperationApplyTime、VisibilityScope | ✅ 已涵盖 | Job.json 新增两属性，baseType/enum/emitsChangedSignal/可读写均符合设计；OperationApplyTime default: "" 已配置 |
| 2 | CreateJob 请求体 Request 新增键值 | ✅ 已涵盖 | Jobs.json description 追加 OperationApplyTime、VisibilityScope |
| 3 | 新增资源协作方法 TriggerJobs | ❌ 未涵盖 | Jobs.json methods 中无 TriggerJobs 定义，本 PR 未实现 |
| 4 | Redfish 接口响应体新增 Oem/openUBMC/OperationApplyTime | — 不涉及 | 设计帖注明"redfish接口以网管\工具评审会议结论为准"，属北向 Redfish 接口，由其他仓库实现，不计入 mdb_interface 覆盖 |
覆盖统计（MDB 资源协作接口）: 2/3（评审点1、2 已涵盖；评审点3 未涵盖）
4. 总结
- AI 意见采纳情况：本 PR 是一个典型案例——一致性检视 AI 提出的 3 条意见（含 1 条严重、1 条中等、1 条建议）均未被开发者显式采纳或回复，但 PR 仍以"部分一致"结论被合入。结合 PR 标题与最终 diff 推断，评审点3（TriggerJobs）很可能按能力拆分策略留待后续 PR 实现，但缺乏显式的拆分说明会导致后续追溯困难。
- 开发者响应态度：开发者对 AI 意见未在评论区做文字回应；但对人工检视者 @liuyq77 的描述优化建议响应迅速并采纳修复，说明开发者更倾向于直接通过代码修改回应而非评论讨论。
- 人工检视的补充价值：@liuyq77 的 diff_comment 精准定位到 VisibilityScope 描述语义不足，其建议被完整采纳，提升了属性描述的可读性；这正是人工检视相较于 AI 的价值补充——关注表达清晰度而非仅设计一致性。
- 值得关注的模式与改进建议：
- 拆分 PR 的可追溯性：当一个设计帖的能力由多个 PR 分批实现时，建议在每个 PR 描述中显式标注"本 PR 仅覆盖评审点 X/Y，评审点 Z 将由后续 PR 承担"，并关联到对应 Issue，避免 AI 检视与人工评审产生"实现缺失"的误判。
- default 字段一致性：同一 PR 中 OperationApplyTime 配置了
default，而 VisibilityScope 未配置（仅有 example），同类属性应保持配置习惯一致；建议在后续补充 VisibilityScope 的default: "Shared"或明确说明不配置的原因。 - 对 AI 意见的闭环：即便选择不采纳 AI 意见（如确认拆分），建议在评论区给出一句话说明，形成检视意见的闭环，便于回顾与知识沉淀。
此回顾分析由 AI (OpenClaw + GLM-5-turbo) 完成
zhaotianli
Jul 21 Comments：
Jul 21 Comments：
PR #1364 回顾分析: 【a36ba15c3c1616da2534e43be4463752】编排任务新增visibility_scope和OperationApplyTime属性
仓库: openUBMC/rackmount
分支: main → main (zzzzzzz123456/rackmount → openUBMC/rackmount)
作者: @zzzzzzz123456 (zhengzege)
合并时间: 2026-07-21T19:39:15+08:00
关联设计: 【已评审】编排任务新增OperationApplyTime，支持触发式执行job
关联 Issue: #911 创建和查询Job支持OperationApplyTime
本 PR 是 rackmount 侧（Redfish/Web 接口层）的实现，与已回顾的 mdb_interface PR #639 共同覆盖设计 topic 6963 的能力。
1. AI 检视意见追踪
本 PR 经历两轮 AI 检视：
- 平台 AI（gitcode-bot，2026-07-18 10:47）：代码审查报告结论为"⛔ 需要修改"，提出 4 个 P0 阻塞问题 + 2 个 P3 建议问题。
- 一致性检视 AI（@Richardli25，2026-07-20 11:56）：判定"一致"，提出 3 条低优先级/信息性观察。
1.1 平台 AI（gitcode-bot）意见追踪
| # | AI 发现 | 优先级 | 后续处理 | 说明 |
|---|---|---|---|---|
| 1 | job_service.lua:55 self. 应为 m.，会导致 GET Jobs 接口运行时崩溃 |
P0 阻塞 | ✅ 已采纳修复 | commit d28c4e99（07-18 16:13）修改该行，resolved: true |
| 2 | job_service.lua:72 self. 应为 m.，会导致健康状态聚合接口崩溃 |
P0 阻塞 | ✅ 已采纳修复 | commit d28c4e99（07-18 16:13）修改该行，resolved: true |
| 3 | Jobs.json:591 ${Statements/CheckOriginAndVisibilityScope() 缺少闭合 }，DELETE 校验失效 |
P0 阻塞 | ✅ 已采纳修复 | commit 798dbb72（07-20 11:40）补全 }，resolved: true |
| 4 | Jobs.json:231 ${Statements/CheckOriginAndVisibilityScope() 缺少闭合 }，GET 校验失效 |
P0 阻塞 | ✅ 已采纳修复 | commit 798dbb72（07-20 11:40）补全 }，resolved: true |
| 5 | job_service.lua:32 条件表达式括号位置误导（and/or 优先级） |
P3 建议 | ✅ 已采纳修复 | commit 798dbb72（07-20 11:40）调整括号，resolved: true |
| 6 | sp.lua:38 同样的括号误导问题 |
P3 建议 | ✅ 已采纳修复 | commit ca7eeccb（07-18 17:16）调整括号，resolved: true |
1.2 一致性检视 AI（@Richardli25）意见追踪
| # | AI 发现 | 优先级 | 后续处理 | 说明 |
|---|---|---|---|---|
| 1 | S1: sp.lua 移除 sp_job_type 白名单对存量数据的影响（非 SP 类 WEB-origin Job 可能泄露） |
低 | ⏳ 未响应 | AI 检视（07-20 11:56）后开发者未显式回复；最终合入 diff 中白名单仍被移除，可见性完全由 check_job_is_visible_in_web_backend 决定。属低风险建议，不阻塞 |
| 2 | S2: Lua 条件括号分组可读性（同平台 AI P3） | 低 | ✅ 已采纳修复 | 与平台 AI #5/#6 同一问题，已修复并标记 Resolved |
| 3 | S3: StartUpdate → TriggerJobs 触发链路不在本 PR 范围 |
信息 | ⏳ 未响应 | 属信息性观察，TriggerJobs 评审点确实未在本 PR 实现（见评审贴覆盖分析） |
汇总指标
| 指标 | 结果 |
|---|---|
| 平台 AI 意见总数 | 6（4 P0 + 2 P3） |
| 平台 AI 已采纳并修复 | 6 |
| 平台 AI 未响应 | 0 |
| 一致性 AI 意见总数 | 3（1 低 + 1 低 + 1 信息） |
| 一致性 AI 已采纳并修复 | 1（S2 与平台 AI 重叠） |
| 一致性 AI 未响应 | 2（S1 低风险、S3 信息性） |
2. 人工检视补充
- 检视人: @liuyq77 (liuyongqi)、@aaronlee (lisiguang)
- 意见概要:
- @liuyq77（diff_comment，定位
Jobs.json:192CreateJob 相关）："CreateJob参数要传入VisibilityScope，否则设置VisibilityScope就没意义了"。精准指出 CreateJob 接口若不在创建时设置 VisibilityScope，则新增该属性无法生效。 - @aaronlee：评论
/lgtm /approve，整体认可。
- @liuyq77（diff_comment，定位
- 解决状态:
3. 评审贴覆盖情况
评审贴链接：【已评审】编排任务新增OperationApplyTime，支持触发式执行job
| # | 评审点 | 是否涵盖 | 说明 |
|---|---|---|---|
| 1 | 新增资源协作属性 OperationApplyTime、VisibilityScope | ✅ 已涵盖（消费侧） | 属性定义在 mdb_interface（PR #639）；rackmount 侧在 ProcessingFlow Destination 中正确消费两属性（Jobs.json GET/DELETE 流程均映射 Origin/VisibilityScope/OperationApplyTime），并实现可见性过滤逻辑 check_job_is_visible_in_redfish/check_job_is_visible_in_web_backend |
| 2 | CreateJob 请求体 Request 新增键值 | ✅ 已涵盖 | get_create_job_req.lua 与 sp.lua:get_create_job_params 在创建任务时按 JobType 自动设置 VisibilityScope（响应 @liuyq77 意见） |
| 3 | 新增资源协作方法 TriggerJobs | ❌ 未涵盖 | 全仓 interface_config/ 下无 TriggerJobs 定义，本 PR 未实现。与 mdb_interface PR #639 一致，评审点3 未被任一 PR 覆盖 |
| 4 | Redfish 接口响应体新增 Oem/openUBMC/OperationApplyTime | ✅ 已涵盖 | Jobs.json GET 响应 Oem/{{OemIdentifier}} 新增 OperationApplyTime（line 261），与设计评审点4 一致 |
覆盖统计（rackmount 侧）: 3/4（评审点1消费侧、2、4 已涵盖；评审点3 未涵盖）
注：评审点3（TriggerJobs）在 mdb_interface PR #639 和本 PR 中均未实现，疑似按拆分策略留待后续 PR。建议在后续 PR 中补充说明并关联本 Issue。
4. 总结
- AI 意见采纳情况（优秀）：本 PR 是 AI 检视价值的高效体现——平台 AI 一次性精准识别出 4 个 P0 阻塞问题（2 处
self.nil 引用将导致 Redfish 接口运行时崩溃、2 处 JSON 模板${}未闭合将导致可见性校验失效），开发者全部采纳并在两轮 commit 中修复。一致性检视 AI 判定"一致"且无阻塞项。AI 意见的采纳率达 100%（阻塞项）/ 33%（建议项含重叠），体现了 AI 在静态缺陷发现上的高效性。 - 开发者响应态度（积极）：开发者对平台 AI 的 P0 阻塞项响应迅速（首轮回合同日修复 2 处
self.、次日修复 JSON 语法），对人工检视者 @liuyq77 的意见在约 1 小时内完成代码修改。虽未在评论区做文字回应，但均通过代码修改直接闭环，所有 diff_comment 均resolved: true。 - 人工检视的补充价值：@liuyq77 的意见切中要害——指出 CreateJob 若不传入 VisibilityScope 则该属性形同虚设，这是设计落地完整性的关键一环。该意见促使开发者在创建任务逻辑中补充了按 JobType 自动推导 VisibilityScope 的逻辑，弥补了 AI 检视未覆盖的业务语义完整性问题。
- 值得关注的模式与改进建议：
- 拆分 PR 的可追溯性（遗留）：评审点3（TriggerJobs）在 mdb_interface 和 rackmount 两个 PR 中均未实现，与 PR #639 回顾的发现一致。建议后续承担 TriggerJobs 的 PR 显式说明覆盖关系并关联 Issue #911。
- VisibilityScope 推导逻辑的一致性：Redfish 端（
get_create_job_req.lua）将 SP 类设为Redfish，Web 端（sp.lua）将 SP 类设为Web，两者方向相反但语义自洽（分别对齐各自接口可见性）。建议在代码注释中补充说明此设计意图，避免后续维护者误改。 - S1 存量数据兼容性（低风险）：
sp.lua移除sp_job_type白名单后，历史非 SP 类的 WEB-origin Job（若 VisibilityScope 为 nil）可能在 Web 后端列表中暴露。当前系统若 Web 端仅创建 SP Job 则无影响，建议确认存量数据情况。
此回顾分析由 AI (OpenClaw + GLM-5.1) 完成
HuangJiayi
Aug 5 Comments：
Aug 5 Comments：
/accepted2developing
Aug 5 changed custom state from 已接纳 to 开发中
HuangJiayi
Aug 5 Comments：
Aug 5 Comments：
/developing2testing
Aug 5 changed custom state from 开发中 to 转测中
HuangJiayi
Aug 5 Comments：
Aug 5 Comments：
/testing2UAT
Aug 5 changed custom state from 转测中 to 待验收
wangyanyan
Aug 5 Comments：
Aug 5 Comments：
/UAT2done
Aug 5 changed custom state from 待验收 to 已完成
Aug 5 Close issue
感谢您为社区贡献新需求！请按照以下提示提供详细信息，以便我们更好地理解并跟进。
版本分支
openUBMC main
需求属性
所属版本
openUBMC 26.09
工作量
0.68 人月
是否需要编码
NA
是否免测试
NA
周边依赖
NA
需求来源
NA
需求描述
简要说明
创建和查询Job支持OperationApplyTime
系统用户
BMC运维、网管
前置条件
BMC运行正常
主成功场景
1. 创建Job接口支持指定OperationApplyTime，至少需要指定的参数有：OnStartUpdateRequest；查询Job接口支持返回OperationApplyTime信息
2. 支持对应OperationApplyTime的调度，即满足ApplyTime指定场景时触发Job Run执行
扩展场景（含异常场景）
NA
约束
NA
非功能需求