We are using the promoted builds plugin as a means of automatically deploying web applications to different environments, both for development purposes and for releasing new application versions to our live environments when they are deemed ready. To accomplish this, we have a series of promotion processes for each job set to execute when they are manually approved, with different approvers listed for the different processes. For deployments to Development environments, all Developers are listed as valid approvers. For the live Production environments, only the Dev Ops team members have the ability to approve the promotion.

The issue we ran into today was that one of the Developers went to promote a build to one of our development environments, but an error occurred on the first attempt. They went to re-run the promotion, but accidentally hit the "Force Promotion" option on the Production environment deployment instead without realizing it. Fortunately for us we maintain two promotion environments and the one that was deployed to was not the currently live environment for customers, but this highlighted the fact for us that the security options for the plugin are lacking.

What we would like is an additional option to restrict Force and Re-execution ability to only the listed Approvers for a promotion process, so if a Dev Ops employee approves a Production deployment, only Dev Ops employees can then re-execute it instead of the promotion now being open for any user to run it again at any time. Additionally, giving users that are not on the Approvers list the ability to force the promotion regardless seems very wrong from a security standpoint. Simply removing the promotion permission from Developers in the global security settings helps a bit in terms of forcing promotions, but the option to re-execute promotions that they shouldn't have access to still appear on the Production environments.

For the time being we have come up with a workaround with the access permissions for individual jobs to restrict the ability of developers to run promotions, but it is greatly limiting compared to the flexibility for Deployment options that we had before we became aware of this problem. An option to further restrict promotion operations to only the list of Approvers would give us greater control and allow us to get that flexibility back.