Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Reporting] [Dashboard] Use ViewMode Only When Printing #6

Conversation

ThomThomson
Copy link

Summary

Hopefully I'm not totally on the wrong track here, but I've updated the POC PR to use the new Print View Mode only, rather than another route. Additionally I have removed the copied code from the print viewport,

You can see this print mode without generating a PDF / PNG by adding &_a=(viewMode:print) onto the end of the dashboard URL. This does require a hard reload. This viewMode will be saved into session storage and persisted over migrations / reloads, so to leave it you have to inject &a=(viewMode:view) into the URL. Again, a hard refresh will be required to make the panels load again.

Checklist

Delete any items that are not applicable to this PR.

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk Probability Severity Mitigation/Notes
Multiple Spaces—unexpected behavior in non-default Kibana Space. Low High Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces.
Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. High Low Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure.
Code should gracefully handle cases when feature X or plugin Y are disabled. Medium High Unit tests will verify that any feature flag or plugin combination still results in our service operational.
See more potential risk examples

For maintainers

Copy link
Owner

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking great, thanks for making these simplifying changes man!

@jloleysens jloleysens merged commit 6aef414 into jloleysens:reporting/poc-migrate-away-from-injected-css-js Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants