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

Broken form validation with stapler

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • core
    • None

      There is an issue with stapler form validation under some specific circumstances.
      See the attached sample plugin. To reproduce the issue:

      1. Run the plugin with `mvn hpi:run`
      2. Create a new item, select "TestItem"
      3. Initial value of "Executors" is 0, even when `default` is set to 1
      4. Try change the value to any positive number, move focus out of the field to trigger a validation
      5. Nothing happens, validation message is still there.

      I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

      1. In the sample code, if I remove the line `<j:set var="descriptor" value="${it.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`) UPDATE: this makes it work because the backend validation is disabled with this (there isn't a descriptor by default so backend `doCheck****` is not called, so only front end validation is in place, which makes it work.

      Or:

      1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor). If one of the validation is removed (either front or back) then it works fine too.

      BTW, this was working fine in older versions of core (2.263 at least).

        1. demo.zip
          10 kB

          [JENKINS-64651] Broken form validation with stapler

          Antonio Muñiz created issue -
          Antonio Muñiz made changes -
          Attachment New: demo.zip [ 53843 ]
          Antonio Muñiz made changes -
          Description Original: There is an issue with stapler form validation under some specific circumstances.
          See the attached sample plugin. To reproduce the issue:

          1. Run the plugin with `mvn hpi:run`
          2. Create a new item, select "TestItem"
          3. Initial value of "Executors" is 0, even when `default` is set to 1
          4. Try change the value to any positive number, move focus out of the field to trigger a validation
          5. Nothing happens, validation message is still there.

          I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

          1. In the sample code, if I remove the line `<j:set var="descriptor" value="${instance.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`.

          Or:

          1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor. If one of the validation is removed (either front or back) then it works fine too.

          BTW, this was working fine in older versions of core (2.263 at least).           		New: There is an issue with stapler form validation under some specific circumstances.
          See the attached sample plugin. To reproduce the issue:

          1. Run the plugin with `mvn hpi:run`
          2. Create a new item, select "TestItem"
          3. Initial value of "Executors" is 0, even when `default` is set to 1
          4. Try change the value to any positive number, move focus out of the field to trigger a validation
          5. Nothing happens, validation message is still there.

          I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

          1. In the sample code, if I remove the line `<j:set var="descriptor" value="${it.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`.

          Or:

          1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor. If one of the validation is removed (either front or back) then it works fine too.

          Workaround 1 is not always applicable, as the set var pattern is commonly used to set the descriptor to the right value so it's used by other components, ie. `f:validateButton`, etc

          BTW, this was working fine in older versions of core (2.263 at least).
          Antonio Muñiz made changes -
          Description Original: There is an issue with stapler form validation under some specific circumstances.
          See the attached sample plugin. To reproduce the issue:

          1. Run the plugin with `mvn hpi:run`
          2. Create a new item, select "TestItem"
          3. Initial value of "Executors" is 0, even when `default` is set to 1
          4. Try change the value to any positive number, move focus out of the field to trigger a validation
          5. Nothing happens, validation message is still there.

          I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

          1. In the sample code, if I remove the line `<j:set var="descriptor" value="${it.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`.

          Or:

          1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor. If one of the validation is removed (either front or back) then it works fine too.

          Workaround 1 is not always applicable, as the set var pattern is commonly used to set the descriptor to the right value so it's used by other components, ie. `f:validateButton`, etc

          BTW, this was working fine in older versions of core (2.263 at least).           		New: There is an issue with stapler form validation under some specific circumstances.
          See the attached sample plugin. To reproduce the issue:

          1. Run the plugin with `mvn hpi:run`
          2. Create a new item, select "TestItem"
          3. Initial value of "Executors" is 0, even when `default` is set to 1
          4. Try change the value to any positive number, move focus out of the field to trigger a validation
          5. Nothing happens, validation message is still there.

          I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

          1. In the sample code, if I remove the line `<j:set var="descriptor" value="${it.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`)

          Or:

          1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor). If one of the validation is removed (either front or back) then it works fine too.

          Workaround 1 is not always applicable, as the set var pattern is commonly used to set the descriptor to the right value so it's used by other components, ie. `f:validateButton`, etc

          BTW, this was working fine in older versions of core (2.263 at least).
          Antonio Muñiz made changes -
          Description Original: There is an issue with stapler form validation under some specific circumstances.
          See the attached sample plugin. To reproduce the issue:

          1. Run the plugin with `mvn hpi:run`
          2. Create a new item, select "TestItem"
          3. Initial value of "Executors" is 0, even when `default` is set to 1
          4. Try change the value to any positive number, move focus out of the field to trigger a validation
          5. Nothing happens, validation message is still there.

          I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

          1. In the sample code, if I remove the line `<j:set var="descriptor" value="${it.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`)

          Or:

          1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor). If one of the validation is removed (either front or back) then it works fine too.

          Workaround 1 is not always applicable, as the set var pattern is commonly used to set the descriptor to the right value so it's used by other components, ie. `f:validateButton`, etc

          BTW, this was working fine in older versions of core (2.263 at least).           		New: There is an issue with stapler form validation under some specific circumstances.
          See the attached sample plugin. To reproduce the issue:

          1. Run the plugin with `mvn hpi:run`
          2. Create a new item, select "TestItem"
          3. Initial value of "Executors" is 0, even when `default` is set to 1
          4. Try change the value to any positive number, move focus out of the field to trigger a validation
          5. Nothing happens, validation message is still there.

          I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

          1. In the sample code, if I remove the line `<j:set var="descriptor" value="${it.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`)

          Or:

          1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor). If one of the validation is removed (either front or back) then it works fine too.

          Workaround 1 is not always applicable, as the set var pattern is [commonly used to set the descriptor to the right value|https://github.com/search?q=org%3Ajenkinsci+%3Cj%3Aset+var%3D%22descriptor%22+value%3D%22%24%7Binstance.descriptor%7D%22+%2F%3E&type=code] so it's used by other components, ie. `f:validateButton`, etc

          BTW, this was working fine in older versions of core (2.263 at least).
          Antonio Muñiz made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]

          Oleg Nenashev added a comment -

          It is likely related to JENKINS-64439 in 2.274

          Oleg Nenashev added a comment - It is likely related to  JENKINS-64439 in 2.274
          Oleg Nenashev made changes -
          Link New: This issue relates to JENKINS-64439 [ JENKINS-64439 ]
          Antonio Muñiz made changes -
          Link New: This issue is related to JENKINS-64429 [ JENKINS-64429 ]
          Antonio Muñiz made changes -
          Description Original: There is an issue with stapler form validation under some specific circumstances.
          See the attached sample plugin. To reproduce the issue:

          1. Run the plugin with `mvn hpi:run`
          2. Create a new item, select "TestItem"
          3. Initial value of "Executors" is 0, even when `default` is set to 1
          4. Try change the value to any positive number, move focus out of the field to trigger a validation
          5. Nothing happens, validation message is still there.

          I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

          1. In the sample code, if I remove the line `<j:set var="descriptor" value="${it.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`)

          Or:

          1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor). If one of the validation is removed (either front or back) then it works fine too.

          Workaround 1 is not always applicable, as the set var pattern is [commonly used to set the descriptor to the right value|https://github.com/search?q=org%3Ajenkinsci+%3Cj%3Aset+var%3D%22descriptor%22+value%3D%22%24%7Binstance.descriptor%7D%22+%2F%3E&type=code] so it's used by other components, ie. `f:validateButton`, etc

          BTW, this was working fine in older versions of core (2.263 at least).           		New: There is an issue with stapler form validation under some specific circumstances.
          See the attached sample plugin. To reproduce the issue:

          1. Run the plugin with `mvn hpi:run`
          2. Create a new item, select "TestItem"
          3. Initial value of "Executors" is 0, even when `default` is set to 1
          4. Try change the value to any positive number, move focus out of the field to trigger a validation
          5. Nothing happens, validation message is still there.

          I haven't been able to identify the root cause, but I've reproduced some interesting behaviours locally:

          1. In the sample code, if I remove the line `<j:set var="descriptor" value="${it.descriptor}" />` then it works fine (it also works fine if the var name is set something different than `descriptor`) - **UPDATE**: this makes it work because the backend validation is disabled with this (there isn't a descriptor by default so backend `doCheck****` is not called, so only front end validation is in place, which makes it wor.

          Or:

          1. The sample plugin has validation for `numExecutors` on both frontend (using `class="positive-number"` and backend using a `doCheckNumExecutors` method in the descriptor). If one of the validation is removed (either front or back) then it works fine too.

          Workaround 1 is not always applicable, as the set var pattern is [commonly used to set the descriptor to the right value|https://github.com/search?q=org%3Ajenkinsci+%3Cj%3Aset+var%3D%22descriptor%22+value%3D%22%24%7Binstance.descriptor%7D%22+%2F%3E&type=code] so it's used by other components, ie. `f:validateButton`, etc

          BTW, this was working fine in older versions of core (2.263 at least).

            fqueiruga Félix Queiruga Balado
            amuniz Antonio Muñiz
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: