[Reporting] Catalog of Reporting Tech Debt

[tsullivan]

This issue is to track low-priority work that could be time consuming but still needs to be done at some point.

• Angular router is used in the public management view
• Integration concerns of Kibana App features, especially Discover / Saved Search CSV, need to be moved to Kibana App ownership.
• Logic to flatten hits from saved search into CSV (server-side only) needs to be unified with Discover (front-end-only)
• Immediate generation of CSV is not a Reporting feature. Reporting export types should always be async/queued.
• Make print_layout an abstraction of the Dashboard PDF integration. It's just a different mode of screenshot, and the layout changes needed are specific to Dashboard.
• Translations for all log messages
• Smaller and more isolated functional tests for each visualization type.
  • Remove expectation of parallelized job running from functional tests: Reporting jobs can stack up, but don't execute in parallel.
• Automated tests on the generation APIs should validate the jobs they are queuing get completed successfully.
• Move reporting/export_types to reporting/server/export_types to follow ESLint import rule: https://github.com/elastic/kibana/blob/01dd08e/x-pack/legacy/plugins/reporting/export_types/csv_from_savedobject/server/lib/generate_csv_search.ts#L29
• Organize types in to server public common and move them to NP as much as possible
• PDF creation leads to inconsistent data model of pending jobs. PDF jobs have an internal objects structure for storing the multiple relative URLs and doing so makes the flow inconsistent with PNG, where there is a better working data model. [Reporting/Legacy] Remove reporting legacy job params compatibility shim #52539
• More unit testing and functional testing needed for PNG creation Getting flaky tests back in shape for reporting #46076

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[alexfrancoeur]

@tsullivan this is a great list. I wanted to add a comment around this bullet point

Integration concerns of Kibana App features, especially Discover / Saved Search CSV, need to be moved to Kibana App ownership.

As we think through a solution here, I'd like to also think about how solutions could use reporting as a service in the future. Once we have the ability to easily schedule reports, I imagine different solutions will want to take advantage of this as well. So if we end up pushing ownership of some of these features down to the applications themselves, it'd be good to come up with a process that can be re-used across all applications, not just core Kibana apps.

[tsullivan]

@alexfrancoeur you make a good point that when Reporting is more of a service, we need new integrations to happen smoothly. That will get us to a place where we can manage many more integrations. There are definitely things that the Reporting Services team will have to provide to make sure that smoothness happens.

A big one in my mind is to have the Reporting Services team provide some test tools that will make automated functional testing easier.

So if we end up pushing ownership of some of these features down to the applications themselves, it'd be good to come up with a process that can be re-used across all applications, not just core Kibana apps.

The work that needs to be done will end up streamlining the Reporting code a bit. We'll remove the layout-manipulating logic we have today that "fixes" the layout for Reporting, and replace it with solutions that will benefit Kibana as a whole:

• better print-media styles
• a URL pattern that can load any Kibana page in an "export-friendly" way, using server-side rendering as an optimization shortcut.

For integrating with Reporting Services, we want to be able to allow the applications to just send simple parameters, and we'll deliver a screenshot response. The parameters just have to be enough information to re-play the page with the user state. It can work great when the URL carries the entire user state, because URL can be the only parameter and Kibana will automatically render correctly. However, that ability depends on how the application was built.

[tsullivan]

I crossed off 2 small items off the list.

We have an RFC as a proposal for how to solve some of these problems: #59084. Having this service would eliminate:

• Integration concerns of Kibana App features, especially Discover / Saved Search CSV, need to be moved to Kibana App ownership.
• Make print_layout an abstraction of the Dashboard PDF integration. It's just a different mode of screenshot, and the layout changes needed are specific to Dashboard.

[tsullivan]

The low fruit of this issue is:

• Move reporting/export_types to reporting/server/export_types
• Organize types in to server public common` and move them to NP as much as possible

[tsullivan]

I'm going to close this.

The concerns about tech debt that we had when this issue was filed have been greatly reduced by the new platform migration, and cleaning up Typescript and other refactoring to prepare for migrating to Task Manager.

Reporting team is now part of App Arch team in Kibana, so the remaining items now have better visibility among engineers that can help.