opensearch-project / dashboards-reporting Goto Github PK

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.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

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

Is it possible to have a feature to allow user to download CSV without maximum of 10,000 rows limitation? Can someone give me some hints how to implement such feature? Where will be the best place (code file) to add a checkbox to enable such feature? Where will be the best place I can utilize "scroll" feature to retrieve all the data? I am not very familiar with ES and Kibana source code layout. But eager to have such feature implemented. Thanks!

This issue is submitted by @FromPAUS
opendistro-for-elasticsearch/kibana-reports#176

@51CGO commented on Wed May 24 2023

Describe the bug

When calling API .opendistro-reports-instances/_search or .opendistro-reports-definitions/_search, no hit is found.

To Reproduce
Steps to reproduce the behavior:

1. Create some reports definitions using Reporting -> Report definitions -> Create
2. Verify that the definitions exists and that some reports have been created
3. Go to Dev tools
4. Try the following calls:
   GET .opendistro-reports-instances/_search
   GET .opendistro-reports-definitions/_search
   => no hit displayed

Expected behavior
These calls should display the definitions and the instances

OpenSearch Version
2.6.0

Dashboards Version
2.6.0

Plugins
Standard installation without adding nor removing any plugin.

Screenshots

Host/Environment (please complete the following information):

• OS: RHEL 8
• Browser and version : Firefox 102

@zhongnansu commented on Wed May 24 2023

@opensearch-project/triage please help moving to reporting repo

@joshuarrrr commented on Thu May 25 2023

Thanks @51CGO - we'll get this moved to the reporting repo: https://github.com/opensearch-project/dashboards-reporting

Is your feature request related to a problem? Please describe.
With Elastic search , we could export to CSV a saved object from the dashboard directly , including the filter apply to it . For example , we could apply a filter on a column to reduce the number of line and after export it.
Now with Opensearch we can export to CSV a saved object but it is only from the reporting tab , which means that all the filter that the user apply in the dashboard are loose. If we want to apply filter, we need to do it again from the discover table.

Describe the solution you'd like
The solution should be to be able to export to CSV directly from the dashboard as ElasticSearch does

What is the bug?
Legend on visualizations is missing in generated report (pdf and png)

How can one reproduce the bug?

• Create a dashboard with visualizations (that have the legend enabled)
• generate a report (doesn't matter if pdf or png)
• miss legend :(

What is the expected behavior?

• legends are present

What is your host/environment?
Opensearch Host

• opensearchproject/opensearch:2.6.0 (same result with 2.5.0)
• opensearchproject/opensearch-dashboards:2.6.0 (same result with 2.5.0)

Client

• OS: Ubuntu 22.04.2 LTS
• Version: 22.04.2 LTS
• Plugins:
  • Edge: none
  • Firefox: uBlock origin
• tested Browsers:
  • Firefox 110.0.1 (64-Bit)
  • Microsoft Edge 110.0.1587.57 (64-Bit)
  • Chromium 110.0.5481.177
  • Google Chrome 110.0.5481.177

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

That is what the dashboard looks like (graphs have legends)

And that's what the report generated from that dashboard looks like in FireFox and Edge

Do you have any additional context?
In other news: if the Navigation is docked, it is included in the generated reports, which does not feel intuitive

Is your feature request related to a problem? Please describe.
Desiring a faster way to get CSV from the dashboard....

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

Describe the solution you'd like
From the Reports menu, currently there is a Generate PDF and a Generate PNG option. We'd like to see a Generate CSV option which would provide all data available to the extend possible.

A clear and concise description of what you want to happen.
When a user, say a data scientist, selects the new Generate CSV menu option, the data matching the visualizations shown in the dashboards is made available for download. Then, they can use that CSV file within tools such as Jupyter Notebook.

Describe alternatives you've considered
I saw this link which illustrates that feature, but would like it in OpenSearch natively.

A clear and concise description of any alternative solutions or features you've considered.
Currently, one can add a data table view and from there using a multistep workaround of saving Dashboard filter, opening the filter query in Discover, resaving in Discover, then reporting -> export as CSV. Way to complex.
Also, the table option only exports fields that are configured, not ALL, which is desired.

Additional context

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

@singhankit62000 commented on Thu Apr 13 2023

Describe the bug
Installed Opensearch dashboard 2.6.0 with reporting plugin.
Created visualizations of various types and tried to generate reports for those visualizations in pdf and png format.
The visualizations are visible in the reports but the scale is not coming in the generated reports.

To Reproduce
Steps to reproduce the behavior:

1. Go to Visualisation, Save a visualisation
2. Click on Reporting -> Download PNG/ Download PDF
3. Check the downloaded report and compare it with the actual Visualisation

Expected behavior
A clear report of the whole visualisation/ dashboard along with the scale of the data as well.

OpenSearch Version
2.6.0

Dashboards Version
2.6.0

Plugins

• reportsDashboards
• opensearch-reports-scheduler
• opensearch-job-scheduler

Screenshots

Host/Environment (please complete the following information):

• OS: [e.g. iOS]
• Browser and version [e.g. 22]

Additional context

Add any other context about the problem here.

@joshuarrrr commented on Thu Apr 13 2023

@opensearch-project/triage Please transfer to https://github.com/opensearch-project/dashboards-reporting

@singhankit62000 commented on Sun Apr 16 2023

Hi @joshuarrrr is there something I need to do for this issue to be transferred?

What is the bug?
The "Reporting" menu link is only added to the default, expanded desktop menu. But on smaller screens, those menu items are collapsed into an expandable menu, and the menu item is missing:

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Resize window to small width, until the action item menu becomes a button with nine-dot grid icon (see screenshot above)
2. Click on action menu button
3. Reporting link doesn't appear

What is the expected behavior?
The Reporting link should always be available, regardless of screen size/mode.

Context
Discovered as part of work on global header redesign: opensearch-project/OpenSearch-Dashboards#1583

What is the bug?

• While downloading csv report, if a nested object has false boolean value, it is replaced by emptyFieldValue. It works fine for other data types and also true boolean value.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Create a test index

PUT test_index
{
  "mappings": {
    "properties": {
      "A.B":    { "type" : "boolean" },
      "C":     { "type" : "boolean" }
    }
  }
}

POST test_index/_doc/1
  "A": {
        "B": false
      },
  "C": false
}

POST test_index/_doc/2
  "A": {
        "B": true
      },
  "C": true
}

2. Create a index pattern with this index.
3. Select this index in Discover page. All values are shown correctly on Discover page.
4. Save and download as CSV.
5. Downloaded CSV will have empty value where A.B=false

What is the expected behavior?
CSV should have same values as shown on Discover page.

What is your host/environment?

• OS: Ubuntu
• Version [e.g. 22] 2.5
• Plugins: reporting

Do you have any additional context?
After some debugging, looks like values at traverse function are correct.

key: A.B and result[key]: true

key: C and result[key]: true

key: A.B and result[key]: false

key: C and result[key]: true

key: A.B and result[key]: false

key: C and result[key]: false

key: A.B and result[key]: true

key: C and result[key]: false

False value is mostly getting replaced while converting json2csv with emptyFieldValue

Summary

With 2.9.0 release, there are lot of enhancements going in for segment replication[1][2] feature (went GA in 2.7.0), we need to ensure different plugins are compatible with current state of this feature. Previously, we ran tests on plugin repos to verify this compatibility but want plugin owners to be aware of these changes so that required updates (if any) can be made. With 2.10.0 release, remote store feature is going GA which internally uses SEGMENT replication strategy only i.e. it enforces all indices to use SEGMENT replication strategy. So, it is important to validate plugins are compatible with segment replication feature.

What changed

1. Refresh policy behavior

1. RefreshPolicy.IMMEDIATE will only refresh primary shards but not replica shards immediately. Instead post refresh, primary will start a round of segment replication to update the replica shard copies leading to eventual consistency.
2. RefreshPolicy.WAIT_UNTIL ensures the indexing operation is searchable in your cluster i.e. RAW (Read after write guarantee). With segment replication, this guarantee is not promised due to delay in replica shared updates from asynchronous background refreshes.

2. Refresh lag on replicas

With segment replication, there is inherent delay in documents to be searchable on replica shard copies. This is due to the fact that replica shard copies over data (segment) files from primary. Thus, compared to document replication, there will be on average increase in amount of time the replica shards are consistent with primaries.

3. System/hidden indices support

With opensearch-project/OpenSearch#8200, system and hidden indices are now supported with SEGMENT replication strategy. We need to ensure there are no bottlenecks which prevents system/hidden indices with segment replication.

Next steps

With segment replication strong reads are not guaranteed. Thus, if the plugin needs strong reads guarantees specially as alternative to change in behavior of refresh policy and lag on replicas (point 1 and 2 above), we need to update search requests to target primary shard only. With opensearch-project/OpenSearch#7375, core now supports primary shards only based search. Please follow documentation for examples and details

Open questions

In case of any questions or issues, please post it in core issue

Reference

[1] Design
[2] Documentation

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.

Is your feature request related to a problem?
Right now csv reports do not respect user configured timezone in advanced settings (e.g. browser time PDT but csv reports will be in UTC)

What solution would you like?
Support advanced settings for csv reports, similar to opensearch-project/reporting#209

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

Do you have any additional context?
Add any other context or screenshots about the feature request here.

This is a component issue for 2.10.0.
Coming from opensearch-project/opensearch-build#3743. 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.10.0.

CI/CD

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

Pre-Release

• Update to the 2.10.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.10.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.

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

Is your feature request related to a problem?
We are using OpenSearch at work as a SIEM and a request was to export specific Dashboards monthly and based on Events.
When we export a Dashboard in a PDF, that has a Data Table Visualization linked, we only see the amount of Events we configured for the Data Table on the Options Tab under "Max rows per page".
If it is possible we would like to not set the Value to a High Number as we don't know how many Events are able to be listed and it would make the Visualization a bit messy if we list all Logs on one Page.
CSV isn't unfortunately a Option as we send this Report to non IT-Worker and we would like to make just one export of the whole Dashboard.

So in conclusion, we need a Feature that can Download a Dashboard/Visualization in that way we as Admins can search through the Logs but without the need to actually give a User access to our OpenSearch Environment.

What solution would you like?
We would like to have a HTML export of a Dashboard, Visualization and Saved Search we can download and maybe a possibility to automatically send these HTML exports via Mail.

What alternatives have you considered?
We thought about a Second PDF Page or File where all the Information are listed which are missing on the first File.
Maybe even just a PDF export no matter how many Documents are listed within a Visualization it will list everythin.

Do you have any additional context?

Description

As part of our ongoing efforts to improve the OpenSearch Dashboards' performance, maintainability, and developer experience, we have decided to de-angularize the dashboard.

This change will impact all plugins that use the OpenSearch Dashboard dashboard and require your attention to ensure the compatibility and performance of your plugins. If your plugin has nothing to do with dashboard, please close the issue.

We suggest a thoroughly test of your plugin on new dashboard. Here are some steps:

• Pull this feature branch https://github.com/opensearch-project/OpenSearch-Dashboards/tree/feature/deangular-dashboards.

• Install and start your plugin.

• Run all the tests. Also recommend to do manual tests.

We understand that this transition may require significant work on your part, and we are here to support you during this process. If there is any concerns or issues, feel free to comment here. If there is a bug, please also add it to opensearch-project/OpenSearch-Dashboards#4505.

What is the bug?
The context menu component is very brittle and dependent on a number of OpenSearch Dashboards side effects that are not part of any public API. As OpenSearch Dashboards is refactored for OUI compliance, cohesion, and look and feel improvements, many of these hard-coded assumptions will break, leaving the current code non-functional.

How can one reproduce the bug?
A few, non-comprehensive examples:

1. These methods for determining the current app are all incorrect and brittle:

   dashboards-reporting/public/components/context_menu/context_menu.js

   Lines 255 to 276 in c8be18e

   	const isDiscoverNavMenu = (navMenu) => {
   	return (
   	navMenu[0].children.length === 5 &&
   	($('[data-test-subj="breadcrumb first"]').prop('title') === 'Discover' ||
   	$('[data-test-subj="breadcrumb first last"]').prop('title') ===
   	'Discover')
   	);
   	};
   	const isDashboardNavMenu = (navMenu) => {
   	return (
   	(navMenu[0].children.length === 4 || navMenu[0].children.length === 6) &&
   	$('[data-test-subj="breadcrumb first"]').prop('title') === 'Dashboard'
   	);
   	};
   	const isVisualizationNavMenu = (navMenu) => {
   	return (
   	navMenu[0].children.length === 3 &&
   	$('[data-test-subj="breadcrumb first"]').prop('title') === 'Visualize'
   	);
   	};

2. The nav menu integration tries to use class names instead of navigation plugin APIs. We will remove at least one of these class names soon (via opensearch-project/OpenSearch-Dashboards#3964):

   dashboards-reporting/public/components/context_menu/context_menu.js

   Lines 280 to 282 in c8be18e

   	const navMenu = document.querySelectorAll(
   	'span.osdTopNavMenu__wrapper > nav.euiHeaderLinks > div.euiHeaderLinks__list'
   	);

3. HTML templates don't correctly position UI elements; UI controls must be rendered using actual OUI components:

   dashboards-reporting/public/components/context_menu/context_menu_ui.js

   Line 35 in c8be18e

   return `

What is the expected behavior?
Because the mentioned files don't use proper APIs, they may break at any time. They should be refactored to use interfaces that are subject to semver.

CVE-2023-28155 - Medium Severity Vulnerability

Vulnerable Library - request-2.88.2.tgz

Simplified HTTP request client.

Library home page: https://registry.npmjs.org/request/-/request-2.88.2.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/request/package.json

Dependency Hierarchy:

• jsdom-16.5.0.tgz (Root Library)
  • ❌ request-2.88.2.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

** UNSUPPORTED WHEN ASSIGNED ** The Request package through 2.88.1 for Node.js allows a bypass of SSRF mitigations via an attacker-controller server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to HTTP). NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Publish Date: 2023-03-16

URL: CVE-2023-28155

CVSS 3 Score Details (6.1)

Base Score Metrics:

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

For more information on CVSS3 Scores, click here.

This is a component issue for 2.8.0.
Coming from opensearch-build#3434. 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.8.0.

CI/CD

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

Pre-Release

• Update to the 2.8 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.8.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.

This is a component issue for 2.11.0.
Coming from opensearch-project/opensearch-build#3998. 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.11.0.
• Finalize the code and create the the release branch 2.11.0 from the 2.x branch.

CI/CD

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

Pre-Release

• 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.11.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.

OSD provides CSS linting through Stylelint and the yarn lint:style command. This helps maintain code quality and code style. Additionally, we're trying to move towards no custom styling, which means no Sass files. We're pushing this out incrementally, and right now we are pushing to remove custom colors and font overrides. To accurately locate these issues, the Stylelint output needs to be clean. However, this is currently not the case.

2 things need to happen for this:

• Add script to run Stylelint and add it to the build and test workflow
• Fix any issues that Stylelint currently throws

What is the bug?
CVE-2022-37603

How can one reproduce the bug?
Security risk caused by loader-utils npm library

What is the expected behavior?

Inefficient Regular Expression Complexity
loader-utils is vulnerable to Regular Expression Denial of Service (ReDoS) via url variable

What is your host/environment?
N/A

Resolution
Bump loader-utils version

Describe the bug
Hi team, In the Reporting tab of Opensearch, it is throwing the below error

I have 3 Node cluster setups. Memory and disk spaces are fine. All functionalities are working only issue is with this reporting tab.

Plugins

node-3 opensearch-alerting 2.6.0.0

node-3 opensearch-anomaly-detection 2.6.0.0

node-3 opensearch-asynchronous-search 2.6.0.0

node-3 opensearch-cross-cluster-replication 2.6.0.0

node-3 opensearch-geospatial 2.6.0.0

node-3 opensearch-index-management 2.6.0.0

node-3 opensearch-job-scheduler 2.6.0.0

node-3 opensearch-knn 2.6.0.0

node-3 opensearch-ml 2.6.0.0

node-3 opensearch-neural-search 2.6.0.0

node-3 opensearch-notifications 2.6.0.0

node-3 opensearch-notifications-core 2.6.0.0

node-3 opensearch-observability 2.6.0.0

node-3 opensearch-performance-analyzer 2.6.0.0

node-3 opensearch-reports-scheduler 2.6.0.0

node-3 opensearch-security 2.6.0.0

node-3 opensearch-security-analytics 2.6.0.0

node-3 opensearch-sql 2.6.0.0

node-2 opensearch-alerting 2.6.0.0

node-2 opensearch-anomaly-detection 2.6.0.0

node-2 opensearch-asynchronous-search 2.6.0.0

node-2 opensearch-cross-cluster-replication 2.6.0.0

node-2 opensearch-geospatial 2.6.0.0

node-2 opensearch-index-management 2.6.0.0

node-2 opensearch-job-scheduler 2.6.0.0

node-2 opensearch-knn 2.6.0.0

node-2 opensearch-ml 2.6.0.0

node-2 opensearch-neural-search 2.6.0.0

node-2 opensearch-notifications 2.6.0.0

node-2 opensearch-notifications-core 2.6.0.0

node-2 opensearch-observability 2.6.0.0

node-2 opensearch-performance-analyzer 2.6.0.0

node-2 opensearch-reports-scheduler 2.6.0.0

node-2 opensearch-security 2.6.0.0

node-2 opensearch-security-analytics 2.6.0.0

node-2 opensearch-sql 2.6.0.0

node-1 opensearch-alerting 2.6.0.0

node-1 opensearch-anomaly-detection 2.6.0.0

node-1 opensearch-asynchronous-search 2.6.0.0

node-1 opensearch-cross-cluster-replication 2.6.0.0

node-1 opensearch-geospatial 2.6.0.0

node-1 opensearch-index-management 2.6.0.0

node-1 opensearch-job-scheduler 2.6.0.0

node-1 opensearch-knn 2.6.0.0

node-1 opensearch-ml 2.6.0.0

node-1 opensearch-neural-search 2.6.0.0

node-1 opensearch-notifications 2.6.0.0

node-1 opensearch-notifications-core 2.6.0.0

node-1 opensearch-observability 2.6.0.0

node-1 opensearch-performance-analyzer 2.6.0.0

node-1 opensearch-reports-scheduler 2.6.0.0

node-1 opensearch-security 2.6.0.0

node-1 opensearch-security-analytics 2.6.0.0

node-1 opensearch-sql 2.6.0.0

Screenshots

Host/Environment (please complete the following information):

• OS: Red Hat Linux 7
• Version 2.6.0

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

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.

I've been trying out the report feature in the past week and got it finally working.

Then i tried to generate some pdf reports. I tried reporting a dashboard and a visualization including a data table showing some top accessed urls from a webserver.

Problem is that the resulting Report pdf Height seems to be limited somehow. The pdf is only showing the first 23 Entries of the data table and i don't see any option anywhere to change that size. I do need the last 50 Entries to be included in that Report.

Is there any option to increase the max shown size? Do i need to increase some resolution of the chromium-headless-browser or is the limit somewhere else? Or will this not work at all and do i need to use csv exports for achieving my top list?

Thank you very much for building this nice reporting feature so far.
Any help on this would be really appreciated.

This issue is submitted by @uplexPaul
opendistro-for-elasticsearch/kibana-reports#326

This is a component issue for 3.0.0.
Coming from opensearch-project/opensearch-build#3747. 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 v3.0.0.

CI/CD

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

Pre-Release

• Update to the 3.0.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 3.0.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.

The integration test failed at distribution level for component reportsDashboards
Version: 1.3.13
Distribution: tar
Architecture: x64
Platform: linux

Please check the logs: https://build.ci.opensearch.org/job/integ-test-opensearch-dashboards/4096/display/redirect

* Test-report manifest:*
- https://ci.opensearch.org/ci/dbc/integ-test-opensearch-dashboards/1.3.13/6598/linux/x64/tar/test-results/4096/integ-test/test-report.yml

Note: Steps to reproduce, additional logs and other files can be found within the above test-report manifest.
Instructions of this test-report manifest can be found here.

What is the bug?
In production environment, bootstrapping fails during postinstall because replace-in-file is not available.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. export NODE_ENV=production
2. yarn osd clean
3. yarn osd bootstrap
4. See error

   Error: Cannot find module 'replace-in-file'
   Require stack:
   - ........../plugins/dashboards-reporting/scripts/postinstall.js
   

What is the expected behavior?
Installation completes without errors.

Do you have any additional context?
replace-in-file should be moved to dependencies.

The integration test failed at distribution level for component reportsDashboards
Version: 2.10.0
Distribution: tar
Architecture: arm64
Platform: linux

Please check the logs: https://build.ci.opensearch.org/job/integ-test-opensearch-dashboards/4098/display/redirect

* Test-report manifest:*
- https://ci.opensearch.org/ci/dbc/integ-test-opensearch-dashboards/2.10.0/6596/linux/arm64/tar/test-results/4098/integ-test/test-report.yml

Note: Steps to reproduce, additional logs and other files can be found within the above test-report manifest.
Instructions of this test-report manifest can be found here.

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'split')
at _callee4$ (reportsDashboards.plugin.js:24:201073)
at tryCatch (reportsDashboards.plugin.js:24:180012)
at Generator.invoke [as _invoke] (reportsDashboards.plugin.js:24:183963)
at Generator.next (reportsDashboards.plugin.js:24:181151)
at asyncGeneratorStep (reportsDashboards.plugin.js:1:73707)
at _next (reportsDashboards.plugin.js:1:74018)
at reportsDashboards.plugin.js:1:74168
at new Promise ()
at reportsDashboards.plugin.js:1:73930
at checkURLParams (reportsDashboards.plugin.js:24:202215)
_callee4$ @ reportsDashboards.plugin.js:24
tryCatch @ reportsDashboards.plugin.js:24
invoke @ reportsDashboards.plugin.js:24
(anonymous) @ reportsDashboards.plugin.js:24
asyncGeneratorStep @ reportsDashboards.plugin.js:1
_next @ reportsDashboards.plugin.js:1
(anonymous) @ reportsDashboards.plugin.js:1
(anonymous) @ reportsDashboards.plugin.js:1
checkURLParams @ reportsDashboards.plugin.js:24
(anonymous) @ reportsDashboards.plugin.js:24
u @ osd-ui-shared-deps.js:406
l @ osd-ui-shared-deps.js:406
setTimeout (async)
(anonymous) @ osd-ui-shared-deps.js:406
c @ osd-ui-shared-deps.js:406
add @ osd-ui-shared-deps.js:406
(anonymous) @ osd-ui-shared-deps.js:406
Deferred @ osd-ui-shared-deps.js:406
then @ osd-ui-shared-deps.js:406
_.fn.ready @ osd-ui-shared-deps.js:406
_.fn.init @ osd-ui-shared-deps.js:406
_ @ osd-ui-shared-deps.js:395
(anonymous) @ reportsDashboards.plugin.js:24
webpack_require @ reportsDashboards.plugin.js:1
(anonymous) @ reportsDashboards.plugin.js:24
webpack_require @ reportsDashboards.plugin.js:1
(anonymous) @ reportsDashboards.plugin.js:24
webpack_require @ reportsDashboards.plugin.js:1
get @ bootstrap.js:28
read @ core.entry.js:15
_callee3$ @ core.entry.js:15
tryCatch @ securityAnalyticsDashboards.plugin.js:2
(anonymous) @ securityAnalyticsDashboards.plugin.js:2
(anonymous) @ securityAnalyticsDashboards.plugin.js:2
plugin_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
(anonymous) @ core.entry.js:15
(anonymous) @ core.entry.js:15
createPluginInstance @ core.entry.js:15
_callee$ @ core.entry.js:15
tryCatch @ securityAnalyticsDashboards.plugin.js:2
(anonymous) @ securityAnalyticsDashboards.plugin.js:2
(anonymous) @ securityAnalyticsDashboards.plugin.js:2
plugin_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
(anonymous) @ core.entry.js:15
(anonymous) @ core.entry.js:15
setup @ core.entry.js:15
_callee$ @ core.entry.js:15
u @ osd-ui-shared-deps.js:382
(anonymous) @ osd-ui-shared-deps.js:382
(anonymous) @ osd-ui-shared-deps.js:382
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
plugins_service_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
(anonymous) @ core.entry.js:15
(anonymous) @ core.entry.js:15
setup @ core.entry.js:15
_callee$ @ core.entry.js:15
u @ osd-ui-shared-deps.js:382
(anonymous) @ osd-ui-shared-deps.js:382
(anonymous) @ osd-ui-shared-deps.js:382
core_system_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
core_system_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
(anonymous) @ core.entry.js:15
(anonymous) @ core.entry.js:15
setup @ core.entry.js:15
_callee$ @ core.entry.js:15
u @ osd-ui-shared-deps.js:382
(anonymous) @ osd-ui-shared-deps.js:382
(anonymous) @ osd-ui-shared-deps.js:382
osd_bootstrap_asyncGeneratorStep @ core.entry.js:15
_next @ core.entry.js:15
Promise.then (async)
osd_bootstrap_asyncGeneratorStep @ core.entry.js:15
next @ core.entry.js:15
(anonymous) @ core.entry.js:15
(anonymous) @ core.entry.js:15
osdBootstrap @ core.entry.js:15
osdBootstrap @ core.entry.js:15
(anonymous) @ bootstrap.js:166
innerCb @ bootstrap.js:91
load (async)
loadScript @ bootstrap.js:81
(anonymous) @ bootstrap.js:100
load @ bootstrap.js:87
window.onload @ bootstrap.js:105
load (async)
(anonymous) @ bootstrap.js:48
core.entry.js:15 TypeError: Cannot read properties of undefined (reading 'call')
at webpack_require (observabilityDashboards.plugin.js:1:932)

What is the bug?
Report generation is moved to client side using html2canvas, and PDF reports are images embedded in PDFs. Previously the texts were selectable, need to investigate if it's possible with client side report generation.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

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

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

This is a component issue for {REPLACE_WITH_RELEASE_VERSION}.
Coming from opensearch-project/opensearch-build#3616. 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 v__REPLACE_MAJOR_MINOR_PATCH__.

CI/CD

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

Pre-Release

• Update to the __REPLACE_MAJOR_MINOR__ 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 __{REPLACE_MAJOR_MINOR_PATCH}__ 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.

@51CGO commented on Mon Apr 17 2023

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

In the reporting page, reporting definitions can be deleted but reportings can't.

Describe the solution you'd like

The report details page should display a button to delete the report

Describe alternatives you've considered

N/A

Additional context

N/A

@zhongnansu commented on Mon Apr 17 2023

@opensearch-project/triage please transfer this issue to reporting repo

CVE-2023-26115 - Medium Severity Vulnerability

Vulnerable Library - word-wrap-1.2.3.tgz

Wrap words to a specified length.

Library home page: https://registry.npmjs.org/word-wrap/-/word-wrap-1.2.3.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/word-wrap/package.json

Dependency Hierarchy:

• jsdom-16.7.0.tgz (Root Library)
  • escodegen-2.0.0.tgz
    • optionator-0.8.3.tgz
      • ❌ word-wrap-1.2.3.tgz (Vulnerable Library)

Found in HEAD commit: 9d17a87630e504b9d5758136fa39293637ae86f1

Found in base branch: main

Vulnerability Details

All versions of the package word-wrap are vulnerable to Regular Expression Denial of Service (ReDoS) due to the usage of an insecure regular expression within the result variable.

Publish Date: 2023-06-22

URL: CVE-2023-26115

CVSS 3 Score Details (5.3)

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: Low

For more information on CVSS3 Scores, click here.

What is the bug?
The cypress integration tests in 02-edit.spec.jsand in 04-download.spec.js seem flaky.

How can one reproduce the bug?

• This usually occurs when network on instances have latency for loading dashboards URL

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

• OS 2.3

Do you have any screenshots?

This is a tracking issue for phase 1 of OUI theme plugin compliance, which will involve changes to OUI typography and color SASS variables (for both dark and light mode). For full details, including dates and tooling, see opensearch-project/OpenSearch-Dashboards#4291

If your plugin has no UI views or components, please add a comment to that effect, and we'll remove the repo from future look and feel update campaigns.

Actions required

• Acknowledge the issue by adding an assignee who will serve as a point-of-contact
• Provide screenshots and navigation instructions for important views and screens in your plugin or application. This will assist with both manual and automatic validation of compliance
• Identify all typographic properties and styles
• Create issues to mitigate typographic styles not inherited from OUI components or SASS variables
• Identify all color values, including visualization colors and palettes
• Create issues to mitigate typographic styles not inherited from OUI components or SASS variables
• Resolve all mitigation issues
• Validate and test plugin with updated OUI theme

Known issues

• opensearch-project/reporting#735

Questions?

Add a comment on opensearch-project/OpenSearch-Dashboards#4291

Is your feature request related to a problem? Please describe.
I'm using OpenSearch Dashboards beta running on Firefox 88.0.1 (64-bit), Ubuntu 20.04.
Unlike all rest pages, Reporting seem not to stretch to the end of the screen, which makes the user experience a bit inconsistent. As you can see on the screenshot, there's an empty space on the right-side.

Describe the solution you'd like
A responsive UI should fill the empty space to the right accordingly.

Describe alternatives you've considered
It's not a major thing, works fine as-is anyway.

Additional context
Definitely not a priority, just a nice thing to have :)
Here's a screenshot from alerting UI, just as a comparison:

@BT-93 commented on Wed May 03 2023

When dark mode is set and you export to either PNG or PDF the background of the exports is white.
This was not an issue prior to version 2.6 (I think).

To Reproduce
Steps to reproduce the behavior:

1. Go to Advanced Settings
2. Search for Dark Mode
3. Set the slider to Dark Mode
4. Go to a dashboard
5. Select Reporting
6. Go either PNG or PDF
7. Exported doco background is white

Expected behavior
The background to be color #141519

OpenSearch Version
2.6 & 2.7

Dashboards Version
2.6 & 2.7

Plugins
The default ones

Screenshots

Host/Environment (please complete the following information):

• OS: Windows 10
• Browser and version: Chrome Version 113.0.5672.64 (Official Build) (64-bit)

Additional context
:)

@zhongnansu commented on Thu May 04 2023

@opensearch-project/triage Please transfer this issue to reporting repo https://github.com/opensearch-project/dashboards-reporting

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?

• date format of nested fields are not changing according to advanced settings in csv report

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Create a index containing fields of type Object.

PUT test_index2
{
  "mappings": {
    "properties": {
      "key1": {
        "properties": {
          "key11": {
            "type": "keyword"
          },
          "key12": {
            "type": "date"
          },
          "key13": {
            "type": "date"
          }
        }
      },
      "key2": {
        "type": "date"
      },
      "key3": {
        "type": "keyword"
      }
    }
  }
}

2. Add sample data

POST /test_index2/_doc/test
{

  "key1": {

    "key11" : "value11",

    "key12": "2023-04-26T04:34:32Z",

    "key13": "2023-04-26T04:34:32Z"

  },

  "key2": "2023-04-21T04:34:32Z",

  "key3": "value3"

}

3. Change the date format to --- in Advanced settings. ¬- MMM D, YYYY @ HH:mm:ss.SSS
4. Try to extract report of field in the object and try to download it.
   In the report, only top level field – key2 will be in “MMM D, YYYY @ HH:mm:ss.SSS”. Field key12, key13 will be in default format.

What is the expected behavior?

• Date format should be changed for all date type fields.

What is your host/environment?

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

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

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 is the bug?
In the 2.1.0 release of Opensearch Dashboards, we're planning to add a configurable option for either a condensed (single-line) or expanded (2-line) global header. However, this plugin currently hard-codes the header height into the popover positioning, which means the popover will no longer align with the menu link in the default mode:

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Pull the feature branch of opensearch dashboards, or simply change the multiplier here to 1.
2. Load opensearch dashboards with the dashboard-reports plugin and click on the Reporting menu link.

What is the expected behavior?
Because the plugin is responsible for rendering both the menu link and popover, it should use the correct EUI components, which will take care of positioning the popover relative to the menu link. Instead of building up large HTML strings with template literals, using EUI React components will make the UI controls much more maintainable and standardized.

Received Error: Error building reportsDashboards, retry with: ./build.sh manifests/2.9.0/opensearch-dashboards-2.9.0.yml --component reportsDashboards.
The distribution build for reportsDashboards has failed.
Please see build log at https://build.ci.opensearch.org/job/distribution-build-opensearch-dashboards/6338/consoleFull

The footer that is added manually in report generation is not shown in the downloaded report.

Created a Report definition, selected a dashboard for which a report needs to be generated, and added a header and footer for the report.

In the downloaded PDF / PNG able to see only the header and the Dashboard content alone.

In plugins/reportsDashboards/server/routes/utils/visual_report/visualReportHelper.js file, the custom footer node is not appending to the parent node when the Report HTML format is created. Whereas inserting a DOM node before a parent node works fine.

CVE-2023-2251 - High Severity Vulnerability

Vulnerable Library - yaml-1.10.0.tgz

JavaScript parser and stringifier for YAML

Library home page: https://registry.npmjs.org/yaml/-/yaml-1.10.0.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/yaml/package.json

Dependency Hierarchy:

• react-toast-notifications-2.4.0.tgz (Root Library)
  • core-10.0.35.tgz
    • css-10.0.27.tgz
      • babel-plugin-emotion-10.0.33.tgz
        • babel-plugin-macros-2.8.0.tgz
          • cosmiconfig-6.0.0.tgz
            • ❌ yaml-1.10.0.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Uncaught Exception in GitHub repository eemeli/yaml prior to 2.2.2.

Publish Date: 2023-04-24

URL: CVE-2023-2251

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: GHSA-f9xv-q969-pqx4

Release Date: 2023-04-24

Fix Resolution: yaml - 2.2.2

What is the bug?
Reporting context menu has "Create report definition" and "View reports". If user is assigned the kibana_read_only role, they do not have access to reporting plugin and clicking on the buttons leads to "Application not found" error.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Using admin, create a new user
2. Assign role kibana_read_only, kibana_user, reports_instances_read_access to the user
3. Add sample data to global tenant
4. Log in as the normal user, go to sample dashboard
5. Click reporting context menu, reports can be generated
6. Click "Create report definition" or "View reports", page redirects to .../app/reports-dashboards#/ and shows "Application Not Found"

What is the expected behavior?
Buttons don't work should be hidden from users.

What is your host/environment?

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

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
This problem exists for dashboards core buttons as well. For example under the same security config, if user clicks "Edit" and "Edit visualization" on any visualization in the dashboard, they will get redirected to Visualize which says "Application Not Found".

come from https://forum.opensearch.org/t/reporting-feature-doesnt-work/9632.

Is your feature request related to a problem?
yes, https://forum.opensearch.org/t/reporting-feature-doesnt-work/9632
What solution would you like?
reporting should use the configure instead of harding code to .kibana.

What alternatives have you considered?
no
Do you have any additional context?
none

Received Error: Error building reportsDashboards, retry with: ./build.sh manifests/1.3.13/opensearch-dashboards-1.3.13.yml --component reportsDashboards.
The distribution build for reportsDashboards has failed for version: 1.3.13.
Please see build log at https://build.ci.opensearch.org/job/distribution-build-opensearch-dashboards/6586/consoleFull

What is the bug?
Create a pdf or png report of the sample flights dashboard, visualizations with y-axis labels on top would get cutoff.

For example the delay type panel:

Is your feature request related to a problem?
Please onboard to functional test repo for catching dependency issues on dashboards

Need Download CSV option in Saved Search

Hi all Right now we can go & download saved search from discover tab.
But incase I'm including Saved search in my dashboard, I do not have option to download saved search.
In case I click on Gear option on right side of saved search in a dasboard, I can only see Inspect & Maximise window. There is no option to download as CSV.

Opensearch Version
1.2.0

Dashboards Version
1.2.0

Describe the solution you'd like

Include a Download as CSV option for saved search when we include it in dashboard.
Will be greatly helpful as we are using data tables . If we use saved search, it will be faster & easier to download.
Download CSV should also have ability more than 10,000 rows/documents of data.

Current View:
Current view in Opensearch in download option in Dashboard

Expected view
Required view in download option in Dashboard. Currently the below feature is from Kibana.