在配置列表显示parent应用的配置

[kklldog]

现在如果 app1 继承自 app0 。在打开 app1 的配置列表的话，这里不能展示 app0 的配置，导致用户不能看到最终的配置列表。
建议做一个预览最终配置列表的功能。

[super-niuma-001]

感谢反馈，这个需求我先按实现角度做一个初步判断：

1. 是否可行

从描述上看，这类需求通常是有实现空间的，但还需要结合 AgileConfig 当前的数据模型、接口兼容性以及控制台交互方式进一步确认边界。

2. 对现有项目的影响

主要需要评估以下几点：

• 是否会影响现有配置读取/发布流程
• 是否会引入兼容性变化，尤其是已有客户端或接口行为
• 是否需要新增配置项、数据库字段或管理界面入口
• 是否会增加运维复杂度、权限控制成本或性能开销

3. 可行方案的简单描述

如果要推进，比较稳妥的方式通常是：

• 先明确具体使用场景和预期行为
• 再确定是扩展现有能力，还是增加独立开关/模块
• 尽量保持默认行为不变，通过可选配置或渐进式方式落地

如果方便的话，欢迎补充更具体的业务场景、预期效果，以及你希望如何使用这个能力，这样可以更准确地评估设计方案。

-- openclaw

[kklldog]

@super-niuma-001
请根据我的建议进行分析：

1. 添加一个checkbox用来指示是否显示上游配置
2. checkbox=true的时候，配置列表需要整合当前应用的配置与上游配置项目（已发布的）
3. checkbox=true的时候，同样影响 txt编辑与json编辑模式，但是即使删除，更新了上游配置，这些更改会忽略

[super-niuma-001]

@kklldog

我按你这 3 点重新收敛了一下，这个需求我建议定义成 “预览最终生效配置”，而不是把 parent 配置真的并入 child 的配置数据里。这样实现边界会清晰很多，也更符合你说的“删除时忽略上游变更”这个意图。

一、目标语义

当勾选 显示上游配置 后，页面展示的是一个计算出来的合并视图：

• 当前应用自己的配置（可编辑）
• 父应用已发布配置（只读参与预览）
• 如果 key 冲突，当前应用优先覆盖父应用

也就是说，这个 checkbox 打开后看到的是“最终视图”，不是把上游配置复制到当前应用。

---

二、列表页建议怎么做

你给的方向我认可，列表页可以这样落：

1）加一个 checkbox

文案可以直接叫：显示上游配置

默认不勾选，保持当前行为不变；勾选后走一个新的查询分支。

2）返回结构不要只是原始 ConfigEntity

建议接口返回一个“带来源信息”的 view model，而不是直接把数据库实体原样返回。至少补这几个字段：

• source：self / parent
• sourceAppId
• isInherited
• isOverridden
• editable

这样前端才能明确区分：

• 这条是当前应用自己的
• 这条是从 parent 继承来的
• 这条 parent key 已经被当前应用覆盖了

3）合并规则

后端合并建议：

1. 先查当前 app 在当前 env 下的配置
2. 再查 parent app 在当前 env 下的已发布配置
3. 按 group + key（如果系统里 key 唯一规则不同，就按实际唯一键）做 merge
4. 当前 app 有同名项时覆盖 parent 项
5. parent 独有项标记成 isInherited = true

这样得到的是一个稳定的“展示层结果”，不会改动现有存储模型。

---

三、删除/编辑语义，建议不要“静默忽略”

你第 3 点里说：

checkbox=true 时也影响 txt/json 编辑模式，但是即使删除，更新了上游配置，这些更改会忽略

我理解你的真实诉求是：

在 merged 视图里能看到上游配置，但不能因为用户在 child 里删了一下，就真的把 parent 配置删掉或固化成本地状态。

这个方向我同意，但我不建议做成“用户删了，保存时悄悄忽略”——这样体验上会有点迷惑。

我更建议：

列表模式

• self 项：正常编辑、删除
• parent 继承项：直接置灰 + 禁止删除/编辑
• 如果用户想覆盖 parent key，就走“新增同名 key 到当前应用”或“复制为本地项再编辑”这种显式动作

这样语义最稳：

• 继承项只是“可见”
• 真正可写的仍然只有当前应用自己的数据

---

四、txt/json 模式我建议分两步做

这里是我觉得最需要收住复杂度的地方。

第一阶段（更稳妥）

checkbox=true 时：

• txt/json 编辑器显示合并后的最终内容
• 但编辑器切成只读预览
• 页面给提示：当前为最终配置预览模式，包含上游已发布配置，不支持直接编辑

checkbox=false 时：

• 保持现在行为，只编辑当前应用自己的配置

这个版本最容易落地，也不会引入“保存时到底该写回哪些 key”的歧义。

第二阶段（如果后面一定要支持 merged 编辑）

如果以后一定要在 merged 模式下也允许编辑，那建议规则只能是：

• self 项可改
• parent 项只读
• 保存时只回写 self 子集

但这意味着 txt/json 编辑器里要能识别每一行属于 self 还是 parent，纯文本模式很难做得不混乱；JSON 模式也一样，除非把结构改成带 metadata 的格式，否则用户很难理解为什么删了某个 inherited key 保存后又回来。

所以我建议这期先不要把 merged txt/json 做成可编辑，先做成预览闭环。

---

五、后端接口建议

我建议不要污染现有查询接口，单独加一个“预览最终配置”的接口：

列表预览

GET /config/list-with-inheritance?appId=xxx&env=xxx&includeParent=true

返回合并后的列表 DTO。

txt/json 预览

再加一个面向编辑器的接口，例如：

• GET /config/txt-preview?appId=xxx&env=xxx&includeParent=true
• GET /config/json-preview?appId=xxx&env=xxx&includeParent=true

这两个接口本质上都是把合并结果序列化成不同展示格式。

这样不会破坏现有保存接口，也不会把“预览最终态”和“编辑当前态”搅在一起。

---

六、我建议的第一版范围

如果想先把价值尽快做出来，我建议第一版只做：

1. 配置列表页增加 显示上游配置 checkbox
2. 勾选后展示 当前配置 + parent 已发布配置 的合并结果
3. inherited 项明确标识来源，且只读
4. txt/json 模式支持“最终配置预览”，但先只读
5. 不做 inherited 项删除，不做 merged 编辑保存

这样这一版已经能解决 issue 里最核心的问题：

用户能看到最终会生效的配置长什么样

而且不会把数据写入语义搞复杂。

如果你认可这个收敛方向，下一步我可以继续把它细化成：

• 后端接口/DTO 设计
• 前端列表字段与状态交互
• txt/json 预览模式切换方案
• 哪些地方复用现有 published config 查询逻辑

reply-to-comment-id: 4229788922