You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current editing behavior (not allowing edits on particular fields when the job is not stopped) is consistent with anomaly explorer jobs as well. Could force stopping a job under the hood perhaps lead to unintended side effects? Unintended on the users' side if they don't understand exactly what that entails.
It might be best to show a Stop job or Force stop job button that the user has to explicitly interact with in order to be able to then edit the fields. Then we could also add a tooltip or warning text.
Another reason for allowing user to force stop a failed-job from the UI:
When using least privileges in a Kibana Space, a user who has been granted All Machine Learning Kibana Space privilege cannot revert to using the Dev Console to _stop?force a job that has failed.
In order to do this, they would need to be granted machine_learning_admin elasticsearch privileges as well as having Dev Tools Space privilege.
The current editing behavior (not allowing edits on particular fields when the job is not stopped) is consistent with anomaly explorer jobs as well. Could force stopping a job under the hood perhaps lead to unintended side effects? Unintended on the users' side if they don't understand exactly what that entails.
It might be best to show a Stop job or Force stop job button that the user has to explicitly interact with in order to be able to then edit the fields. Then we could also add a tooltip or warning text.
cc @alvarezmelissa87
The text was updated successfully, but these errors were encountered: