Repository navigation
[Feature Request] Filter knowledge bases by availability status #43848
Description
Self Checks
- I have read the Contributing Guide and Language Policy.
- I have searched for existing issues search for existing issues, including closed ones.
- I confirm that I am using English to submit this report, otherwise it will be closed.
- Please do not modify this template :) and fill in all the required fields.
1. Is this request related to a challenge you're experiencing? Tell me about your story.
The Knowledge list can contain both available and unavailable knowledge bases. Unavailable knowledge bases are already shown as dimmed cards with an Unavailable badge, but users need to scan the list manually to find them.
Please add a Status filter to the Knowledge list with three options:
- Available: Show only available knowledge bases.
- Unavailable: Show only unavailable knowledge bases.
- All: Show knowledge bases regardless of availability. This should be the default.
This would help users quickly find usable knowledge bases or locate unavailable ones that need attention, especially in workspaces with many knowledge bases.
2. Additional context or comments
Place the Status filter alongside the existing tag filter and search field. It should work together with those controls and reflect the same availability status used by the knowledge base cards.
The current UI shows available and unavailable cards together, with no filter for this status.
Related availability-status bug report: #43847.
3. Can you help us with this feature?
- I am interested in contributing to this feature.
Activity
KevinAndrewDong commentedon Oct 12, 2026
I'd like to contribute the availability filter. Before starting, could we confirm the intended scope and its relationship with #43853?
My plan is to add All / Available / Unavailable to the knowledge-base list and apply the same availability rules used by the cards. Filtering would happen before pagination and totals, while preserving the existing workspace permissions, keyword search and tag matching. Omitting the new filter would keep current behavior.
Could you confirm whether this should initially cover the existing card list only, or also the new Knowledge list? Should the predicate include the embedding and reranker availability rules from #43853 once that work lands? I'd coordinate with that PR rather than duplicate its card/API changes.
Tests would cover matching datasets beyond the first page, accurate totals, combined filters and permissions, model configuration changes, and resetting frontend pagination when the filter changes. Availability would remain a configuration-state check, not a new live model health probe.
Is this a contribution you would welcome, and is anyone already working on the filtering portion?
leslie2046 commentedon Oct 12, 2026
@KevinAndrewDong Thanks for offering to contribute! A PR would be very welcome, and no one is currently working on the filtering portion.
I agree with your approach: the filter should reuse the existing availability status and follow the same rules as the knowledge-base cards. It should also incorporate the availability fixes from #43853, including the reranking model checks. Let's wait for that PR to land, then retest the filtering against the updated availability logic.
KevinAndrewDong commentedon Nov 2, 2026
Opened a PR for the Status filter: #45322
Implementation notes:
availability=all|available|unavailable(defaultall, so existing requests are unchanged). The filter runs in the same query as the page andtotal, before pagination, and composes with workspace permissions, keyword search, tags, creators and the existingidsfilter.embedding_available; it now lives in one shared function used by both the card flag and the filter, so a filtered list cannot disagree with the badge on a card. Availability stays a configuration-state check, not a live model health probe.Relation to #43853: this PR filters on the availability state cards expose on
maintoday and deliberately does not copy #43853's reranking card/API changes. Once #43853 lands, the reranking check should be folded into the shared availability predicate; I'm happy to rebase and retest the filter against the updated card logic then.feat(knowledge): filter knowledge bases by availability status