f08005e0e7
* very wip * - Reached first iteration of reporting body value being saved with the report for **PDF** - Removed v2 of the reporting since it looks like we may be able to make a backwards compatible change on existing PDF/PNG exports * reintroduced pdfv2 export type, see https://github.com/elastic/kibana/issues/99890\#issuecomment-851527878 * fix a whol bunch of imports * mapped out a working version for pdf * refactor to tuples * added v2 pdf to export type registry * a lot of hackery to get reports generated in v2 * added png v2, png reports with locator state * wip: refactored for loading the saved object on the redirect app URL * major wip: initial stages of reporting redirect app, need to add a way to generate v2 reports! * added a way to generate a v2 pdf from the example reporting plugin * updated reporting example app to read and accept forwarded app state * added reporting locator and updated server-side route to not use Boom * removed reporting locator for now, first iteration of reports being generated using the reporting redirect app * version with PNG working * moved png/v2 -> png_v2 * moved printable_pdf/v2 -> printable_pdf_v2 * updated share public setup and start mocks * fix types after merging master * locator -> locatorParams AND added a new endpoint for getting locator params to client * fix type import * fix types * clean up bad imports * forceNow required on v2 payloads * reworked create job interface for PNG task payload and updated consumer code report example for forcenow * put locatorparams[] back onto the reportsource interface because on baseparams it conflicts with the different export type params * move getCustomLogo and generatePng to common for export types * additional import fixes * urls -> url * chore: fix and update types and fix jest import mocks * - refactored v2 behaviour to avoid client-side request for locator instead this value is injected pre-page-load so that the redirect app can use it - refactored the interface for the getScreenshot observable factory. specifically we now expect 'urlsOrUrlTuples' to be passed in. tested with new and old report types. * updated the reporting example app to use locator migration for v2 report types * added functionality for setting forceNow * added forceNow to job payload for v2 report types and fixed shared components for v2 * write the output of v2 reports to stream * fix types for forceNow * added tests for execute job * added comments, organized imports, removed selectors from report params * fix some type issues * feedback: removed duplicated PDF code, cleaned screenshot observable function and other minor tweaks * use variable (not destructured values) and remove unused import Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| common | ||
| public | ||
| kibana.json | ||
| README.md | ||
| tsconfig.json | ||
Example Reporting integration!
Use this example code to understand how to add a "Generate Report" button to a Kibana page. This simple example shows that the end-to-end functionality of generating a screenshot report of a page just requires you to render a React component that you import from the Reportinng plugin.
A "reportable" Kibana page is one that has an alternate version to show the data in a "screenshot-friendly" way. The alternate version can be reached at a variation of the page's URL that the App team builds.
A "screenshot-friendly" page has all interactive features turned off. These are typically notifications, popups, tooltips, controls, autocomplete libraries, etc.
Turning off these features keeps glitches out of the screenshot, and makes the server-side headless browser run faster and use less RAM.
The URL that Reporting captures is controlled by the application, is a part of a "jobParams" object that gets passed to the React component imported from Reporting. The job params give the app control over the end-resulting report:
- Layout
- Page dimensions
- DOM attributes to select where the visualization container(s) is/are. The App team must add the attributes to DOM elements in their app.
- DOM events that the page fires off and signals when the rendering is done. The App team must implement triggering the DOM events around rendering the data in their app.
- Export type definition
- Processes the jobParams into output data, which is stored in Elasticsearch in the Reporting system index.
- Export type definitions are registered with the Reporting plugin at setup time.
The existing export type definitions are PDF, PNG, and CSV. They should be enough for nearly any use case.
If the existing options are too limited for a future use case, the AppServices team can assist the App team to implement a custom export type definition of their own, and register it using the Reporting plugin API (documentation coming soon).