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

Input step submitter parameter is ignored for administrators

    XMLWordPrintable

Details

    • pipeline-input-step-2.12

    Description

      I use the following snippet in my DSL pipeline

      operators = "ldapUserGroup"
      ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
      returnValue = input message: 'DEPLOY ?', 
                          parameters: [choice], 
                          submitter: operators, 
                          submitterParameter: 'approver'
      

      I am not part of the ldapUserGroup thus I would expect the pipeline not to continue. However the pipeline continues anyway.

      07:39:05 Approved by Surname Lastname
      [Pipeline] }
      

      The same happens if i use a particular userID or list of userIDs rather than an ldapGroup

      operators = "userID0001,userID0002"
      ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
      returnValue = input message: 'DEPLOY ?', 
                          parameters: [choice], 
                          submitter: operators, 
                          submitterParameter: 'approver'
      

      Attachments

        Issue Links

          Activity

            When will this released? As resolution is "fixed" I cannot vote and watch for this issue.

            tkleiber Torsten Kleiber added a comment - When will this released? As resolution is "fixed" I cannot vote and watch for this issue.

            tkleiber You can find the releases including that correction at the top of the page https://github.com/jenkinsci/pipeline-input-step-plugin/commit/b0c006ed1be9bb5a55114d9239085ba4bfc48a82
            To access that page, you can scroll down in the PR page, and click on the link just after "merged commit".

            This ticket's status was forgotten, I will update it, thanks

            wfollonier Wadeck Follonier added a comment - tkleiber You can find the releases including that correction at the top of the page https://github.com/jenkinsci/pipeline-input-step-plugin/commit/b0c006ed1be9bb5a55114d9239085ba4bfc48a82 To access that page, you can scroll down in the PR page, and click on the link just after "merged commit". This ticket's status was forgotten, I will update it, thanks

            Then you should reopen the issue because of regression.
            I have installed version 449.v77f0e8b_845c4 of the plugin and administrator can approve the input step despite he is not part of the submitter parameter.

            tkleiber Torsten Kleiber added a comment - Then you should reopen the issue because of regression. I have installed version 449.v77f0e8b_845c4 of the plugin and administrator can approve the input step despite he is not part of the submitter parameter.
            dnusbaum Devin Nusbaum added a comment -

            tkleiber The resolution here should have been "Won't fix". If you look at the commit that Wadeck linked, you will see that the change is only to update the documentation to mention the current behavior. We will not change the behavior to prevent admins from approving the input, because it just does not make sense with the Jenkins security model.

            I think the nicest thing we could do would be to copy this logic into a new method that is used to add text like " (Admin override)" to the end of the "Proceed" button if the current user is only allowed to click the button because they are an admin (similar to what GitHub does when you bypass branch protections using your admin permissions to merge a PR on a repo). I do not have any time or plans to look into that myself, but anyone else is welcome to do so and file a PR.

            dnusbaum Devin Nusbaum added a comment - tkleiber The resolution here should have been "Won't fix". If you look at the commit that Wadeck linked, you will see that the change is only to update the documentation to mention the current behavior. We will not change the behavior to prevent admins from approving the input, because it just does not make sense with the Jenkins security model. I think the nicest thing we could do would be to copy this logic into a new method that is used to add text like " (Admin override)" to the end of the "Proceed" button if the current user is only allowed to click the button because they are an admin (similar to what GitHub does when you bypass branch protections using your admin permissions to merge a PR on a repo). I do not have any time or plans to look into that myself, but anyone else is welcome to do so and file a PR.

            Thanks Devin for the information, changed the resolution to "Won't fix"

            wfollonier Wadeck Follonier added a comment - Thanks Devin for the information, changed the resolution to "Won't fix"

            People

              papanito papanito
              papanito papanito
              Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: