Skip to content

feat: implement search functionality in configuration components and update UI#5168

Merged
Soulter merged 1 commit intomasterfrom
feat/search-config
Feb 17, 2026
Merged

feat: implement search functionality in configuration components and update UI#5168
Soulter merged 1 commit intomasterfrom
feat/search-config

Conversation

@Soulter
Copy link
Member

@Soulter Soulter commented Feb 17, 2026

Modifications / 改动点

  • This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果


Checklist / 检查清单

  • 😊 如果 PR 中有新加入的功能,已经通过 Issue / 邮件等方式和作者讨论过。/ If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  • 👀 我的更改经过了良好的测试,并已在上方提供了“验证步骤”和“运行截图”。/ My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  • 🤓 我确保没有引入新依赖库,或者引入了新依赖库的同时将其添加到了 requirements.txtpyproject.toml 文件相应位置。/ I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  • 😮 我的更改没有引入恶意代码。/ My changes do not introduce malicious code.

Summary by Sourcery

在配置界面中添加基于关键字的搜索功能,并将过滤逻辑应用到配置分组和配置项中。

New Features:

  • 在配置页面中新增搜索框,可按照关键字在所有配置分组和配置项中进行过滤。
  • 当当前搜索关键字没有匹配到任何配置分组时,显示一条提示信息。

Enhancements:

  • 优化配置选项卡的处理方式,以支持带键的分组,并在过滤结果变化时保持当前激活的选项卡同步更新。
  • 调整配置面板和输入控件的样式,以改善间距,并在小屏幕上提供更好的响应式布局。
Original summary in English

Summary by Sourcery

Add keyword-based search to the configuration UI and propagate filtering through configuration sections and items.

New Features:

  • Introduce a search field on the configuration page to filter configuration entries by keyword across sections and items.
  • Display an informational message when no configuration sections match the current search keyword.

Enhancements:

  • Refine configuration tab handling to work with keyed sections and keep the active tab in sync with filtered results.
  • Adjust configuration panel and input styling for better spacing and responsive layout on smaller screens.

@dosubot dosubot bot added the size:L This PR changes 100-499 lines, ignoring generated files. label Feb 17, 2026
@Soulter Soulter merged commit 6e22d26 into master Feb 17, 2026
5 checks passed
@dosubot
Copy link

dosubot bot commented Feb 17, 2026

Related Documentation

Checked 1 published document(s) in 1 knowledge base(s). No updates required.

How did I do? Any feedback?  Join Discord

1 similar comment
@dosubot
Copy link

dosubot bot commented Feb 17, 2026

Related Documentation

Checked 1 published document(s) in 1 knowledge base(s). No updates required.

How did I do? Any feedback?  Join Discord

Copy link
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - 我发现了 1 个问题,并留下了一些整体反馈:

  • 搜索逻辑目前分散在 AstrBotCoreConfigWrapper(使用 this.tm)和 AstrBotConfigV4(使用 translateIfKey)之间,这可能会导致在分区级过滤和条目级过滤之间出现不一致的匹配行为;建议将文本提取/标准化逻辑整合到一个共享的辅助函数中,以确保它们的行为完全一致。
  • AstrBotCoreConfigWrapper.visibleSections 中,sectionHasSearchMatch 在每次重新计算时都会遍历整个 section 的 metadata,并拼接成一个很大的字符串;如果 metadata 体量较大,你可能需要为每个 section 缓存或预先计算可搜索字符串,以避免每次敲键都重复做相同的工作。
给 AI Agent 的提示词
Please address the comments from this code review:

## Overall Comments
- Search logic is split between `AstrBotCoreConfigWrapper` (using `this.tm`) and `AstrBotConfigV4` (using `translateIfKey`), which may lead to inconsistent matching behavior between section-level and item-level filtering; consider consolidating the text extraction/normalization into a shared helper to ensure they behave identically.
- In `AstrBotCoreConfigWrapper.visibleSections`, `sectionHasSearchMatch` walks the entire section metadata and builds a large joined string on every recompute; if metadata is large, you may want to cache or precompute searchable strings per section to avoid repeated work on every keystroke.

## Individual Comments

### Comment 1
<location> `dashboard/src/components/shared/AstrBotConfigV4.vue:167-168` </location>
<code_context>
   }
-  return true
+
+  const sectionItems = props.metadata?.[props.metadataKey]?.items || {}
+  const hasVisibleItems = Object.entries(sectionItems).some(([itemKey, itemMeta]) => shouldShowItem(itemMeta, itemKey))
+  return hasVisibleItems
 }
</code_context>

<issue_to_address>
**issue (bug_risk):** Section-level visibility with search can lead to tabs with no visible content when only the section-level metadata matches.

In `shouldShowSection`, requiring `hasVisibleItems` (via `shouldShowItem`, which applies search filtering) conflicts with the wrapper’s `visibleSections`, which already uses `sectionHasSearchMatch` on both section metadata and items. This means a section can be shown because its description/hint matches the keyword, but `shouldShowSection` still returns false when no items match, yielding an empty tab. To avoid this mismatch, either: (1) bypass the `hasVisibleItems` check when `searchKeyword` is non-empty and rely on the wrapper’s visibility decision, or (2) move the section-level search logic into this component and have the wrapper only manage tab selection.
</issue_to_address>

Sourcery 对开源项目是免费的——如果你觉得我们的 Review 有帮助,欢迎分享 ✨
帮我变得更有用!请在每条评论上点 👍 或 👎,我会根据你的反馈改进后续的 Review。
Original comment in English

Hey - I've found 1 issue, and left some high level feedback:

  • Search logic is split between AstrBotCoreConfigWrapper (using this.tm) and AstrBotConfigV4 (using translateIfKey), which may lead to inconsistent matching behavior between section-level and item-level filtering; consider consolidating the text extraction/normalization into a shared helper to ensure they behave identically.
  • In AstrBotCoreConfigWrapper.visibleSections, sectionHasSearchMatch walks the entire section metadata and builds a large joined string on every recompute; if metadata is large, you may want to cache or precompute searchable strings per section to avoid repeated work on every keystroke.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- Search logic is split between `AstrBotCoreConfigWrapper` (using `this.tm`) and `AstrBotConfigV4` (using `translateIfKey`), which may lead to inconsistent matching behavior between section-level and item-level filtering; consider consolidating the text extraction/normalization into a shared helper to ensure they behave identically.
- In `AstrBotCoreConfigWrapper.visibleSections`, `sectionHasSearchMatch` walks the entire section metadata and builds a large joined string on every recompute; if metadata is large, you may want to cache or precompute searchable strings per section to avoid repeated work on every keystroke.

## Individual Comments

### Comment 1
<location> `dashboard/src/components/shared/AstrBotConfigV4.vue:167-168` </location>
<code_context>
   }
-  return true
+
+  const sectionItems = props.metadata?.[props.metadataKey]?.items || {}
+  const hasVisibleItems = Object.entries(sectionItems).some(([itemKey, itemMeta]) => shouldShowItem(itemMeta, itemKey))
+  return hasVisibleItems
 }
</code_context>

<issue_to_address>
**issue (bug_risk):** Section-level visibility with search can lead to tabs with no visible content when only the section-level metadata matches.

In `shouldShowSection`, requiring `hasVisibleItems` (via `shouldShowItem`, which applies search filtering) conflicts with the wrapper’s `visibleSections`, which already uses `sectionHasSearchMatch` on both section metadata and items. This means a section can be shown because its description/hint matches the keyword, but `shouldShowSection` still returns false when no items match, yielding an empty tab. To avoid this mismatch, either: (1) bypass the `hasVisibleItems` check when `searchKeyword` is non-empty and rely on the wrapper’s visibility decision, or (2) move the section-level search logic into this component and have the wrapper only manage tab selection.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment on lines +167 to +168
const sectionItems = props.metadata?.[props.metadataKey]?.items || {}
const hasVisibleItems = Object.entries(sectionItems).some(([itemKey, itemMeta]) => shouldShowItem(itemMeta, itemKey))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): 带搜索的分区级可见性在只有 section 元数据匹配时,可能会导致标签页中没有可见内容。

shouldShowSection 中,通过 hasVisibleItems(经由 shouldShowItem,会应用搜索过滤)来做要求,这与 wrapper 中已经在使用的 visibleSections 存在冲突,后者会在 section 元数据和 items 上同时使用 sectionHasSearchMatch。这意味着,一个 section 可能因为其描述/提示文本匹配了关键词而被显示,但如果没有任何 item 匹配,shouldShowSection 仍然返回 false,最终得到的是一个空标签页。为避免这种不一致,你可以: (1) 在 searchKeyword 非空时跳过 hasVisibleItems 检查,并依赖 wrapper 的可见性判断,或者 (2) 将分区级的搜索逻辑移动到当前组件中,让 wrapper 只负责标签页的选择。

Original comment in English

issue (bug_risk): Section-level visibility with search can lead to tabs with no visible content when only the section-level metadata matches.

In shouldShowSection, requiring hasVisibleItems (via shouldShowItem, which applies search filtering) conflicts with the wrapper’s visibleSections, which already uses sectionHasSearchMatch on both section metadata and items. This means a section can be shown because its description/hint matches the keyword, but shouldShowSection still returns false when no items match, yielding an empty tab. To avoid this mismatch, either: (1) bypass the hasVisibleItems check when searchKeyword is non-empty and rely on the wrapper’s visibility decision, or (2) move the section-level search logic into this component and have the wrapper only manage tab selection.

@dosubot dosubot bot added the area:webui The bug / feature is about webui(dashboard) of astrbot. label Feb 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:webui The bug / feature is about webui(dashboard) of astrbot. size:L This PR changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

Comments