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.

+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.

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.

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;
  }
}

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.

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.

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)

Dependencies on specific authorization strategies will not be entertained.

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

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.

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

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

thanks!