I would like this to do something like the mock attached; whomever is given security access to this project utilizing the Run | Update project security, those persons are then options to have access to manually promote an individual promotion.

The users list would not be necessary when not manual.

I have modified this plug-in to handle this in an easy sort of way. I've added textbox to allow comma separated usernames. The plugin then checks the logged in user against this user name list; if the user is in the list, the button is available to promote, if not, the button doesn't exist.

Please repost on here if you are interested in this.

Yes I am interested in this. Does it also check against groups as well as individual users?

That is one of the first things my boss asked me too, can i include a group? The code is very simple; as in it doesn't do anything fancy. It doesn't verify users or check them against anything. All it does is verifies that the username Hudson has for logged in matches up to one of the comma separated usernames in each promotion entity.

I may do some research on including more security options as I know my company would use it as well. I may check to see if I can include my code into the promoted builds plugin as well.

As for now, I've attached the HPI to this comment. If you have any questions, you can contact me directly using farcrats at gmail

I have modified the Manual Approval Condition to support a list of users that can approve a promotion. It also does not support groups at this time. The difference is that it does not piggyback on the Force Promotion concept, the Manual Approval Condition now contributes a UI element that conditionally shows an Approve button if the logged in user has permissions to approve a promotion. It also honors the other conditions and does not necessarily immediately force a promotion when a user clicks approve.

Here's the commit: https://github.com/jenkinsci/promoted-builds-plugin/commit/9b8c399513e96bc2c8219fb50d65dde655681e34

I've attached the unreleased hpi to JENKINS-8804 if you can try it out and let me know if it works for you.

Currently they are "promote" permission setting in global security matrix, but not in per job security matrix. If I want to give someone the job 're-execute' permission, I have to give the global 'promote' permission, however, this user will have the ability to 're-execute' all the jobs promotion.

It would be better to limit this permission in job level