[Reporting] Save before generating report

[elasticmachine]

Original comment by @kobelb:

Currently, the user is required to save all Visualizations/Saved Searches/Dashboard before they are able to generate a PDF or CSV. This can be rather frustrating to the end-user, and there are a few things we can do to improve the user experience.

Option 1 - no more saving, export whenever

This is presently easily possible as long as all of the state for the various applications are stored in the URL. However, there has been discussion about no longer doing so and only allowing saved objects to be shared. If this is in the immediate future, relaxing this requirement temporarily could introduce even more pain down the road because we'd be taking away something that we gave the end-users for a short period of time.

There are a few approaches that I've thought of to make this work even if the state isn't in the URL; however, they are much more time-consuming and alter the way that Reporting works fundamentally. If anyone else has any ideas to facilitate this process without required significant effort, please share!

Option 2 - guide user through this process

Currently, there is a rather bare-bones message that is displayed to the user prompting them that they need to save, and this can be rather jarring:

Perhaps improving this experience and guiding them through the process would be a sufficient enough improvement? @snide do you have any guidance on what we can do to make this more obvious?

Option 3 - export to csv no longer requires saving

Technically, it's possible for us to export to csv without requiring the user to save regardless of the save being in the URL or not; however, it's currently being done for consistency with PDFs. It's possible for us to relax this requirement only for CSVs regardless of the decision made for PDFs.

[elasticmachine]

Original comment by @kobelb:

@jimgoodwin @stacey-gammon @alexfrancoeur @timroes

[elasticmachine]

Original comment by @stacey-gammon:

Note that the hesitancy on the first option is due to this issue: LINK REDACTED We tossed around the idea about not allowing sharing unsaved objects, but after hearing from one, very active, community member, I think this would cause a lot of frustration by our users.

So I'm leaning towards 1. I think we need to solve the too long urls a different way, not by disallowing sharing unsaved objects.

[elasticmachine]

Original comment by @snide:

If it requires save, the simplest thing you can do is link the text you have there to the actual save mechanism rather than just hinting at it.

[elasticmachine]

Original comment by @alexfrancoeur:

From a user experience and consistency perspective, option 1 makes the most sense. I do understand the concerns stated in #12369 and the last thing we'll want to do is lax the save requirement for reporting only to re-introduce later. I think we need to determine if we'll be going down this route any time soon. It sounded to me like a non-trivial effort and at least immediately, not a priority. If that is determined otherwise, I think option LINK REDACTED with Dave's suggestion will go a long way.

The fact that we are using the URL directly made me think of the state:storeInSessionStorage option available in Advanced Settings. Is reporting already able to create reports with session storage if this is enabled? If not, we'd have to understand how this would work. I would think Watcher still uses and needs the full URL.

[tomhe]

Please also consider the case where the user wants a CSV export from a Discover search, but where the user has read-only access to the Kibana index and has no way to save the search.

[tsullivan]

@elastic/kibana-app let's revive this discussion. It's pertinent to a Reporting Breakout chat we had today.

Option 1 - no more saving, export whenever
There are a few approaches that I've thought of to make this work even if the state isn't in the URL; however, they are much more time-consuming and alter the way that Reporting works fundamentally. If anyone else has any ideas to facilitate this process without required significant effort, please share!

I'm leaning towards 1. I think we need to solve the too long urls a different way

I feel like we landed on an experience that we'd like to have, but stopped short of discussing what would need to change to support it.

Also, it sounds like users are feeling special pain on CSV experience, in other words Option 3 could be a small win, even if it raises an inconsistent experience for CSV vs PDF/PNG.

[tsullivan]

However, there has been discussion about no longer doing so and only allowing saved objects to be shared

This discussion hasn't been continuing to my knowledge.

Technically, it's possible for us to export to csv without requiring the user to save regardless of the save being in the URL or not; however, it's currently being done for consistency with PDFs

PDF and CSV are generated with different endpoints, but they share behavior and both work off the state of the URL (generate_from_jobparams). Using the saved object ID to generate a report only exists for backwards-compatibility with POST URLs that were created in older versions.

There aren't any barriers for Option 3, and even Option 1. The limitations stated about Option 1 aren't applicable in any for today's integrations so we're fine as long as new integrations stick with the status quo.

To be clear, the status quo for generate_from_jobparams integrations today is:

• Populate an array of relativeUrls in the jobParams posted to the generation URL.
• If that integration doesn't work, it's not a generate_from_jobparams integration. They can define a new export_type and add a new generation endpoint to create those kinds of jobs.

I'd like to add this to the roadmap, going in after re-platforming, the ongoing performance improvement work, and scheduling. I imagine it will be small work, so perhaps the work could come from outside of @elastic/kibana-stack-services.

cc @kobelb @stacey-gammon @joelgriffith @bmcconaghy Hope you can give a 👍 to this :)

[tsullivan]

cc @dtuck9

[elasticmachine]

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

[TuemmlerKelch]

Are there any updates on this? I would really love to see this feature implemented.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[jloleysens]

The limitations stated about Option 1 aren't applicable in any for today's integrations so we're fine as long as new integrations stick with the status quo.

Would it be desirable to, in certain cases, uncouple page state from the URL. This puts us back in the position of needing to save non-CSV reports first, however we can still help users out by offering to "Save and generate", something like:

I guess the primary question for me is whether the real pain point here is just having to click more than once to generate a PDF, or do we explicitly want to avoid having to save at all. I think if it is the former we can solve this by just updating the UI and doing two steps in one.

[TuemmlerKelch]

My issue with having to save those searches is that our infrastructure is bloated with saved searches that were only needed once, because most people forget to delete those.
It might be a feasible workaround to implement a button that says: "generate PDF" while in the background it's doing the following:

1. save search temporary name
2. create report
3. delete search after report creation

[tsullivan]

My issue with having to save those searches is that our infrastructure is bloated with saved searches that were only needed once, because most people forget to delete those.

Just FYI, there is a separate issue to cover Reporting system indices with a built-in Index Lifecycle Management policy: #81544. This will help when users do not remember to delete reports that are no longer needed. Creating an ILM policy for reporting is possible today, but this issue will make it easier to enable out-of-the box.

[tsullivan]

It might be a feasible workaround to implement a button that says: "generate PDF" while in the background it's doing the following:

1. save search temporary name
2. create report
3. delete search after report creation

We could re-use the screenshot generation code in a new endpoint that simply generates the PNG/PDF data and returns it for the initial request. We did this for CSV export as the "Download CSV" button in the sharing menu of a saved search panel embedded in a dashboard. It sounds like it would really help to standardize something like that for the PNG and PDF report types as well.

That's a separate feature, but still it should align with the main idea behind this issue: make it so that you don't have to save the dashboard before downloading a PNG or PDF.

[tsullivan]

Closed in #108553