-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Attach] Allow semantic searching content node documents #11516
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand.
I thought we wanted to have one action per attached folders?
Is the intent here to allow searching in attached files? Aren't we supposed to change the isSearchable in the list files as well?
How will that work when we start allowing folders?
dataSourceViewId: f.nodeDataSourceViewId, | ||
filter: { parents: null, tags: null }, | ||
})); | ||
if (dataSourceView) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we rename this one to make it clear it's the conversation data source right?
.map((f) => ({ | ||
workspaceId: auth.getNonNullableWorkspace().sId, | ||
dataSourceViewId: f.nodeDataSourceViewId, | ||
filter: { parents: null, tags: null }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're taking the whole dataSourceView?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I should have the content node id as parent filter, thanks for noticing 👍
So, indeed, let me explain how I see it: Previous behaviour, before Attach project:
New behaviour, before folders: the same. New behaviour, after folders: the same:
As for listFiles, it doesn't need an update. Content nodes doc were already marked as searchable, but since we didn't add their datasourceview in the global semantic search action, they weren't included in that search (that's what this PR solves) |
const dataSources: DataSourceConfiguration[] = | ||
filesUsableAsRetrievalQuery | ||
.filter((f) => isConversationContentNodeType(f)) | ||
// For each searchable content node, we add its datasourceview with itself as parent filter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we could group by datasourceview here but not sure the gain (which seems ~0 to me) is worth the added LOCs and complexity
When you say:
It's more we can search no?
roger that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
yes, search indeed |
Fixes #2404
Description
As per title and issue.
Extracted from #11489 (cf comments)
Risks
standard
Deploy
front