[ML] Edit datafeed usability issues

[sophiec20]

Found in 7.7.0

I wanted to clone a job, keeping the complex datafeed query whilst narrowing the scope of the index pattern.

The UI let me think I could do this for a while, without warning me that I couldn't. It was a frustrating user experience.

Steps to replicate

1. Create two kibana index patterns filebeat-* and filebeat-7* (data should exist)
2. Create job using filebeat-*
3. Clone this job
4. Click Edit JSON
5. Edit text to change index pattern from filebeat-* to filebeat-7*

The save button is not enabled, therefore I cannot apply the change.
Both exist as kibana index patterns.

Usability issues:

1. When trying to Edit JSON, there is no useful error message for the user as to why they cannot apply changes to the index pattern.
2. A user cannot tell which index pattern is configured (without clicking on Edit JSON) which is useful information in the clone scenario. It is also missing from the final summary page and it was a long time since pattern was selected, so would be good to display it here also.
3. A user cannot pick another index pattern, even one that is a Kibana index pattern and valid for this space
4. When editing JSON, the Save button switches between being enabled and disabled, depending on whether it is valid JSON and if the index pattern has changed. It does not check if it is valid for a datafeed query, so a user can spend a lot of time editing something that will never work. Enabling the Save button gives a misleading sense that the syntax is correct. Can we improve the UX here and include some encouragement to click on preview to check the sytnax is correct.
5. If the user accidentally messes up their datafeed query, it would be useful to be able to reset it back to match_all so they can start again.

There may be some other good reasons for not allowing [3], however usability points [1], [2] ,[4] and [5] could still be addressed.

[elasticmachine]

Pinging @elastic/ml-ui (:ml)

[peteharverson]

The usability points [1], [2] ,[4] and [5] are all good and valid, and we will look to address these.

Note that with point [3], preventing the user editing the index for the datafeed, was a deliberate design choice when the wizard was created. A change to the datafeed indices might result in making large portions of the job config invalid (detectors, influencers, categorization field etc) with fields not existing in the new index pattern, or being of a different data type. Addressing this will be a much more significant piece of work - for example by comparing the list of fields and field types in the original and new choice of index, and if the mappings were the same, as in the use case described above, allowing the edit. However in the meantime, addressing point [1] above, to provide clear messaging on why the datafeed indices cannot be edited, will hopefully alleviate some of the frustration.

[peteharverson]

Point 2 above has been addressed for 7.9.0 by #72400 to add the index pattern name to the top of the job wizards.

[peteharverson]

Closing as the usability issues have been addressed by #72400 (7.9.0), #72117 and #73958 (7.10.0).