Title:
Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
qs vulnerable to Prototype Pollution

Description:
qs before 6.10.3, as used in Express before 4.17.3 and other products, allows attackers to cause a Node process hang for an Express application because an __ proto__ key can be used. In many typical Express use cases, an unauthenticated remote attacker can place the attack payload in the query string of the URL that is used to visit the application, such as a[proto]=b&a[proto]&a[length]=100000000. The fix was backported to qs 6.9.7, 6.8.3, 6.7.3, 6.6.1, 6.5.3, 6.4.1, 6.3.3, and 6.2.4 (and therefore Express 4.17.3, which has "deps: [email protected]" in its release description, is not vulnerable).

Support automate version bump in https://github.com/opensearch-project/opensearch-build

Mingshi is a new contributor and will be working to help release this repo into 2.5.0 so she is being added as a maintainer. Congrats Mingshi!

• Add to CODEOWNERS team
• Add to MAINTAINERS.md

• Create an Onboarding Issue for Plugin: opensearch-project/opensearch-build#2785
• Repository Live and Public https://github.com/opensearch-project/dashboards-search-relevance
• Conventions Verified: https://github.com/opensearch-project/opensearch-plugins/blob/main/CONVENTIONS.md
• Complete onboarding: https://github.com/opensearch-project/opensearch-build/blob/main/ONBOARDING.md
• commit waiting for correct branches in source to create PR: opensearch-project/opensearch-build@main...macohen:opensearch-build:main
  -[ ] dependabot, whitesource, codecov integration
• Security Review

As part of the discussion around implementing an organization-wide testing policy, I am visiting each repo to see what tests they currently perform. I am conducting this work on GitHub so that it is easy to reference.

Looking at the Dashboards Search Relevance repository, it appears there is

I don't see any requirements for code coverage in the testing documentation. If there are any specific requirements could you respond to this issue to let me know?

If there are any tests I missed or anything you think all repositories in OpenSearch should have for testing please respond to this issue with details.

Title:
glob-parent before 6.0.1 and 5.1.2 vulnerable to Regular Expression Denial of Service (ReDoS)
Inefficient Regular Expression Complexity
glob-parent 6.0.0 vulnerable to Regular Expression Denial of Service
Description:
glob-parent before 6.0.1 and 5.1.2 is vulnerable to Regular Expression Denial of Service (ReDoS). This issue is fixed in version 6.0.1 and 5.1.2.

The glob-parent package before 6.0.1 for Node.js allows ReDoS (regular expression denial of service) attacks against the enclosure regular expression.

glob-parent 6.0.0 is vulnerable to Regular Expression Denial of Service (ReDoS). This issue is fixed in version 6.0.1.

This vulnerability is separate from GHSA-ww39-953v-wcq6.

https://advisories.aws.barahmand.com/advisory/CVE-2021-35065

Summary

When building a product or full-text search based application in OpenSearch, careful consideration and thought needs to be put into building the index based on the data being ingested. Often, a document to be indexed is derived from several different sources (e.g. databases, tables, or files). In OpenSearch, the best practice is to denormalize this data into a single document. This proposal is to build tooling that inspects source data and generates a suggested OpenSearch index mapping file so that search application builders do not need to start from scratch and also do not need to default to dynamic mapping.

General Use Case

1. Upload a CSV, JSON document, or SQL query against a source
2. Optionally specify a primary or unique key
3. Mapping file generator then:
   4. sorts the data based on the key provided
   5. loops through X number of rows to generate a suggestion for mapping file including nested documents, datatypes,
   analyzers, and autosuggest.
4. Search Application Builder can take the mapping file and tweak/correct the mappings.

Questions

1. Is there an existing component, like data-prepper, that can be used to support this case?
2. Many organizations reuse datatypes, so we would want to learn from existing mappings. How can this be done?

Is your feature request related to a problem?

Current comparison tool only display text document, which is not very intuitive comparing search results. We propose to display pictures when a url is available.

What solution would you like?

See attachment for a mock up

What alternatives have you considered?

We could use greasemonkey script on client side to do the job, but it's not as easy.

Do you have any additional context?

Add any other context or screenshots about the feature request here.

Is your feature request related to a problem?

Yes. Results are limited to four lines of text governed by the width of the browser window. Many real-world documents are much larger than that.

What solution would you like?

I would like some way of viewing the full source of a document (or at least the full set of returned fields and their values).

What alternatives have you considered?

I think any expansion should involve a small UI element (e.g. a rotating arrow or an "expand" icon), to preserve the existing "compact" feel. I would like to be able to expand individual results (rather than needing to expand all results).

1. We could add an icon that shows modal popover with the full document source.
2. Add an icon that toggles "expansion" of a given result, where the result would be given enough vertical space to show the full document.

Do you have any additional context?

Add any other context or screenshots about the feature request here.
TODO

This is a component issue for 2.6.0.
Coming from opensearch-build__3081__. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.6.0.

CI/CD

• All code changes for __2.6.0__ are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the __2.6__ release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for __2.6.0__ have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

Changelogs for each release make it easier to cut the release.

Is your feature request related to a problem?

Currently, the comparison tool only shows document source. Sometimes, though, I don't want to retrieve the whole document source because I have large text fields and vector fields. Also, sometimes I want to retrieve fields that are not available in source, but are available as doc values, stored fields, or are computed by a script.

What solution would you like?

The results shown in the comparison tool should include fields from the fields property of each document. I would suggest that the result object first be populated with fields from the source (if available), then overlay the field values from the fields property -- if a field is available in both source and fields, the value in fields should overwrite the value in source.

What alternatives have you considered?

We can limit the set of fields returned using the _source parameter in the search request, but that doesn't cover the cases where a field is not available in the source (but may be in doc values, a stored field, or be computed with script_fields).

Do you have any additional context?

No

Is your feature request related to a problem?
Following a problem in another plugin (opensearch-project/opensearch-build#2043), and coming from opensearch-project/opensearch-build#58, there's no automated testing that this plugin runs as part of the OpenSearch distribution.

What solution would you like?
Run integration tests as part of the distribution.

A bit different from the OpenSearch Gradle IntegTest, the cypress test on dashboards need to be added to https://github.com/opensearch-project/opensearch-dashboards-functional-test

What/Why

What are you proposing?

In order to maintain high standards on this project, I propose that we set the unit test coverage target to 80% because we are starting with 80% coverage now and a threshold of 2% (effectively making our target to fail a build at 78% coverage. CodeCov docs are here: https://docs.codecov.com/docs/github-3-customizing-codecov. I'll submit a PR that should close this issue.

What users have asked for this feature?

None

What problems are you trying to solve?

Maintaining technical standards and setting a bar for builds.

Are there any security considerations?

No

Are there any breaking changes to the API

No

Introduction

As part of our continued efforts to improve OpenSearch Dashboards, we are planning to upgrade the underlying Node.js version from v14 to v18. This change will enhance performance, add new features, and bolster security. However, such major version changes might also affect the compatibility of existing plugins. Here is more introduction: opensearch-project/OpenSearch-Dashboards#3601.

Therefore, we kindly request assistance in testing this plugin the compatibility of with this new version of Node.js. We've prepared a branch with the Node.js v18 upgrade, which you can find here:
https://github.com/AMoo-Miki/OpenSearch-Dashboards/tree/node-18-webpack-4

Steps to Proceed

• If you think your plugin won't be affected by OpenSearch Dashboards Node.js upgrade. Pls ignore the rest steps and close the issue directly.
• Pull the provided branch that includes the Node.js v18 upgrade and OpenSearch 3.0.0.
• Hook up your plugin with the updated OpenSearch Dashboards.
• Run your existing test suites and perform manual testing as necessary.
• If no issues are encountered, feel free to close this issue.
• If there are any problems, report them in this issue thread and also link them in the overall OpenSearch Dashboards Node.js upgrade issue thread opensearch-project/OpenSearch-Dashboards#4058
  The purpose of linking any questions or issues back to the main issue is to maintain visibility and transparency among all plugin owners. A problem encountered by one plugin might also affect others. This shared knowledge base will foster collaborative problem-solving and prevent duplication of effort.

We appreciate your support and cooperation in ensuring a smooth transition to Node.js v18 for the entire OpenSearch Dashboards community.

We need to integrate something like https://github.com/opensearch-project/observability/blob/main/.github/workflows/dashboards-observability-test-and-build-workflow.yml for this project. It should go into https://github.com/opensearch-project/dashboards-search-relevance/.github/workflows/

Coming from opensearch-project/opensearch-plugins#95, add Windows support.

• Passing CI on Windows
• Documentation

What/Why

What are you proposing?

I believe that the comparison tool is stable and have no immediate plans to make changes to it. IMO, we should remove the experimental tag from the tool in an upcoming release.

What problems are you trying to solve?

We should try to minimize the amount of time anything is considered experimental.

What is the developer experience going to be?

None

Are there any security considerations?

No

Are there any breaking changes to the API

No

What is the user experience going to be?

I believe the "Experimental Feature" label should be removed, but the box it's in with the description, link to documentation, and forum should remain. https://searchapps.playground.opensearch.org/app/searchRelevance#/.

Are there breaking changes to the User Experience?

No

Why should it be built? Any reason not to?

Experimental features are meant for features that are not ready for production due to potential API changes or performance concerns. This feature has neither of those concerns.

What will it take to execute?

• Replace the title attribute for the EuiCallOut component in public/components/common/header.tsx with "Description" or something else. Make sure the tests pass.
• Update documentation to remove the experimental status https://opensearch.org/docs/latest/search-plugins/search-relevance/index/

What is the bug?

The 2.x branch and 2.6 branches are diverged.

The most updated commit on 2.x after 1eb4994 is 98d9b8d. But on 2.6 it's 7b992b1

How can one reproduce the bug?

Not applicable.

What is the expected behavior?

All commits to minor branch should go to 2.x first.

What is your host/environment?

Not applicable.

Do you have any screenshots?

Not applicable.

Do you have any additional context?

There are two potential ways to fix it

1. Reset 7b992b1 on 2.6, Reset 1eb4994 on 2.x, create new PR same as 7b992b1 to 2.x and then cherry pick parent of 1eb4994 on 2.x, then backport the new PR to 2.6
2. Reset 1eb4994 on 2.x, cherry-pick 7b992b1 and 1eb4994 on 2.x.

Note: both approachs will create new commit ids since it's backporting after branch cut. Example noCharger@14c05dc

Follow opensearch-project/.github#125 to baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions.

Close this issue when:

1. MAINTAINERS.md has the correct list of project maintainers.
2. CODEOWNERS exists and has the correct list of aliases.
3. Repo permissions only contain individual aliases as collaborators with maintain rights, admin, and triage teams.
4. All other teams are removed from repo permissions.

If this repo's permissions was already baselined, please confirm the above when closing this issue.

Need UX and product input to define what's attractive demo page

Example
https://reinvent.playground.opensearch.org/app/dashboards#/view/084aed50-6f48-11ed-a3d5-1ddbf0afc873?_g=(filters:!(),refreshInterval:(pause:!f,value:900000),time:(from:'2022-11-22T05:28:45.013Z',to:'2022-11-29T05:28:54.583Z'))&_a=(description:'Analyze%20mock%20global%20orders%20and%20revenue%20from%20Multiple%20Data%20Sources',filters:!(),fullScreenMode:!f,options:(hidePanelTitles:!f,useMargins:!t),query:(language:kuery,query:''),timeRestore:!t,title:'%5BMultiple%20Data%20Sources%5D%20Global%20Revenue%20Dashboard',viewMode:view)

OpenSearch Relevancy Workbench

1. Summary

Relevancy Workbench is an OpenSearch Dashboards plugin that comprises of different components: Query Explorer, Rules Manager and Search Analytics. These components allow search relevancy engineers to make their query results more accurate, contextual and relevant.

1.1 Target User:

Search Relevance Engineers who want to create a good search experience for their end-users, by providing them with relevant search results. Also, they want to dive deeper into search analytics like top search queries, top clicks and top queries without result.

1.2 Glossary:

• Search App: An OpenSearch Dashboards UI that allows user to put in a search query, add filters and see results.
• Querqy rewriter types (Details here):
  • Common rules
  • Replace
  • Word-break
  • Number-unit
• PPL Query: OpenSearch Piped Processing Language Details here.

2. Query Explorer

OpenSearch search relevance engineers create and test different DSL queries and Querqy queries for their search app. Query Explorer enables these developers to test these queries and rules.

2.1 Functional requirements

1. Users should be able to see all the Search Apps created, filter them by name and sort them by date modified/date created.
2. Users should be able to create/modify/clone/delete Search Apps.
3. Users should be able to add/edit tags and description for their Search Apps.
4. Users should be able to configure index name used for their Search Apps.
5. Users should be able to configure DSL/Querqy queries used for their Search Apps.
6. Users should be able to preview search results during configuration.
7. In Edit mode, Users should be able to add filters (similar to e-commerce sites) in their Search Apps.
8. In Edit mode, Users should be able to move around filters, search bars and results table.
9. In View mode, Users should be able to type a search query in the search bar and see the search results with all selected filters applied.
10. In View mode, Users should be able to click on each result row to see a detailed view of the selected result.
11. Users should be have the option to allow or not allow the capturing clicks, search queries, results, filters for search analytics.
12. Users should be able to visually compare two result sets.
13. Users should be able to analyze difference in two result sets (permutation metrics).
14. Users should be able to save search test sets.
15. Users should be able to view which Querqy rules were applied along side the query explain functionality.

2.2 Non-Functional requirements

1. The Search App should adhere to all security checks based on tenants, user roles, and permissions.
2. The search queries should be made based on the user roles and permissions.
3. The search queries should have proper circuit breakers, for all search requests made.

3. Rules Manager

Rules Manager allows search relevance engineers to manage querqy rules.

3.1 Functional requirements

1. Users should be able to view all Rules created, filter them by name and sort them by date modified/date created and by rewriter type.
2. Users should be able to create rules for all types of Querqy Rewriters.
3. Users should be restricted from creating two or more rules with the same name.
4. Users should be able to modify/clone/delete rules.
5. Users should be able to view rule contents.
6. Users should be able to add and edit rules using assisted rule table UI.
7. Users should be able to add and edit the rule in a code editor UI.
8. Users should be able to save the rules in the Querqy OpenSearch Index.
9. Users should be able to reload, rename, clone, delete rule while viewing it.
10. Users should be able to view help text/docs on the Querqy Rewriters type while creating/editing a rule.

3.2 Non-Functional requirements

1. The Search App should adhere to all security checks based on user roles, and permissions.

4. Search Analytics

Search Analytics allows search relevance engineers to view summaries of interactions (clicks, search queries, etc) on different search apps.

4.1 Functional requirements

1. Users should be able to view aggregated analytics with data from all Search Apps.
2. Users should be able to filter the analytics view by search app name, tags using PPL Query.
3. Users should be able to filter the analytics view by time interval.
4. Users should be able to see total number of queries, total number of queries with no results, total result-clicks in the analytics, stats on ranks of clicks.
5. Users should be able to see graphs for total queries, queries without results per hour/day/month (based on time interval selected by user).
6. Users should be able to see tables of top queries, top queries with no results.

4.2 Non-Functional requirements

1. The Search Analytics should adhere to all security checks based on tenants, user roles, and permissions.
2. The search queries should be made based on the user roles and permissions.
3. The search queries should have proper circuit breakers, for all search requests made.

5. Future Work

1. Add a query evaluation tool for offline testing with golden queries.
2. Allow users to make a pipeline based configuration for request/response intercepts in Search Apps.
3. Support for 2+ pipelines in a single UI for request/response configs with interleaving results.

6. Appendix

6.1 Related Issues:

1. opensearch-project/search-processor#1
2. opensearch-project/search-processor#2

6.2 References:

1. Querqy Docs: https://docs.querqy.org/querqy/index.html
2. SMUI (Querqy Search Management UI): https://docs.querqy.org/smui/index.html
3. Chorus tools playlist: https://www.youtube.com/watch?v=aoWx7KJzvCs&list=PLCoJWKqBHERvkhDoH1JBWfUxjj0H_It5D
4. SMUI usage video:https://www.youtube.com/watch?v=iUFzS7k2OHQ
5. Quepid: https://quepid.com/

Description

Although config.ts is added at the top level of the plugin, it is not included in the construction artifact when using the command yarn plugin-helpers build. The current github testing workflows always get the source code through checkout. (see examples https://github.com/opensearch-project/dashboards-search-relevance/blob/main/.github/workflows/remote-integ-tests-workflow.yml#L72-L75 and https://github.com/opensearch-project/dashboards-search-relevance/blob/main/.github/workflows/test-and-build.yml#L22-L25). We should instead utilize build artifacts for integration testing.

What is the bug?

When creating a PR with "backport 2.x" or "backport 2.4" labels, the backport action succeeds, but the opensearch-trigger-bot sends e-mail that it failed with instructions:

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128
To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-30-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 61a7232068b72469263a2391b741bf86af5ed0ca
# Push it to GitHub
git push --set-upstream origin backport/backport-30-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x
Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-30-to-2.x.

How can one reproduce the bug?

Label a PR "backport 2.x", merge it to main.

What is the expected behavior?

Expected that the merge would be successful.

What is your host/environment?

N/A

Do you have any screenshots?

N/A

Do you have any additional context?

This is the first time we're running backport so there may be an issue with how we're using it.

The existing maintainers have voted and approved adding Sean Li (sejli) and Louis Chu (noCharger) as maintainers on this repo. Can you please add them to the maintainers list, @opensearch-project/admin?

During the 2.6.0 release, the Cypress tests for this repo (running from https://github.com/opensearch-project/opensearch-dashboards-functional-test/blob/main/cypress/integration/plugins/search-relevance-dashboards/1_query_compare.spec.js) failed because it was unable to create sample data (in the before() step), because the sample data had been created but not cleaned up by another test.

We should defend against other tests' bad behavior so that our tests don't break.

I think https://github.com/opensearch-project/opensearch-dashboards-functional-test/blob/main/cypress/integration/plugins/custom-import-map-dashboards/import_vector_map_tab.spec.js#L14-L15 may be a model that we can copy -- delete all indices before trying to add sample data to start with a clean slate.

We have informally said that coverage should not drop below 80%. We also have this .codecov.yml file which may not be working right: https://github.com/opensearch-project/dashboards-search-relevance/blob/main/.github/.codecov.yml.

We should also document our expectations for coverage in the readme.

Originally posted by @macohen in #152 (comment)

Add dashboards-search-relevance plugin to source code page: https://opensearch.org/source.html#

We are launching an experimental search results comparison UI and are looking for feedback on this feature so we can work with the community to make it better.

Release Version 2.5.0

This is a component issue for 2.5.0.
Coming from opensearch-build#2908. Please follow the following checklist.
Please refer to the DATES / CAMPAIGNS in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.5.0.
• Cut 2.5 branch

CI/CD

• All code changes for 2.5.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 2.5.0 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.5.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

[### What is the bug?]
Title:
Inefficient Regular Expression Complexity
Inefficient Regular Expression Complexity in chalk/ansi-regex
Description:
ansi-regex is vulnerable to Inefficient Regular Expression Complexity
ansi-regex is vulnerable to Inefficient Regular Expression Complexity which could lead to a denial of service.

(https://advisories.aws.barahmand.com/advisory/CVE-2021-3807)[

What/Why

What are you proposing?

Relevance engineers want to use different ranking techniques to deliver the best results for their users in search applications. This feature will allow users to see search results for a single user query using two different DSLs, including external rerankers, on the same OpenSearch Dashboard UI.

What users have asked for this feature?

Highlight any research, proposals, requests or anecdotes that signal this is the right thing to build. Include links to GitHub Issues, Forums, Stack Overflow, Twitter, Etc

What problems are you trying to solve?

Summarize the core use cases and user problems and needs you are trying to solve. Describe the most important user needs, pain points and jobs as expressed by the user asks above. Template: When <a situation arises> , a <type of user> wants to <do something>, so they can <expected outcome>. (Example: When searching by postal code, a buyer wants to be required to enter a valid code so they don’t waste time searching for a clearly invalid postal code.)

• As a search relevancy engineer, I need to eyeball the effect of making changes to a search configuration, on a set of queries, so that I can determine if one approach is better than another. Examples of such changes include:
  • Weighting different fields differently
  • Different stemming or lemmatization strategies
  • Comparing different re-ranking pipelines such as Kendra
  • Shingling

What is the developer experience going to be?

Does this have a REST API? If so, please describe the API and any impact it may have to existing APIs. In a brief summary (not a spec), highlight what new REST APIs or changes to REST APIs are planned. as well as any other API, CLI or Configuration changes that are planned as part of this feature.

• No REST API

Are there any security considerations?

Describe if the feature has any security considerations or impact. What is the security model of the new APIs? Features should be integrated into the OpenSearch security suite and so if they are not, we should highlight the reasons here.

• No security concerns. The UI is only executes searches against the currently configured OpenSearch backend.

Are there any breaking changes to the API

If this feature will require breaking changes to any APIs, ouline what those are and why they are needed. What is the path to minimizing impact? (example, add new API and deprecate the old one)

• No

What is the user experience going to be?

Describe the feature requirements and or user stories. You may include low-fidelity sketches, wireframes, APIs stubs, or other examples of how a user would use the feature via CLI, OpenSearch Dashboards, REST API, etc. Using a bulleted list or simple diagrams to outline features is okay. If this is net new functionality, call this out as well.

Are there breaking changes to the User Experience?

Will this change the existing user experience? Will this be a breaking change from a user flow or user experience perspective?

• No, this is a new feature.

Why should it be built? Any reason not to?

Describe the value that this feature will bring to the OpenSearch community, as well as what impact it has if it isn't built, or new risks if it is. Highlight opportunities for additional research.

• First step towards building a comprehensive search relevance evaluation system with the search relevance engineer in mind.

What will it take to execute?

Describe what it will take to build this feature. Are there any assumptions you may be making that could limit scope or add limitations? Are there performance, cost, or technical constraints that may impact the user experience? Does this feature depend on other feature work? What additional risks are there?

• The initial UI will be a simple step with the ability to see results from two different queries in the same window.
• We also must consider how this system will evolve to move from a manual, visual comparison tool to supporting automated multivariate testing. Automated multivariate testing will be considered in the architecture/API development, but it is out of scope for this proposal.

Any remaining open questions?

What are known enhancements to this feature? Any enhancements that may be out of scope but that we will want to track long term? List any other open questions that may need to be answered before proceeding with an implementation.

• Enhancements to this feature include:
  • Highlighting differences in result lists (e.g. highlighting results that do not appear in the other list).
  • Customizing result formatting.
  • Giving information on the relative rank of a result (e.g. showing the position in the other list).
• The bigger picture is that this is the first baby step in measuring search results. Future steps include:
  • Offline testing of a fixed list of searches for different algorithms.
    • Showing queries which have the most different result lists (by some statistical measure).
    • Saving judgement lists and calculating relevance statistics (e.g. nDCG)
  • Online evaluation of different algorithms using action statistics (clicks etc.)

What is the bug?

In the Results field of Search Relevance / Compare search results, the text wrapping is bizarre.

How can one reproduce the bug?

With the query {} on the sample_data_ecommerce index, the first result (with a certain window width) looks like this:

category: ["Men's
Clothing"] currency: EUR customer_first_name: Eddie customer_full_name :Edd
ie
Underwood customer_gender: MALE customer_id: 38 customer_last_name: Underwo

Three problems:

• line breaks only happen at spaces within value fields (and not between the field name and the value or the value and the next field name)
• the line is overflowing, leaving orphans like "ie" on a line by themselves
• (not shown in this example), there can be a linebreak between the field name and the following ":".

What is the expected behavior?

Result should be formatted like this:

category: ["Men's Clothing"] currency: EUR customer_first_name:
Eddie customer_full_name: Eddie Underwood customer_gender: MALE
customer_id: 38 customer_last_name: Underwood customer_phone: day_of_week:
Monday day_of_week_i: 0 email: [email protected] manufacturer:

What is your host/environment?

Chrome 107.0.5304.87 on macOS 12.6 Intel

Do you have any screenshots?

(I don't know why the colon after "category" is missing here -- I couldn't reproduce that.)

Do you have any additional context?

This is a component issue for 2.7.0.
Coming from opensearch-build#3230. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.7.0.

CI/CD

• All code changes for 2.7.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 2.7 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.7.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

What solution would you like?

We should add pagination and the ability to show how many results are on the page and how many results are returned by the query in the comparison UI

Do you have any additional context?

#55 is where this was suggested.

What is the bug?

Default tab spacing in the Query text box is 4 spaces. In dev tools, it is 2 spaces, which makes the query more compact and easier to see.

How can one reproduce the bug?

From the top-left hamburger menu go to “OpenSearch Plugins -> Search Relevance”. Enter a query in Query 1 or Query 2 text box.

What is the expected behavior?

Expect the same tab spacing as dev tools.

What is your host/environment?

Any

Do you have any screenshots?

Do you have any additional context?

Add any other context about the problem.

When a nightly build fails, a github action could open an issue for deeper investigation so we don't forget.

This action could handle that for us: https://github.com/jayqi/failed-build-issue-action

Hi,

Update your plugin information in the documentation website:
https://github.com/opensearch-project/documentation-website

Example AsyncSearch:
https://opensearch.org/docs/latest/search-plugins/async/index/

Thanks.

Is your feature request related to a problem?

Yes. When editing a query, the DSL can get pretty verbose. The query box seems to be sized for about 8 lines of query text.

Following the JSON convention of putting one property on each line and closing curly braces on their own line, it's really hard to fit a non-trivial query on screen, meaning I need to scroll.

What solution would you like?

I would like the query boxes to be expandable vertically. I think we should add a handlebar to adjust the space allocated to queries versus results.

What alternatives have you considered?

1. Could just make the query boxes bigger (but still fixed). I don't think this is the right solution, though, because once I'm done editing the queries, I do want to devote more screen real estate to the results.
2. Maybe the query boxes could be large, but "behind" the results. When one query box or the other has focus, they could be brought to the front and moved back when focus is lost.

Do you have any additional context?

The following screenshot shows the problem. The query on the left is 9 lines, while the one on the right is 22 lines.

What is the bug?

In Compare search results, "See some examples" gives an error when it shouldn't and doesn't show the Examples slide-out.

How can one reproduce the bug?

In the Compare search results page, click in the Query box (but don't enter any text), then click on "See some examples".
It gives the error "A query is required. Enter a query." and does not show the Examples slide-out.
Clicking on "See some examples" then does display the Examples slide-out.

What is the expected behavior?

It should not give an error, and it should show the slide-out.

What is your host/environment?

Chrome 107.0.5304.87 on macOS 12.6 Intel

Do you have any screenshots?

Not needed.

Do you have any additional context?

Any content in the Query field, even a single space or an invalid query, keeps this bug from happening.

Refactoring the dashboards-search-relevance plugin can provide several benefits, making the application more maintainable, scalable, and efficient. The primary purposes for refactoring the plugin are:

1. Improve code readability and maintainability: Refactoring helps in simplifying complex code structures and making them more readable. This ensures that other contributers can easily understand and maintain the codebase in the long run.

2. Enhance performance and optimization: By refactoring, contributers can identify and eliminate bugs, optimize code, and improve the app's overall performance. This ensures a better user experience and faster loading times.

3. Increase reusability and modularity and facilitate easier testing: Breaking down large components into smaller, reusable components enhances the modularity of the application. This makes it easier to manage, test, and scale the application in the future. For example, this index.ts has several functions that cannot be easily unit tested until they are modulated.

4. Adhere to best practices and design patterns: Refactoring helps in aligning the codebase with industry best practices and widely accepted design patterns. This ensures consistency, reduces the chances of bugs, and makes the codebase easier to work with for other contributers .

Overall, refactoring the dashboards-search-relevance app aims to make the application more efficient, maintainable, and scalable, providing a better experience for both developers and users.

What is the bug?

When the search button is pressed and a single search is performed, an error message appears saying "An index is required. Select an index."

How can one reproduce the bug?

1. Select index on either left or right hand side
2. Click search button

What is the expected behavior?

Three possibilities:

1. If a single search is not permitted, display an error message but do not execute the search.
2. If a single search is permitted, delete the error message.
3. If a single search is permitted, change the font color to black and display a recommendation wording such as "try comparing search results by selecting an index."

Do you have any additional context?

I would want to clarify the expected behavior.

Is your feature request related to a problem?

We are building QA summary based search using search pipeline. We want to use the search comparison tool to show the difference between that and normal searches. Can we add support to QA search into the comparison tool?

What solution would you like?

Basically we need to highlight the summarized answer and display the list of documents that used to summarize the answer. See attachment for details.
(to be updated)

What alternatives have you considered?

This could also be done via client side script but not as convenient.

Do you have any additional context?

Add any other context or screenshots about the feature request here.

What is the bug?

The backport delete action does not work because the action defined the label pattern to search for as "backport/" when we use "backport-"

Release Version 2.4.0

This is a component issue for 2.4.0.
Coming from opensearch-build#2649. Please follow the following checklist.
Please refer to the DATES / CAMPAIGNS in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.4.0. @macohen
• Cut 2.4 branch

CI/CD

• All code changes for 2.4.0 are complete. @mingkunm
• Ensure working and passing CI. @mingkunm
• #13

Pre-Release

• Update to the 2.4.0 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.4.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary. @mingkunm
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass. @mingkunm
• Sanity Testing: Sanity testing and fixing of critical issues found. @mingkunm
• File issues for all intermittent test failures. @mingkunm

Release

• Complete documentation. @kolchfa-aws
• Verify all issued labeled for this release are closed or labelled for the next release. @macohen

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version. @macohen
• Add this repo to the manifest of the next eventual security patch version. @macohen
• Suggest improvements to this template. @macohen
• Conduct a retrospective, and publish its results. @macohen

Add git action steps to run integration test

https://github.com/opensearch-project/opensearch-dashboards-functional-test/tree/main/cypress/integration/plugins/search-relevance-dashboards

What/Why

What are you proposing?

Add a metrics framework on dashboards-search-relevance by instrumentation.

What users have asked for this feature?

Will post the RFC/HLD.

What problems are you trying to solve?

A metrics framework can solve a number of problems related to monitoring and measuring the performance and behavior of dashboards-search-relevance plugin.

1. Lack of visibility: Without a metrics framework in place, it can be difficult to gain visibility into the behavior of an application. Metrics provide insights into how different components of an application are performing and how users are interacting with the application.
2. Difficulty in identifying bottlenecks: By monitoring metrics related to resource utilization, response times, and error rates, a metrics framework can help identify bottlenecks in an application that are affecting performance.
3. Inability to measure performance over time: Metrics collected over time can be used to create historical trends that can be used to understand how an application is performing over time, and how changes to the application are affecting performance.
4. Difficulty in identifying issues: Metrics can be used to identify issues that may be difficult to spot through other means. For example, a high error rate may indicate a problem that is affecting only a small number of users, but that could be having a significant impact on the overall user experience.
5. Lack of context: Metrics can be used to provide context around performance issues, allowing developers and operations teams to quickly identify the root cause of problems and take corrective action.

What is the developer experience going to be?

The new REST API /api/relevancy/stats returns all metrics of the dashboards-search-relevance plugin. Metrics will be used to monitor existing APIs such as /api/relevancy/search/indexes and /api/relevancy/search. Any future APIs can be seamlessly added by calling metricsService.addMetric. It will be configurable to setup the refresh time interval.

Are there any security considerations?

No security impact. All metrics are stored in memory. For metric persistence and visualization, OpenSearch or another monitoring framework can be used.

Are there any breaking changes to the API

To support multiple requests, the /api/relevancy/search URL has been changed to a batch API. This is a browser-side routing API.

What is the user experience going to be?

Users are able to call /api/relevancy/stats to view all metrics of the dashboards-search-relevance plugin.

Are there breaking changes to the User Experience?

No.

Why should it be built? Any reason not to?

The reason to build is mentioned here

The reason to not build:

Limited benefits: dashboards-search-relevance is quite small and simple, there are no significant performance or reliability issues, the benefits of building a metrics framework may be limited

What will it take to execute?

As of now, user behavior such as clicking is not covered. By exposing a new API endpoint, the same framework can be used.

Any remaining open questions?

No.

Example output:

% curl -XGET http://localhost:5603/hgn/api/relevancy/stats
{
  "data": {
    "relevant_search": {
      "fetch_index": {
        "200": {
          "sum": 12.02572301030159,
          "count": 1
        }
      },
      "single_search": {
        "200": {
          "sum": 4.898337006568909,
          "count": 1
        }
      }
    }
  },
  "overall": {
    "response_time_avg": 8.46203000843525,
    "requests_per_second": 0.03333333333333333
  },
  "component_counts": {
    "relevant_search": 2
  },
  "status_code_counts": {
    "200": 2
  }
}%   

Is your feature request related to a problem?

We want to make sure we have a way to easily identify issues that we haven't reviewed. By default new issues do get created with untriaged if created with a template, but this action should cover other use cases.

What solution would you like?

Add an action with the following...

name: Apply 'untriaged' label during issue lifecycle

on:
  issues:
    types: [opened, reopened, transferred]

jobs:
  apply-label:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v6
        with:
          script: |
            github.rest.issues.addLabels({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              labels: ['untriaged']
            })