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

should be able to specify multiple users or groups for the submitter of an input step

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      It is quite often that the team writing workflows does not have access to create groups in the external authenitcation realm (e.g. ActiveDirectory).

      The input step allows you to restrict who can approve (submit) the input - but this is limited to a single user or group.

      It would be beneficial if this could be expanded to a list that could contain multiple users or groups (i.e a mix).

        Attachments

          Issue Links

            Activity

            teilo James Nord created issue -
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Link This issue duplicates JENKINS-27134 [ JENKINS-27134 ]
            jglick Jesse Glick made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Resolved [ 5 ]
            Hide
            teilo James Nord added a comment -

            re-opening as there are distinct use cases.

            If you had a Permission check then you can not have some users approve a specific "input" step yet another set of users approve a different step.

            example - say you want to seek approval from the QC team before deployment to the manual at server, and approval from OPs before deployment to live - these should be two distinct sets of users. If using Permissions I do not see how you would accomplish this.

            Show
            teilo James Nord added a comment - re-opening as there are distinct use cases. If you had a Permission check then you can not have some users approve a specific "input" step yet another set of users approve a different step. example - say you want to seek approval from the QC team before deployment to the manual at server, and approval from OPs before deployment to live - these should be two distinct sets of users. If using Permissions I do not see how you would accomplish this.
            teilo James Nord made changes -
            Resolution Duplicate [ 3 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            jglick Jesse Glick made changes -
            Link This issue is duplicated by JENKINS-32341 [ JENKINS-32341 ]
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-27134 [ JENKINS-27134 ]
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-27134 [ JENKINS-27134 ]
            Hide
            kad Alexander Kanevskiy added a comment -

            +1 to this request. It's common practice where certain steps of workflow would be requiring set of users or groups to be able to approve. Overall permission would not solve it (well, even for Abort action most of times it would be good to follow same access control as for "ok" action), it must be flexible argument handling on input step.

            Show
            kad Alexander Kanevskiy added a comment - +1 to this request. It's common practice where certain steps of workflow would be requiring set of users or groups to be able to approve. Overall permission would not solve it (well, even for Abort action most of times it would be good to follow same access control as for "ok" action), it must be flexible argument handling on input step.
            Hide
            sag47 Sam Gleske added a comment -

            Pipeline and Jenkins will not be ready for any enterprise without this. This is a poor decision because: what if your "one deployer" goes on vacation in a team of 20 developers? Is the whole pipeline held hostage? This needs to be highly prioritized.

            Needs to support Jenkins groups. It needs to support optionally selecting multiple Jenkins groups/users in the same field.

            Show
            sag47 Sam Gleske added a comment - Pipeline and Jenkins will not be ready for any enterprise without this. This is a poor decision because: what if your "one deployer" goes on vacation in a team of 20 developers? Is the whole pipeline held hostage? This needs to be highly prioritized. Needs to support Jenkins groups. It needs to support optionally selecting multiple Jenkins groups/users in the same field.
            Hide
            teilo James Nord added a comment -

            there is a hacky workaround

            create a credential in the same folder as the job - with some magic value...
            in the workflow read that magic value.
            in the workflow have the input ask for the magic value.
            whilst it is not the same loop.
            if it is the same it is approved.
            only give the magic value to people that are "approvers"

            def magicValue
            node {
                withCredentials([[$class: 'StringBinding', credentialsId: 'production_magic', variable: 'tmpMagicValue']]) {
                    magicValue = env.tmpMagicValue
                }
            }
            
            // send some email notification
            
            while (true) {
              def pass = input id: 'ApproveIt', message: 'Please enter the magic value to approve the build', parameters: [[$class: 'com.michelin.cio.hudson.plugins.passwordparam.PasswordParameterDefinition', defaultValue: 'bogus', description: 'The magic token to show you have rights to push to production', name: 'authentication token']]
              if (magicValue != pass) {
                echo "incorrect value entered"
              }
              else {
                echo "Push to production approved by magic"
                break;
              }
            }
            
            Show
            teilo James Nord added a comment - there is a hacky workaround create a credential in the same folder as the job - with some magic value... in the workflow read that magic value. in the workflow have the input ask for the magic value. whilst it is not the same loop. if it is the same it is approved. only give the magic value to people that are "approvers" def magicValue node { withCredentials([[$class: 'StringBinding' , credentialsId: 'production_magic' , variable: 'tmpMagicValue' ]]) { magicValue = env.tmpMagicValue } } // send some email notification while ( true ) { def pass = input id: 'ApproveIt' , message: 'Please enter the magic value to approve the build' , parameters: [[$class: 'com.michelin.cio.hudson.plugins.passwordparam.PasswordParameterDefinition' , defaultValue: 'bogus' , description: 'The magic token to show you have rights to push to production' , name: 'authentication token' ]] if (magicValue != pass) { echo "incorrect value entered" } else { echo "Push to production approved by magic" break ; } }
            Hide
            sag47 Sam Gleske added a comment - - edited

            That requires a passphrase to deploy if I understand correctly.

            I'd rather have groups support prioritized. Pipelines can't be considered enterprise ready in any capacity in my opinion without this. To assume, "dev's can't create AD groups" is a naive and bad assumption to have. We're using GitHub OAuth and Dev's manage their own groups in a fully self service manner. I'll reach out to my support rep and try to get this on the roadmap sooner.

            I appreciate the workaround but I think this requires a bit more finesse.

            Show
            sag47 Sam Gleske added a comment - - edited That requires a passphrase to deploy if I understand correctly. I'd rather have groups support prioritized. Pipelines can't be considered enterprise ready in any capacity in my opinion without this. To assume, "dev's can't create AD groups" is a naive and bad assumption to have. We're using GitHub OAuth and Dev's manage their own groups in a fully self service manner. I'll reach out to my support rep and try to get this on the roadmap sooner. I appreciate the workaround but I think this requires a bit more finesse.
            Hide
            sag47 Sam Gleske added a comment - - edited

            I have mispoken. I appear to have likely run up against a bug in the GitHub OAuth plugin and the behavior I was talking about is not directly related to multiple users or groups in this issue. However, this would be a killer feature for us . I apologize if there's been any ruffled feathers due to my comments.

            Show
            sag47 Sam Gleske added a comment - - edited I have mispoken. I appear to have likely run up against a bug in the GitHub OAuth plugin and the behavior I was talking about is not directly related to multiple users or groups in this issue. However, this would be a killer feature for us . I apologize if there's been any ruffled feathers due to my comments.
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 166789 ] JNJira + In-Review [ 186328 ]
            abayer Andrew Bayer made changes -
            Component/s pipeline-general [ 21692 ]
            abayer Andrew Bayer made changes -
            Component/s workflow-plugin [ 18820 ]
            jglick Jesse Glick made changes -
            Component/s pipeline-input-step-plugin [ 21708 ]
            Component/s pipeline [ 21692 ]
            Hide
            uhp UHP added a comment - - edited

            Would it be possible for you as a first step to extend

            private boolean canSettle(Authentication a) {
            String submitter = input.getSubmitter();
            if (submitter==null || a.getName().equals(submitter))

            Unknown macro: { return true; }

            for (GrantedAuthority ga : a.getAuthorities()) {
            if (ga.getAuthority().equals(submitter))

            Unknown macro: { return true; }

            }
            return false;
            }

            by iterating over all roles of the submitting user for the RoleBasedAuthorizationStrategy Plugin?

            If not it would help if we can get the approver back as a result so we can implement any strategy on our own (seems to be wished for 3 years already: http://stackoverflow.com/questions/39451358/how-to-know-which-user-answered-a-jenkins-pipeline-input-step#comment66251982_39465711)

            Show
            uhp UHP added a comment - - edited Would it be possible for you as a first step to extend private boolean canSettle(Authentication a) { String submitter = input.getSubmitter(); if (submitter==null || a.getName().equals(submitter)) Unknown macro: { return true; } for (GrantedAuthority ga : a.getAuthorities()) { if (ga.getAuthority().equals(submitter)) Unknown macro: { return true; } } return false; } by iterating over all roles of the submitting user for the RoleBasedAuthorizationStrategy Plugin? If not it would help if we can get the approver back as a result so we can implement any strategy on our own (seems to be wished for 3 years already: http://stackoverflow.com/questions/39451358/how-to-know-which-user-answered-a-jenkins-pipeline-input-step#comment66251982_39465711 )
            Hide
            jglick Jesse Glick added a comment -

            Dependencies on specific authorization strategies will not be entertained.

            Show
            jglick Jesse Glick added a comment - Dependencies on specific authorization strategies will not be entertained.
            Hide
            jglick Jesse Glick added a comment -

            Anyway most of the discussion here is actually about JENKINS-27134, not the “multiple” part per se.

            Show
            jglick Jesse Glick added a comment - Anyway most of the discussion here is actually about JENKINS-27134 , not the “multiple” part per se.
            Hide
            sag47 Sam Gleske added a comment - - edited

            Dependencies on specific authorization strategies will not be entertained.

            I'm not sure how you came to the conclusion that this request is dependent on a specific authorization strategy. Right now, only one Jenkins Group or one User is allowed for the input step. The actual request is one or more Jenkins Groups (agnostic to the strategy being used). Most authorization strategies (like the GitHub Authorization Strategy) surface their authorizations as Jenkins Groups.

            not the “multiple” part per se.

            The original purpose for this request is just the "'multiple' part".

            Also after reading JENKINS-27134, I'd say it's not good for how my team works. We don't want "one person or group of people" to approve all parts of the pipeline. There's a whole approval process at my place of work (like Dev deployer, QA teams deploying, and an entire separate permission for production deployments). The current behavior is good enough.

            JENKINS-27134 is not a good proposal for how my teams work.

            Show
            sag47 Sam Gleske added a comment - - edited Dependencies on specific authorization strategies will not be entertained. I'm not sure how you came to the conclusion that this request is dependent on a specific authorization strategy. Right now, only one Jenkins Group or one User is allowed for the input step. The actual request is one or more Jenkins Groups (agnostic to the strategy being used). Most authorization strategies (like the GitHub Authorization Strategy) surface their authorizations as Jenkins Groups. not the “multiple” part per se. The original purpose for this request is just the "'multiple' part". Also after reading JENKINS-27134 , I'd say it's not good for how my team works. We don't want "one person or group of people" to approve all parts of the pipeline. There's a whole approval process at my place of work (like Dev deployer, QA teams deploying, and an entire separate permission for production deployments). The current behavior is good enough. JENKINS-27134 is not a good proposal for how my teams work.
            jglick Jesse Glick made changes -
            Remote Link This issue links to "PR 6 (Web Link)" [ 14931 ]
            jglick Jesse Glick made changes -
            Assignee Jesse Glick [ jglick ] Emilio Escobar [ escoem ]
            jglick Jesse Glick made changes -
            Status Reopened [ 4 ] Open [ 1 ]
            jglick Jesse Glick made changes -
            Issue Type Bug [ 1 ] Improvement [ 4 ]
            jglick Jesse Glick made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            jglick Jesse Glick made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            Hide
            romanp Roman Pickl added a comment -

            See https://www.cloudbees.com/sites/default/files/2016-jenkins-world-no_you_shouldnt_do_that_lessons_from_using_pipeline.pdf last slide on how people currently try to cope with this limitation.

            def magicValue
            node {
            withCredentials([
            [$class: 'StringBinding', credentialsId: 'production_magic', variable:
            'tmpMagicValue'
            ]
            ])

            { magicValue = env.tmpMagicValue }

            }
            while (true) {
            def pass = input id: 'PushToProduction', message: 'Please enter the magic value for publishing to
            production ', parameters: [[$class:
            'com.michelin.cio.hudson.plugins.passwordparam.PasswordParameterDefinition', defaultValue:
            'wibble', description: 'The magic token to show you have rights to push to production', name:
            'authentication token']]
            if (magicValue != pass) {
            echo "incorrect value entered"
            } else {
            echo "Push to production approved by magic"
            break
            }

            Please fix this.

            Show
            romanp Roman Pickl added a comment - See https://www.cloudbees.com/sites/default/files/2016-jenkins-world-no_you_shouldnt_do_that_lessons_from_using_pipeline.pdf last slide on how people currently try to cope with this limitation. def magicValue node { withCredentials([ [$class: 'StringBinding', credentialsId: 'production_magic', variable: 'tmpMagicValue' ] ]) { magicValue = env.tmpMagicValue } } while (true) { def pass = input id: 'PushToProduction', message: 'Please enter the magic value for publishing to production ', parameters: [[$class: 'com.michelin.cio.hudson.plugins.passwordparam.PasswordParameterDefinition', defaultValue: 'wibble', description: 'The magic token to show you have rights to push to production', name: 'authentication token']] if (magicValue != pass) { echo "incorrect value entered" } else { echo "Push to production approved by magic" break } Please fix this.
            jglick Jesse Glick made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Emilio Escobar
            Path:
            src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStep.java
            src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution.java
            src/main/resources/org/jenkinsci/plugins/workflow/support/steps/input/InputStep/help-submitter.html
            src/test/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepTest.java
            http://jenkins-ci.org/commit/pipeline-input-step-plugin/e2563fbbac634b6c9f64cd00755478064fcdd2bf
            Log:
            JENKINS-31425 multiple submitters are allowed

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Emilio Escobar Path: src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStep.java src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution.java src/main/resources/org/jenkinsci/plugins/workflow/support/steps/input/InputStep/help-submitter.html src/test/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepTest.java http://jenkins-ci.org/commit/pipeline-input-step-plugin/e2563fbbac634b6c9f64cd00755478064fcdd2bf Log: JENKINS-31425 multiple submitters are allowed
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            .gitignore
            src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStep.java
            src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution.java
            src/main/resources/org/jenkinsci/plugins/workflow/support/steps/input/InputStep/help-submitter.html
            src/test/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepTest.java
            http://jenkins-ci.org/commit/pipeline-input-step-plugin/01c72d7b53c857e0fa7de796a7fefce35260c4fc
            Log:
            Merge pull request #6 from escoem/JENKINS-31425

            JENKINS-31425 should be able to specify multiple users or groups for the submitter of an input step

            Compare: https://github.com/jenkinsci/pipeline-input-step-plugin/compare/114a36be8362...01c72d7b53c8

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: .gitignore src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStep.java src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution.java src/main/resources/org/jenkinsci/plugins/workflow/support/steps/input/InputStep/help-submitter.html src/test/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepTest.java http://jenkins-ci.org/commit/pipeline-input-step-plugin/01c72d7b53c857e0fa7de796a7fefce35260c4fc Log: Merge pull request #6 from escoem/ JENKINS-31425 JENKINS-31425 should be able to specify multiple users or groups for the submitter of an input step Compare: https://github.com/jenkinsci/pipeline-input-step-plugin/compare/114a36be8362...01c72d7b53c8
            Hide
            romanp Roman Pickl added a comment -

            thanks!

            Show
            romanp Roman Pickl added a comment - thanks!
            jamesdumay James Dumay made changes -
            Labels blueocean
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal OSS-837 (Web Link)" [ 18818 ]

              People

              Assignee:
              escoem Emilio Escobar
              Reporter:
              teilo James Nord
              Votes:
              11 Vote for this issue
              Watchers:
              20 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: