[Dashboard] Capture & Communicate Panel Migrations

[ThomThomson]

When a dashboard has legacy panels injected through the URL, migrations are run on the panel shape if they were last saved on a version before 7.3.0.

There are a number of inconsistencies with how the migrations work:

• While the migrations should be run on any panel <7.3.0, sometimes the migrations aren't run. Specifically, 7.0.0-alpha is not considered to be <7.3
• If the migrations are run, the version numbers on the panels get replaced with the current version - this means that the dashboard diffing wouldn’t find any differences between the last saved panels and the current panels, and it wouldn’t prompt the user to save.
• When the migrations aren’t run, but the panels were last saved on a slightly older version, 7.4.0 for example, the version numbers on the panels don’t get updated, and the dashboard notices the differences in version number and prompts the user to save - even though no migrations were actually run.

There are some open questions on how we communicate this:

• Should these migrations be considered "under the hood" and therefore shouldn't be communicated at all?
• Is there any case where a user would want to see the version their panels were last saved in?

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[ryankeairns]

There are some open questions on how we communicate this:

Should these migrations be considered "under the hood" and therefore shouldn't be communicated at all?
Is there any case where a user would want to see the version their panels were last saved in?

My inclination is that this should be "under the hood". Follow up questions that come to mind are:

• Is there any significant visual or functional difference once a migration happens?
• Is there any means to prevent the migration? I'm not proposing there should be, rather if I - as a user - can't do anything about it, then why even bother me with it?
• Do I have to manually save it? Could these just auto-save as part of the migration?

If it is useful information that I, personally, am just not grokking, then I wonder if a toast message would be more appropriate. It could even have an action on it to accept or apply the migration.

All in all, I would favor a transparent process that hides all this terminology and does not require action on my part... presuming there is no real visual or functional impact and that I can't stop it anyway.

[ThomThomson]

@ryankeairns I totally agree with your read of the situation. Here are some answers to your questions:

• Is there any significant visual or functional difference once a migration happens?
  The migrations should be totally seamless

• Is there any means to prevent the migration?
  There is currently no way to prevent this from happening. Further, because migrations are necessary to align saved state with the current dashboard code, there should never be a way to prevent them.

• Do I have to manually save it? Could these just auto-save as part of the migration?
  Yes and no - you do have to manually save the dashboard in order for the migrated state to be saved back into the saved object, but if you decide not to save it, the migration will just be run seamlessly each time the dashboard is loaded.

So far, the plan is to ensure that nothing except for direct user action ever causes the unsaved changes badge to appear. Panel migrations from any version will be silent and behind the scenes. Once this PR is merged #97941 and this issue #98180 is fixed, this will be the case.

@stacey-gammon @kmartastic for visibility.

Note: If we ever decide to remove snapshot URL support, we will also be able to remove these clientside dashboard panel migrations along with them which will greatly simplify the dashboard code.