[Discover] Unsaved work error on CSV reports for read-only user

[cqliu1]

Kibana version:
8.7.0

Elasticsearch version:
8.7.0

Server OS version:
cloud

Browser version:
safari

Browser OS version:
mac ventura 13.2

Original install method (e.g. download page, yum, from source, etc.):
cloud deployment

Describe the bug:
I'm getting a confusing error message when I go to the CSV report advanced options on a read-only user in Discover.

Steps to reproduce:

1. Log into a user with read only access to discover
2. Open Discover
3. Click Share
4. Click CSV Reports
5. Click Advanced options
6. Observe Unsaved work error

Expected behavior:
I'm not sure what the error message should say instead, but we shouldn't tell the user to save their work when they don't have access to save their search. It might be better to just hide the entire CSV report menu when the user doesn't have access to generate a CSV report.

Screenshots (if relevant):

Note: the toast error is from clicking Generate CSV which is expected.

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context:

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[tsullivan]

Related: #112156

[boskjoett]

We have this issue too. We have several Kibana dashboards that are read-only, because we don't want the user to be able to change them. When you initially open the dashboard the "Copy POST URL" button works fine.
If you change the Time Range you can no longer create a POST URL. It shows the error "Unsaved work".

It would be nice if you were able to change the Time Range on a read-only dashboard and still be able to generate a POST URL.

I believe this used to work in Kibana 7.x

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[Hubadova-F]

Adding also here, that we have reports of the same behaviour with Unsaved work errors for PDF reports, when the user has read-only privileges.

When dashboard is modified, we get the: "Unsaved work" when choosing the "Copy POST URL" in Kibana.

[tsullivan]

In 8.0, some changes came out for the Share functionality in Dashboard and Discover to prevent the POST URL from being copied when there are unsaved changes in the application state. This was done to a prevent subtle problem and a migration issue:

1. Subtle problems: if a POST URL is created that refers to a stored Saved Object; plus inline, static, unsaved state; it creates a "mixed state" that can lead to user confusion. The stored SO can be updated at any time, but the unsaved state encoded into the POST URL job parameters can only be updated with the POST URL is re-created. If the stored SO is updated, the POST URL no longer represents what it represented originally, but the static unsaved state still does. The solution: users should need to regenerate the POST URL any time the stored SO is updated. That would not be obvious to the user, as they would have to pay close attention to their reports to notice the issue.
2. Migration issues: if the schema of an application's Saved Object changes from one version to the next, the unsaved state never gets migrated to the new schema. Today, SO schemas are migrated in storage when Kibana boots up. When an application is requested to load state using the SO schema from an older version, it will break. The solution is the same: users would need to regenerate the POST URL whenever upgrading to a new version that uses a different schema for the SO.

The current configuration of the UI rules is intended to prevent these problems. However, if only the date range is changing and added as unsaved state in the POST URL, it definitely seems unlikely to cause either one of these. I'm not opposed to supporting POST URL creation for applications with unsaved changes, but there also needs to be some explanation in the UI about the problems it can cause.