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

Active Choices radio parameter has incorrect default value on parambuild URL

      Active Choice radio parameter on parambuild page is always visible as text box (which is fine). Unfortunately, the default value is set incorrectly. The plugin always fills the text box with the first value from the script and does not remove :selected suffix. It means that for the following script:

      ['1', '2', '3:selected', '4', '5']
      

      it returns 1, and for:

      ['1:selected', '2', '3', '4', '5']
      

      it returns 1:selected.

      This behavior makes radio button unusable when builds are triggered by Jenkins Pipeline build step or parambuild/buildWithParameters URLs.

        1. build-with-parameters.png
          build-with-parameters.png
          32 kB
        2. image-2020-03-09-15-50-25-634.png
          image-2020-03-09-15-50-25-634.png
          88 kB
        3. image-2020-03-10-09-32-13-452.png
          image-2020-03-10-09-32-13-452.png
          13 kB
        4. parambuild.png
          parambuild.png
          11 kB
        5. parameter-configuration.png
          parameter-configuration.png
          9 kB
        6. reference-parameter.gif
          reference-parameter.gif
          107 kB
        7. uno-choice.hpi
          248 kB
        8. view-build-with-parameters.png
          view-build-with-parameters.png
          43 kB
        9. view-parambuild.png
          view-parambuild.png
          20 kB

          [JENKINS-61068] Active Choices radio parameter has incorrect default value on parambuild URL

          Adam Gabryś added a comment -

          I created a pull request (PR #32) with the fix. Now it works as follow:

          Code Result Returns
          ['1:selected', '2', '3', '4', '5'] "1" the default value
          ['1', '2', '3:selected', '4', '5'] "3" the default value, no difference if it is first or last
          ['1', '2', '3', '4'] "1" the first element when (no values are marked as default)
          [] "" empty value (Jenkins cannot handle null)
          [""] "" the first element (no values are marked as default)
          ['1:selected', '2', '3:selected', '4'] "1,3" multiple values are checked, so all of them are added (consistent with Build with Parameters behavior)
          ['1', '2', ':selected', '4'] "" the empty element is marked as selected

          Adam Gabryś added a comment - I created a pull request ( PR #32 ) with the fix. Now it works as follow: Code Result Returns ['1:selected', '2', '3', '4', '5'] "1" the default value ['1', '2', '3:selected', '4', '5'] "3" the default value, no difference if it is first or last ['1', '2', '3', '4'] "1" the first element when (no values are marked as default) [] "" empty value (Jenkins cannot handle null) [""] "" the first element (no values are marked as default) ['1:selected', '2', '3:selected', '4'] "1,3" multiple values are checked, so all of them are added (consistent with Build with Parameters behavior) ['1', '2', ':selected', '4'] "" the empty element is marked as selected

          ioannis, attached the plugin hpi file for testing: uno-choice.hpi

          Bruno P. Kinoshita added a comment - ioannis , attached the plugin hpi file for testing: uno-choice.hpi

          Merged and added to the changelog for the next release. Thanks a lot agabrys!

          Bruno P. Kinoshita added a comment - Merged and added to the changelog for the next release. Thanks a lot agabrys !

          Ioannis Moutsatsos added a comment - - edited

          The 2.2.3 snapshot works. However, using Plugin v 2.1 and 2.2.2 I'm not able to reproduce the Jira issue as reported . In each case I get the correct default value selected. (see screenshot below)

          Nonetheless, I'm using older version of Jenkins ver. 2.121.3 and  Jenkins ver. 2.187

          Is it possible that this could be the difference causing the issue?

           

           

          Ioannis Moutsatsos added a comment - - edited The 2.2.3 snapshot works. However, using Plugin v 2.1 and 2.2.2 I'm not able to reproduce the Jira issue as reported . In each case I get the correct default value selected. (see screenshot below) Nonetheless, I'm using older version of Jenkins ver. 2.121.3 and  Jenkins ver. 2.187 Is it possible that this could be the difference causing the issue?    

          Adam Gabryś added a comment -

          ioannis you are testing an incorrect page.

          You opened Build with Parameters. On it everything looks good.

          The problem is that this page can be used only by humans (impossible to set parameters by using POST data or GET parameters). The pages which should be used by robots are:

          • parambuild - takes parameters from GET
          • buildWithParameters - takes parameters from POST

          Example for parambuild:

          As you can see, the default value is set incorrectly (should be 3, but it is filled with 1).

          My parameter configuration:

          Adam Gabryś added a comment - ioannis you are testing an incorrect page. You opened Build with Parameters . On it everything looks good. The problem is that this page can be used only by humans (impossible to set parameters by using POST data or GET parameters). The pages which should be used by robots are: parambuild - takes parameters from GET buildWithParameters - takes parameters from POST Example for parambuild : As you can see, the default value is set incorrectly (should be 3, but it is filled with 1). My parameter configuration:

          agabrys thank you for the clatification. I missed this point (since I never use the parameters this way).

          In this case YES I can reproduce the issue with previous versions of the plugin, and INDEED it is corrected in this version.

           

          I would love to see an example where you can set other Active Choices parameters to a value using GET or POST. Does the cascading of other Active Choices still works?

          For the plugin documentation we state that this plugin only works and is intended for interactive use by a human and not by API. Has this PR changed that?

          See: https://plugins.jenkins.io/uno-choice/

           

          Ioannis Moutsatsos added a comment - agabrys thank you for the clatification. I missed this point (since I never use the parameters this way). In this case YES I can reproduce the issue with previous versions of the plugin, and INDEED it is corrected in this version.   I would love to see an example where you can set other Active Choices parameters to a value using GET or POST. Does the cascading of other Active Choices still works? For the plugin documentation we state that this plugin only works and is intended for interactive use by a human and not by API. Has this PR changed that? See:  https://plugins.jenkins.io/uno-choice/  

          Adam Gabryś added a comment -

          Does the cascading of other Active Choices still works?

          The parambuild and buildWithParameters pages take parameter default values and render them as inputs. No other logic is available or executed. It means that if one field should be changed when another field is changed - the logic won't be executed. Example:

          For the plugin documentation we state that this plugin only works and is intended for interactive use by a human and not by API. Has this PR changed that?

          All dynamic actions and validations are still able only for the humans (don't allow checking two radio buttons at the same time etc.). The PR only changes the way of setting the default values of the most basic parameter (not support for references). I know it is not perfect, but make the plugin more usable in basic cases. It also partially solves problem mentioned here JENKINS-28735 (set correct default values for basic parameters when jobs are executed by timers).

          Adam Gabryś added a comment - Does the cascading of other Active Choices still works? The parambuild and buildWithParameters pages take parameter default values and render them as inputs. No other logic is available or executed. It means that if one field should be changed when another field is changed - the logic won't be executed. Example: For the plugin documentation we state that this plugin only works and is intended for interactive use by a human and not by API. Has this PR changed that? All dynamic actions and validations are still able only for the humans (don't allow checking two radio buttons at the same time etc.). The PR only changes the way of setting the default values of the most basic parameter (not support for references). I know it is not perfect, but make the plugin more usable in basic cases. It also partially solves problem mentioned here JENKINS-28735 (set correct default values for basic parameters when jobs are executed by timers).

          Thank you agabrys. I've learned something!

          kinow it should be safe to incorporate these basic improvements into a new release. Thank you!

          Ioannis Moutsatsos added a comment - Thank you agabrys . I've learned something! kinow it should be safe to incorporate these basic improvements into a new release. Thank you!

            kinow Bruno P. Kinoshita
            agabrys Adam Gabryś
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: