Describe the bug
The following cypress test is flakey:

 1) Bucket-Level Monitors
       can be created
         by extraction query:
     AssertionError: Timed out retrying after 10000ms: Expected to find content: 'This table contains 1 row' but never did.
      at Context.eval (http://localhost:5601/__cypress/tests?p=cypress/integration/bucket_level_monitor_spec.js:319:10)

Should update the assertion to something more stable.

To Reproduce
Steps to reproduce the behavior:

1. Run yarn run cypress open or yarn run cypress run along with OpenSearch and OpenSearch dashboard in background. (Detailed instructions in README or documentation)
2. Check the "Bucket-Level Monitors can be created by extraction query" cypress test. If not failing, try a few more times.

Expected behavior
Will see the error AssertionError: Timed out retrying after 10000ms: Expected to find content: 'This table contains 1 row' but never did.

Host/Environment (please complete the following information):

• Version 1.1.0

Describe the bug
If a Monitor is created (at least with cron expression, did not check interval behavior) using the backend REST API, when going to the Edit Monitor page in the frontend plugin, the Monitor Schedule section displays the default of 1 minute interval. The cron information is actually being stored in the formik object derived from the Monitor object but it isn't the selected default. If the user ends up saving the Monitor without doing anything, the saved Monitor schedule will become the default of 1 minute.

To Reproduce
Steps to reproduce the behavior:

1. Create a Monitor with a cron schedule using the backend API
2. Go to Monitors page in the Alerting console
3. Select the Monitor to go to the Monitor details page
4. Select Edit
5. Scroll down to Monitor Schedule

Expected behavior
When creating a Monitor from the backend API, if the Monitor schedule is a cron expression, then default to the Custom cron expression display in the Edit Monitor page to ensure it can be shown regardless of the expression. May also need to test this with other schedule types to see if they behave correctly.

Screenshots
User reported this issue in a forum question which includes screenshots. The user was on the OpenDistro version of Alerting but this behavior has not been altered in OpenSearch and all new issues are being handled here.

Describe the bug
When creating a bucket-level monitor, the preview graph sometimes shows data out of the graph.

To Reproduce
Steps to reproduce the behavior:

1. Go to Create monitor page
2. Define a bucket-level monitor using sample flight data
3. Expand the preview graph section
4. See error

Expected behavior
Something like this screenshot

Host/Environment (please complete the following information):

• OS: macOS

Additional context
Add any other context about the problem here.

Describe the bug
Hello team! I've been running some tests to check if this Opendistro bug, is already fixed in Opensearch and, as far as I checked, it is not. I managed to replicate the same situation in Opensearch 1.2.0.
Also tried adding the monitor using the alerting API, and got the same result as the mentioned issue.

Having this said, is it an expected behavior or a known issue? Is there any workaround?
Are there any plans on adding this feature or fixing it?

To Reproduce
Steps to reproduce the behavior:

1. Enable Cross Cluster Search as explained here.
2. Try to create a monitor based on a remote cluster index.
3. You'll see only local indices from the coordinating cluster.

Expected behavior
Having the possibility of selecting all indices (from remote clusters and from the coordinating one).

Plugins
Default installation. No plugin added.

Screenshots
Remote index seen in Coordinating cluster:

Coordinating cluster indices only in Alerting:

Error after creating the monitor with the Alerting API:

Host/Environment (please complete the following information):

• Deployed using Docker running on Ubuntu 21.10
• Version: Opensearch 1.2.0

Additional context
Add any other context about the problem here.

There are many leftover constants names that have old references (OPENDISTRO-ALERTING-CONFIG, ES_AD_PLUGIN, etc.) These can be changed to reflect OpenSearch instead.

CVE-2021-3807 - High Severity Vulnerability

Vulnerable Libraries - ansi-regex-5.0.0.tgz, ansi-regex-3.0.0.tgz

ansi-regex-5.0.0.tgz

Regular expression for matching ANSI escape codes

Library home page: https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.0.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/ansi-regex/package.json

Dependency Hierarchy:

• cypress-6.9.1.tgz (Root Library)
  • cli-table3-0.6.0.tgz
    • string-width-4.2.2.tgz
      • strip-ansi-6.0.0.tgz
        • ❌ ansi-regex-5.0.0.tgz (Vulnerable Library)

ansi-regex-3.0.0.tgz

Regular expression for matching ANSI escape codes

Library home page: https://registry.npmjs.org/ansi-regex/-/ansi-regex-3.0.0.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/ansi-regex/package.json

Dependency Hierarchy:

• lint-staged-9.5.0.tgz (Root Library)
  • listr-0.14.3.tgz
    • listr-update-renderer-0.5.0.tgz
      • log-update-2.3.0.tgz
        • wrap-ansi-3.0.1.tgz
          • strip-ansi-4.0.0.tgz
            • ❌ ansi-regex-3.0.0.tgz (Vulnerable Library)

Found in HEAD commit: 7180f8ac0c662966536053af9bdb47ccd4fbd9ff

Found in base branch: main

Vulnerability Details

ansi-regex is vulnerable to Inefficient Regular Expression Complexity

Publish Date: 2021-09-17

URL: CVE-2021-3807

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://huntr.dev/bounties/5b3cf33b-ede0-4398-9974-800876dfd994/

Release Date: 2021-09-17

Fix Resolution (ansi-regex): 5.0.1

Direct dependency fix Resolution (cypress): 7.0.0

Fix Resolution (ansi-regex): 3.0.1

Direct dependency fix Resolution (lint-staged): 10.0.0-0

• Check this box to open an automated fix PR

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

• Passing CI on Windows
• Documentation

Creating a meta tracking issue for improving test coverage in general in the Alerting Dashboards plugin.

A couple things worth discussing in this issue correspondence is meaningful goals or milestones to help track progress (ie. what coverage % are we aiming for, what test cases do we want covered, gaps in components that need test coverage, etc.)

Describe the bug
Avoid monitors/_search api to fetch destination(s).

Expected behavior
Destinations UI flows much work without monitors_search api.

Plugins
alerting
alerting-dashboards

Screenshots
n/a

Host/Environment (please complete the following information):

• all

We are using Opensearch Dashboards as a central Point, where all Open Search Cluster Requests are going via Cross-Cluster-Search to external Hosts. Technically everything works as it should. Now we're facing the problem, that the Alerting monitor cannot access ccs indexes like "region-a:index_b-*". Even if we manually type it in the field, the following timestamp selector cannot find any dates.

Steps to reproduce the behavior:

1. Create CCS Cluster
2. Go to 'Alerting'
3. Click on 'Create Monitor'
4. Under "Define monitor" type an CCS Index like "region-a:index_b-*"

Expected behavior
The Monitor should list the ccs indexes with valid timestamp dates.

OpenSearch Version
1.0.0

Dashboards Version
1.0.0

Plugins

Default Plugins

Screenshots

Host/Environment (please complete the following information):

• Kubernetes 1.20
• Opensearch installed by HELM (Opensearch 1.0.7 - Opensearch Dashboards 1.0.4)

Is your feature request related to a problem? Please describe.
Currently, the details page for a monitor features 3 Edit monitor buttons that prompt users to create triggers when none are defined for the monitor. Pressing one of those buttons will link the user to the top of the edit monitor page. The user will then have to scroll down to the trigger definition panel.

Describe the solution you'd like
Add an anchor point to the edit monitor page that will cause the page to scroll directly to the trigger definition panel when an Edit monitor button is used from one of the create a trigger prompts.

CVE-2021-3918 - High Severity Vulnerability

Vulnerable Library - json-schema-0.2.3.tgz

JSON Schema validation and specifications

Library home page: https://registry.npmjs.org/json-schema/-/json-schema-0.2.3.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/json-schema/package.json

Dependency Hierarchy:

• cypress-6.9.1.tgz (Root Library)
  • request-2.88.5.tgz
    • http-signature-1.2.0.tgz
      • jsprim-1.4.1.tgz
        • ❌ json-schema-0.2.3.tgz (Vulnerable Library)

Found in HEAD commit: 7180f8ac0c662966536053af9bdb47ccd4fbd9ff

Found in base branch: main

Vulnerability Details

json-schema is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Publish Date: 2021-11-13

URL: CVE-2021-3918

CVSS 3 Score Details (9.8)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://nvd.nist.gov/vuln/detail/CVE-2021-3918

Release Date: 2021-11-13

Fix Resolution (json-schema): 0.4.0

Direct dependency fix Resolution (cypress): 7.0.0

• Check this box to open an automated fix PR

Coming from opensearch-project/project-meta#17

A Developer Certificate of Origin is required on commits in the OpenSearch-Project.

See doc.yml for an example workflow. Ensure CONTRIBUTING.md to has a section on the DCO per the project template.

• DCO Check Workflow
• CONTRIBUTING.md DCO Section

Is your feature request related to a problem? Please describe.
With the new single-page monitor creation experience, users must navigate the entire monitor definition page in order to edit or delete any of the monitor's triggers. That page can be cumbersome to navigate when a monitor is configured with multiple triggers, multiple actions per trigger, etc.

Describe the solution you'd like
Check boxes could be reimplemented in the Triggers table on the monitor details page which would support editing or deleting one trigger at a time, rather than scrolling through the entire monitor definition page. This feature could resemble the old monitor creation flow in which a trigger was defined on a separate page from the rest of the monitor components.

This feature could be expanded to support users selecting more than one trigger to edit/delete at a time.

Describe the bug
On alerts by triggers page, when acknowledging alerts from 1 trigger it only applies to the first 10 alerts.

To Reproduce
Steps to reproduce the behavior:

1. Create a bucket-level monitor with 10+ alerts in 1 trigger. (Try using sample ecommerce data with count of documents below 10000 over the past 3 days)
2. Click on Alerts tab
3. Select the trigger with more than 10+ alerts.
4. Click the "Acknowledge" button.
5. Should see that "Active" column only decreased by 10, and "Acknowledged" column only adds 10.

Expected behavior
All alerts within the trigger should be acknowledge. If error occurs, should show an error notification.

Screenshots
N/A

Host/Environment (please complete the following information):

• OS: [e.g. iOS]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
Currently the date math pattern in index names for the search query in the monitor input parameters is not allowed via the OSD dashboards. This support is available via the API calls (opensearch-project/alerting#74) for the monitor definition. Support in the OSD for date math pattern in the index names will make it easier to define the monitors using the indices with the date math pattern.

Describe the solution you'd like
Support to list and validate the Indices defined via the date math index pattern.

Describe alternatives you've considered
Able to create monitors for indices defined having the date math pattern via the APIs. However the support via the dashboard for the plugin would be a good addition.

Describe the bug

Noticed the same behavior for multiple alerts we are using. Alerts goes off, but can't find the data that triggered it anywhere. When we were using open distro we did not encounter these problems, although I now seperated the master / data nodes (3 master, 3 data. With open distro we were using 3 nodes that did everything).

Definiton and graph showing 0 results

Yet, history shows red:

Data:

no data present (look at index names, nothing matching the prd indexes)

To Reproduce
See above

Expected behavior
No alerts when there is no data present that matches the rules

OpenSearch Version
1.0.0

Dashboards Version
1.0.0

Plugins

Default docker image

Screenshots

Host/Environment (please complete the following information):
Kubernetes

Additional context

Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
Mustache templates (http://mustache.github.io) has different implementation in different programming languages, and the way of rendering may vary except for those are defined in the official manual (http://mustache.github.io/mustache.5.html).

The Mustache templates in the "message preview" of an Action in Alerting Dashboards plugin is rendered by JavaScript implementation (https://github.com/janl/mustache.js/).
While in the actual message, the Mustache templates is rendered in Java (https://github.com/spullara/mustache.java), which is encapsulated in OpenSearch, and the message is sent out through OpenSearch.

Describe the solution you'd like
One attempted solution is captured in opendistro-for-elasticsearch/alerting-kibana-plugin#205, however it did not seem ideal so further discussion may be required. Ideally the user should be able to preview the Mustache message as close to what they will actually be receiving without any syntax/variable issues between the two.

Coming from opensearch-project/opensearch-plugins#96, add MacOS (Darwin) support.

• Passing CI on MacOS
• Documentation

Is your feature request related to a problem? Please describe.

If I destroy my cluster I need to recreate the alerts by hand

Describe the solution you'd like

I want to export alerts and import them on another cluster through the GUI

Describe alternatives you've considered

Using the api, but I find that a bit difficult

Additional context

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

Describe the bug

The mustache preview of ctx.results[0].hits.hits is broken and will not be displayed in the message preview.

To Reproduce
Steps to reproduce the behavior:

1. Go to Alerting and open a query with the method Extraction query editor
2. Add a sample query
3. Scroll down to 'Actions'
4. Add sample values

Monitor {{ctx.monitor.name}} just entered alert status. Please investigate the issue.
  - Trigger: {{ctx.trigger.name}}
  - Severity: {{ctx.trigger.severity}}
  - Period start: {{ctx.periodStart}}
  - Period end: {{ctx.periodEnd}}

{{#ctx.results[0].hits.hits}}
{{_source.summary.up}}
{{/ctx.results[0].hits.hits}}

The upper 4 values will be previewed if set. The results part will NOT be previewed. If one sends a test email the contents will be correct.

Expected behavior
The contents of the results will be previewed correctly.

OpenSearch Version
Docker 1.1.0

REPOSITORY                                TAG            IMAGE ID       CREATED         SIZE
opensearchproject/opensearch              1.1.0          6394bbe93612   6 weeks ago     835MB

Dashboards Version
Docker 1.1.0

REPOSITORY                                TAG            IMAGE ID       CREATED         SIZE
opensearchproject/opensearch-dashboards   1.1.0          ce0ea078fdfb   6 weeks ago     897MB

Plugins

Default

Screenshots

Additional context

None

Describe the bug

1. Trigger-specific alerts flyout displaying all alerts for a monitor.
2. Trigger-specific alerts flyout displaying incorrect source for the condition field.
3. Trigger-specific alerts flyout displaying incorrect severity.
4. Combobox popovers in the query definition panel of the monitor creation page are erroneously generating error messages that are preventing preview graphs from illustrating data.
5. When all docs in an index contain the same value for the time field, the preview graph does not illustrate the data.
6. Missing periods in some error messages.
7. Query data not displaying properly in preview graph for bucket-level monitors.
8. A floating comma is rending after the first preview graph for bucket-level monitors.
9. Acknowledge button on trigger-specific alerts flyout and monitor details page does not support acknowledging multiple alerts.
10. Acknowledge action on Monitors tab is failing silently when more than 2 monitors are selected.
11. Monitors tab is not displaying active, acknowledge, error, etc. counts.

To Reproduce
Steps to reproduce the behavior:
Bug 1. When a monitor has multiple triggers with alerts, view the flyout for one of those triggers on the Alerts by trigger dashboard.
Bug 2. When a monitor has multiple triggers, view the flyout for any of those triggers on the Alerts by trigger dashboard except the first trigger that was defined.
Bug 3. When a monitor has multiple triggers, view the flyout for any of those triggers on the Alerts by trigger dashboard except the first trigger that was defined.
Bug 4. When defining the Data filter fields on the monitor creation query panel, inputting empty values results in errors when ideally the field shouldn't save at all. These errors cause the preview graph to display Invalid input in data filter. Remove data filter or adjust filter.
Bug 5. When all docs in an index contain the same value for the time field, the preview graph does not illustrate the data. Create an index, and upload docs to it with a time field (e.g., timestamp) that contain the same value. Creating a monitor for that index that uses that time field results in a blank preview graph.
Bug 6. Attempt to define a trigger that has the same name as another trigger associated with that monitor, or without a name. The error messages displayed under the name field will not end with periods.
Bug 7. Create a bucket-level monitor with multiple metrics, and at least 1 group by option. The preview graphs generated will appear to be the same.
Bug 8. Create a bucket-level monitor with at least 1 group by option. The floating comma will appear right under the preview graph.
Bug 9. Create a bucket-level monitor and trigger that generates multiple alerts. Select more than one of those alerts on either the trigger-specific flyout or the monitor details page. The acknowledge button will be disabled when more than 1 alert is selected.
Bug 10. Create multiple monitors with triggers that generate alerts. Select more than 1 monitor on the Monitors tab, and select the Acknowledge option from the Actions dropdown. The modal to acknowledge alerts for monitors will not appear when more than 1 monitor is selected. Inspecting the page reveals that the API call failed without notifying the user.
Bug 11. Create 1+ monitors with triggers that generate alerts. The active, acknowledge, error, etc. counts on the Monitors tab will display 0, and the Last notification time field will be blank.

Expected behavior
A clear and concise description of what you expected to happen:
Bug 1. The flyout should only display the alerts generated by that trigger.
Bug 2. The flyout should display the trigger condition for that trigger.
Bug 3. The flyout should display the severity for that trigger.
Bug 4. The query should not filter any data if the filter value field is undefined.
Bug 5. The preview graph should illustrate the data despite the time field values being the same.
Bug 6. Error messages should end with periods.
Bug 7. The preview graphs should accurately illustrate the data associated with their metric.
Bug 8. There should be a floating comma rending on the page.
Bug 9. Support for acknowledging more than 1 alert at a time would be more convenient.
Bug 10. If the option to acknowledge more than 1 monitor at a time is available, it should provide some feedback if it fails.
Bug 11. Accurate counts and values should be displayed in the table.

Plugins

1. Alerting dashboard
2. Alerting

Screenshots
If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: IOS
• Version 10.15.7

Additional context
Add any other context about the problem here.

https://discuss.opendistrocommunity.dev/t/cannot-create-trigger-from-anomaly-detector-requesttimeout/4832

Alerting create AD trigger page will call preview detector API to get sample anomaly results and detector feature configuration. The preview API may not work for some cases

1. If preview detector API timeout or throw error, AD trigger page can’t get any data, then it will show this warning “No features have been added to this anomaly detector. A feature is a metric that is used for anomaly detection. A detector can discover anomalies across one or more features.”. The message is not so accurate for such case as detector have features but just failed to call preview API.

2. When add AD trigger, alerting frontend will call preview API with last 5 days data. And preview API needs 400+ data points to generate sample anomaly results. If the anomaly detector interval is too big or there is no enough data in last 5 days, then preview API won’t return anything, then we will see this error message.

We need to tune the error message.

Coming from opensearch-build#652, onboard this plugin to the OpenSearch Dashboards 1.1.0 manifest. See opensearch-build#652 and onboarding for more details.

This is a component issue for release 2.0.0 (RC1).

Coming from opensearch-project/opensearch-build#1624, please refer to the dates in that post.

Please also follow the following checklist.

You can find all the date in above issue

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.0.0.

CI/CD

• All code changes for 2.0.0 are complete.
• Ensure working and passing CI.
• Re(add) this repo to the (if not exist) opensearch-dashboards input manifest.

Pre-Release

• Update your branch in the opensearch-dashboards input manifest.
• Confirm that all changes for 2.0.0 have been merged.
• Complete integration tests, and update results in the comment, example.
• Find/fix bugs using latest tarball and docker image provided in meta issue.
• Completed release candidate testing build #TBD.
• All intermittent test failures have issues filed.

Release

• Complete documentation.
• Gather, review and publish release notes.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Create a release tag.
• Suggest improvements to this template.
• Conduct a retrospect, and publish its results.

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Currently, when changing from a query-level to a bucket-level monitor, or vise versa, trigger definitions are not cleared. ClusterMetrics monitors introduces logic here that displays a model, when changing the request type, that gives users the option to clear triggers.

Introducing a similar modal when changing monitor type could be valuable. The modal could have options to clear triggers, keep triggers, or cancel the type change all together.

Describe alternatives you've considered
An alternative would be to clear the form automatically when changing request types as trigger conditions may not be supported by all monitor types.

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

When I get an alert I need to create a manual query to examine what the problem is what triggered the alert.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Add the query and the result that was done to the GUI and the mustache templates for actions. This saves a lot of time reverse engineering the query for the problem.

A clear and concise description of what you want to happen.

A clear and concise description of any alternative solutions or features you've considered.

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

Describe the bug
The default formik value for the Destination type in the 'Create Destination' page is Slack. So if the plugins.alerting.destination.allow_list setting is set to have only a single Destination type (which is not Slack), the dropdown for the type will default to a disallowed Destination type and the user will not the ability to change to another option and clear the invalid message.

To Reproduce
Steps to reproduce the behavior:

1. Set the Destination allow list to have on Destination that is not Slack
   Example:

PUT /_cluster/settings
{ 
  "persistent" : {
    "plugins.alerting.destination.allow_list" : "chime"
  }
}

2. Go to the 'Destinations' page on the Alerting Dashboards page
3. Click on 'Add Destination'
4. The Type dropdown will show that Slack is not allowed, with no other options to be able to choose from

Expected behavior
The values of plugins.alerting.destination.allow_list are used to populate the options for the Destination type dropdown. The formik default value should also account for this and use the allowed Destination type if there is only one available. If no Destinations are allowed, the dropdown should be disabled (effectively preventing a Destination from being created).

Additional context
This issue was created based on the this issue in the Open Distro repo for the Alerting Kibana plugin, some additional context can be found there.

Coming from opensearch-project/opensearch-plugins#92.

Each plugin has a short descriptive text blurb that says what it does: this appears in plugin-descriptor.properties (OpenSearch plugins) or package.json (OpenSearch Dashboards plugins), as well as on the project website's "source" page and in the "About" section of every repo. These were created one-by-one over the years as plugins were created, so looking at them all together now it would be hard for somebody new to the project to use these to understand what the plugins do.

Coming from opensearch-project/.github#21.

The correct copyright for open-source projects in opensearch-project is "Copyright OpenSearch Contributors". Please correct any places that say otherwise, especially where it says copyright Amazon. Make sure NOTICE.txt and README match. See opensearch-project/.github#24 for an example.

Is your feature request related to a problem? Please describe.
Currently, users are able to acknowledge all alerts only for a single trigger using the Alerts by trigger dashboard on the plugin landing page.

Describe the solution you'd like
Implement support for acknowledging alerts for more than one trigger at a time using the Alerts by trigger dashboard.

This is a component issue for release 1.1.1.
Coming from release issue 1.1.1, release version 1.1.1. Please follow the following checklist.

You can find all the date in above issue

Preparation

• Assign this issue to a release owner.
• 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 v1.1.1.

CI/CD

• All code changes for 1.1.1 are complete.
• Ensure working and passing CI.

Pre-Release

• Confirm that all changes for 1.1.1 have been merged.
• Complete integration and sanity tests, and update results in the comment, example.
• Find/fix bugs using latest tarball and docker image provided in meta issue.
• Completed release candidate testing build #TBD.
• All intermittent test failures have issues filed.

Release

• Complete documentation.
• Gather, review and publish release notes.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Create a release tag.
• Suggest improvements to this template.
• Conduct a retrospect, and publish its results.

This is a component issue for release 1.3.0.

Coming from opensearch-build#889, release version 1.3. Please follow the following checklist.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• Create, update, triage and label all features and issues targeted for this release with v1.3.0.

CI/CD

• Increment version on main to 1.3.0.0.
• Ensure working and passing CI.
• Re(add) this repo to the (if not exist) manifest.

Pre-Release

• Branch and build from a 1.3 branch.
• Update your branch in the manifest.
• Feature complete, pencils down.
• Fix bugs that target this release.

Release

• Complete documentation.
• Gather, review and publish release notes.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Create a release tag.
• Suggest improvements to this template.
• Conduct a postmortem, and publish its results.

Coming

Is your feature request related to a problem? Please describe.
Expand testing

Describe the solution you'd like
Add tests for all supported request types for the ClusterMetrics monitor feature.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

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

Describe the bug
The repo says "OpenSearch Dashboards Kibana Alerting Plugin" - this plugin doesn't run in Kibana, so that should be removed.

To Reproduce
Steps to reproduce the behavior:

1. Go to github repo
2. Look to the right
3. See this:

Expected behavior
It doesn't mention that other product.

Plugins
n/a

Screenshots
See above

As part of v2.0 release, mapping types are getting removed from OpenSearch engine. Below are the changes in the opensearch-engine.

• Removal of type from rest end-points
• Removal of include_type_name parameter from API requests.

As part of this issue, please verify if type removal change on OpenSearch engine impacts this repository. If yes, then please remove the type references/usage from this plugin.

Top level changes are captured in gist below:
https://gist.github.com/dreamer-89/d76eaf639171e8ab32fa7f8b9d6c93d3

For more detailed changes, please check meta issue below:
Related: OpenSearch-engine meta issue

On a fresh cluster, before all of the plugin system indices have been inited, there is an error toast that shows up in the unified flow when creating a monitor with a trigger:

These types of errors should be caught and handled. AD has a solution of filtering out the type of exception being faced, and ignoring if applicable (e.g., loading the detector list page without the .opendistro-anomaly-detectors system index present). See here for details

CVE-2021-23567 - High Severity Vulnerability

Vulnerable Library - colors-1.4.0.tgz

get colors in your node.js console

Library home page: https://registry.npmjs.org/colors/-/colors-1.4.0.tgz

Dependency Hierarchy:

• cypress-6.9.1.tgz (Root Library)
  • cli-table3-0.6.0.tgz
    • ❌ colors-1.4.0.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

The package colors after 1.4.0 are vulnerable to Denial of Service (DoS) that was introduced through an infinite loop in the americanFlag module. Unfortunately this appears to have been a purposeful attempt by a maintainer of colors to make the package unusable, other maintainers' controls over this package appear to have been revoked in an attempt to prevent them from fixing the issue. Vulnerable Code js for (let i = 666; i < Infinity; i++;) { Alternative Remediation Suggested * Pin dependancy to 1.4.0

Publish Date: 2022-01-14

URL: CVE-2021-23567

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Coming from meta issue opensearch-project/opensearch-plugins#108:

• Add auto-backport PR creation Github action to make sure all the PRs are backported for a particular release.
• Add auto-delete for merged auto-backport PRs to clean up the branches created during auto-backport.
• Add documentation for the same.

Related documentation: https://github.com/opensearch-project/opensearch-plugins/blob/main/BACKPORT.md

After the refactor of page along with bucket-level alerting implementation, there are several components removed and re-implemented. There are potentially leftover code that is unused in the code base and should be cleaned up.

Describe the bug
I currently have more than 200 destinations in the alerting plugin and issues are noticeable :

• In the "Destinations" list, pagination above item 200 is broken :

  • number of page is correct
  • if you click on a page representing an item above 200, you can quickly see the correct page but then you are redirected back to the page that is not bugged

• In the "Create monitor" page :

• if you create an action, the destination except the first 200 are not listed in the UI and you can't select them

To Reproduce
Steps to reproduce the behavior:

1. Create more than 200 destinations
2. Go to '/app/alerting#/destinations'
3. Play with the pages (1)
4. Create a monitor and a trigger
5. Start typing a destination that is not in the 200 firsts (2), it's missing

Plugins
Default install (everything)

Host/Environment

• OS: Debian
• Version: 10

Opensearch Dashboards 1.2.0

Is your feature request related to a problem? Please describe.
After acknowledging alerts in the flyout from alerts by trigger dashboard, the table within flyout does not refresh automatically, and manual refresh will throw error because the size of get alert request is malformed. Also, would be good to have toast notification upon acknowledging the alerts to verify if it succeed or failed.

Describe the solution you'd like

• Call getAlerts upon acknowledging alerts in flyout.
• Separate the alert by triggers size and flyout size to 2 variables.
• Add toast notification after acknowledging alerts in all places that allows acknowledgment.

Describe alternatives you've considered
Making the alert by triggers size a constant number, and stop using the size parameter in url.

Coming from opensearch-project/opensearch-build#1632, add support for -Dbuild.version_qualifier=.

The distribution build process now supports passing additional optional qualifiers other than the 3 digit versions, e.g. 2.0.0-alpha1. Add the ability to pass additional qualifier to build scripts, and generate artifacts with a version that includes the qualifier.

Is your feature request related to a problem? Please describe.
Currently, popovers, badges, accordions, and other containers for multiple input fields can make it difficult for users to identify where an error is located on the monitor creation form. These elements are typically closed by default, and users may inadvertently close the element without noticing an input error. Pressing the create/update button at the bottom of the page will then alert the user with a popup that says there is an error somewhere on the page, but the user has to scroll through the page and manually open container elements to find errors.

Describe the solution you'd like
Refactor popovers, badges, accordions, etc. to open automatically when the input fields they contain have errors.

Describe alternatives you've considered
If there is concern that opening containers with invalid values might cause the page size to become too large, an alternative might be to refactor container elements to highlight when a field they contain has an invalid value.

Describe the bug
Cypress integration tests on ARM64 are failing

To Reproduce
Steps to reproduce the behavior:

1. https://localhost:9200/_plugins/_alerting/monitors/_search

We attempted to make an http request to this URL but the request failed without a response.

We received this error at the network level:

Error: connect ECONNREFUSED 127.0.0.1:9200

Request sent: URL: https://localhost:9200/_plugins/_alerting/monitors/_search

2. Error:
   Common situations why this would fail:

• you don't have internet access
• you forgot to run / boot your web server
• your web server isn't accessible
• you have weird network configuration settings on your computer

https://on.cypress.io/request

Because this error occurred during a after all hook we are skipping the remaining tests in the current suite: Alerts
at http://localhost:34559/__cypress/runner/cypress_runner.js:160339:19
at tryCatcher (http://localhost:34559/__cypress/runner/cypress_runner.js:10765:23)
at http://localhost:34559/__cypress/runner/cypress_runner.js:5904:37
at tryCatcher (http://localhost:34559/__cypress/runner/cypress_runner.js:10765:23)
at Promise._settlePromiseFromHandler (http://localhost:34559/__cypress/runner/cypress_runner.js:8700:31)
at Promise._settlePromise (http://localhost:34559/__cypress/runner/cypress_runner.js:8757:18)
at Promise._settlePromise0 (http://localhost:34559/__cypress/runner/cypress_runner.js:8802:10)
at Promise._settlePromises (http://localhost:34559/__cypress/runner/cypress_runner.js:8878:18)
at _drainQueueStep (http://localhost:34559/__cypress/runner/cypress_runner.js:5472:12)
at _drainQueue (http://localhost:34559/__cypress/runner/cypress_runner.js:5465:9)
at Async.../../node_modules/bluebird/js/release/async.js.Async._drainQueues (http://localhost:34559/__cypress/runner/cypress_runner.js:5481:5)
at Async.drainQueues (http://localhost:34559/__cypress/runner/cypress_runner.js:5351:14)
From Your Spec Code:
at Context.eval (http://localhost:34559/__cypress/tests?p=cypress/support/index.js:238:6)

From Node.js Internals:
RequestError: Error: connect ECONNREFUSED 127.0.0.1:9200
at new RequestError (/usr/share/opensearch/.cache/Cypress/6.9.1/Cypress/resources/app/packages/server/node_modules/request-promise-core/lib/errors.js:14:15)
at Request.plumbing.callback (/usr/share/opensearch/.cache/Cypress/6.9.1/Cypress/resources/app/packages/server/node_modules/request-promise-core/lib/plumbing.js:87:29)
at Request.RP$callback [as _callback] (/usr/share/opensearch/.cache/Cypress/6.9.1/Cypress/resources/app/packages/server/node_modules/request-promise-core/lib/plumbing.js:46:31)
at self.callback (/usr/share/opensearch/.cache/Cypress/6.9.1/Cypress/resources/app/packages/server/node_modules/@cypress/request/request.js:185:22)
at Request.emit (events.js:315:20)
at Request.onRequestError (/usr/share/opensearch/.cache/Cypress/6.9.1/Cypress/resources/app/packages/server/node_modules/@cypress/request/request.js:877:8)
at ClientRequest.emit (events.js:327:22)
at TLSSocket.socketErrorListener (_http_client.js:426:9)
at TLSSocket.emit (events.js:315:20)
at emitErrorNT (internal/streams/destroy.js:92:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
at processTicksAndRejections (internal/process/task_queues.js:84:21)

Expected behavior (Test passing with No Security )
Running: alert_spec.js (1 of 3)
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db

Alerts
can be in 'Active' state
✓ after the monitor starts running (66271ms)
can be in 'Acknowledged' state
✓ by clicking the button in Dashboard (2254ms)
can be in 'Completed' state
✓ when the trigger condition is not met after met once (64083ms)
can be in 'Error' state
✓ by using a wrong destination (1959ms)
can be in 'Deleted' state
✓ by deleting the monitor (2398ms)

5 passing (2m)

Plugins
Please list all plugins currently enabled.

Screenshots
If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: [e.g. iOS]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
Currently, when there are errors in the monitor, trigger, or action definition forms (e.g., when an invalid value is entered into an input field), only some fields will automatically scroll to the error when the create/update button is pressed.

Describe the solution you'd like
Anchor points could be implemented for each input field to help users quickly identify fields with errors, rather than requiring users to scroll through the page.

Coming from opensearch-build#567, release version 1.2. Please follow the following checklist.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• #139

CI/CD

• Increment version on main to 1.2.0.0.
• Ensure working and passing CI.
• Re(add) this repo to the manifest.

Pre-Release

• Branch and build from a 1.2 branch.
• Update your branch in the manifest.
• Feature complete, pencils down.
• Fix bugs that target this release.

Release

• Complete documentation.
• Gather, review and publish release notes.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Create a release tag.
• Suggest improvements to this template.
• Conduct a postmortem, and publish its results.

Dashboards has upgraded Node to v14.18.2 and this is for plugin teams to verify that their plugins work with the new version upgrade. The Dashboards branch running the upgraded node is feature/node14.

A list of things to check is:

• Your plugin's node version is bumped to 14.18.2
• Your plugin's @types/node package is bumped to ^14.17.32 if it's used
• Plugin builds and runs on Dashboards
• All of your plugin's tests pass
• Your GitHub workflows are not broken by the node version change and updated if they do
• Any sanity/smoke testing is successful