Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19584

Ability to redirect user to configuration screen when erroneous data is saved

    Details

    • Similar Issues:

      Description

      When a user enters erroneous data in the configuration screen and hits Save, we should be able to redirect the user back to the page and display a user-friendly error message.

      This becomes relevant if the user pastes data into a field and hits Save or simply ignores the UI error message. See JENKINS-19582 for an example.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            If there is no workspace, validateFileMask reports ok() as you would expect. The error status should be reserved for cases where the validation method is reasonably sure something is actually wrong.

            However any logic driven off FormValidation would really have to look for warnings, too, since for example a blank required field is normally shown as a warning rather than an error under the expectation that the user is about to fill it in and just has not gotten there yet and showing a red mark on a freshly loaded form is impolite. Not sure if we can defer validation checks until after the field has gotten focus, or if we could introduce a status which is logically like ERROR yet is displayed in a more toned-down UI that merely indicates that a field is required, not that you did something wrong.

            I like the idea of showing a dialog when Save (or Apply) is clicked, which shows a list of outstanding warnings and errors.

            Show
            jglick Jesse Glick added a comment - If there is no workspace, validateFileMask reports ok() as you would expect. The error status should be reserved for cases where the validation method is reasonably sure something is actually wrong. However any logic driven off FormValidation would really have to look for warnings, too, since for example a blank required field is normally shown as a warning rather than an error under the expectation that the user is about to fill it in and just has not gotten there yet and showing a red mark on a freshly loaded form is impolite. Not sure if we can defer validation checks until after the field has gotten focus, or if we could introduce a status which is logically like ERROR yet is displayed in a more toned-down UI that merely indicates that a field is required, not that you did something wrong. I like the idea of showing a dialog when Save (or Apply ) is clicked, which shows a list of outstanding warnings and errors.
            Hide
            danielbeck Daniel Beck added a comment -

            Jesse Glick:

            The error status should be reserved for cases where the validation method is reasonably sure something is actually wrong.

            Right, wrote that comment without double-checking the conditions. But it still happens a lot for me: builds in progress (updating publishers while the build is already in progress works nicely ), selectively cleaned up workspaces using Workspace Cleanup, and jobs that already ran but are getting reconfigured to create new files. I guess we'll need to see how bad a change like this would be in practice.

            Show
            danielbeck Daniel Beck added a comment - Jesse Glick : The error status should be reserved for cases where the validation method is reasonably sure something is actually wrong. Right, wrote that comment without double-checking the conditions. But it still happens a lot for me: builds in progress (updating publishers while the build is already in progress works nicely ), selectively cleaned up workspaces using Workspace Cleanup, and jobs that already ran but are getting reconfigured to create new files. I guess we'll need to see how bad a change like this would be in practice.
            Hide
            jglick Jesse Glick added a comment -

            True, even with a best effort there can be false positives from things like checkFileMask. So a dialog listing possible problems would be a good compromise. You could use your own judgement whether the warning/error was meaningful or not. Obviously the code handling the form submission still needs to be written defensively, but it could feel free to just throw an exception if it cannot proceed meaningfully, for example if it expects to store something in a URL-valued field but a malformed URL was entered—whereas without a feature like this there would be pressure to quietly ignore the problem when the form was saved.

            Show
            jglick Jesse Glick added a comment - True, even with a best effort there can be false positives from things like checkFileMask . So a dialog listing possible problems would be a good compromise. You could use your own judgement whether the warning/error was meaningful or not. Obviously the code handling the form submission still needs to be written defensively, but it could feel free to just throw an exception if it cannot proceed meaningfully, for example if it expects to store something in a URL -valued field but a malformed URL was entered—whereas without a feature like this there would be pressure to quietly ignore the problem when the form was saved.
            Hide
            rsandell rsandell added a comment -

            According to the javadoc of FormValidation, hudson.model.Failure and hudson.model.Descriptor.FormException; throwing any of those should display a user friendly error page, perhaps tweaking those to be able to go back to the correct form state could at least approve things.
            Although when I try to throw a hudson.model.Failure I get the standard oops page instead of a "nicer" error page.

            Show
            rsandell rsandell added a comment - According to the javadoc of FormValidation, hudson.model.Failure and hudson.model.Descriptor.FormException; throwing any of those should display a user friendly error page, perhaps tweaking those to be able to go back to the correct form state could at least approve things. Although when I try to throw a hudson.model.Failure I get the standard oops page instead of a "nicer" error page.
            Hide
            jglick Jesse Glick added a comment -

            I wonder if it would work to send a 204 response to prevent the browser from rendering any page from configSubmit, so that the form with pending modifications remains open and available for amendment. (Combined with some other mechanism for displaying a popup warning to the user that the submission was rejected.) Not perfect—some form field changes might have actually been applied before Jenkins got to the erroneous one—but better than the current behavior.

            Show
            jglick Jesse Glick added a comment - I wonder if it would work to send a 204 response to prevent the browser from rendering any page from configSubmit , so that the form with pending modifications remains open and available for amendment. (Combined with some other mechanism for displaying a popup warning to the user that the submission was rejected.) Not perfect—some form field changes might have actually been applied before Jenkins got to the erroneous one—but better than the current behavior.

              People

              • Assignee:
                Unassigned
                Reporter:
                cowwoc cowwoc
              • Votes:
                8 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated: