-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
Platform: All, OS: All
Currently security permissions for build promotion are only applied at the global level.
It would be useful to be to restrict when users/groups can and cannot promote on a per promotion basis.
This would be used when having staged promotions so that, for example: only users in group 'dev' can trigger the 'promote to dev' promotion process.
- is related to
-
JENKINS-8804 Can't set security role for promotion process locally to a job
-
- Open
-
[JENKINS-6888] Per-promotion security permissions.
farcrats
added a comment - 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.
farcrats
added a comment - 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. 
liamjbennett
added a comment - Yes I am interested in this. Does it also check against groups as well as individual users?
liamjbennett
added a comment - Yes I am interested in this. Does it also check against groups as well as individual users? farcrats
added a comment - 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
farcrats
added a comment - 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 
Peter Hayes
added a comment - 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.
Peter Hayes
added a comment - 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
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/java/hudson/model/Item.java
core/src/main/java/hudson/model/Run.java
core/src/main/java/hudson/security/AuthorizationMatrixProperty.java
core/src/main/java/hudson/security/Permission.java
core/src/main/java/hudson/security/PermissionGroup.java
core/src/main/java/hudson/security/PermissionScope.java
http://jenkins-ci.org/commit/jenkins/f5e0f001c0c608205e3c0b290af9115ab3fba32c
Log:
Added the concept of scope to permissions so that permissions added by
plugins can be properly controlled by per-project matrix security.
See issues like JENKINS-6888.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/java/hudson/model/Item.java
core/src/main/java/hudson/model/Run.java
core/src/main/java/hudson/security/AuthorizationMatrixProperty.java
core/src/main/java/hudson/security/Permission.java
core/src/main/java/hudson/security/PermissionGroup.java
core/src/main/java/hudson/security/PermissionScope.java
http://jenkins-ci.org/commit/jenkins/f5e0f001c0c608205e3c0b290af9115ab3fba32c
Log:
Added the concept of scope to permissions so that permissions added by
plugins can be properly controlled by per-project matrix security.
See issues like JENKINS-6888.
I made the necessary change in the core in f5e0f001c0c608205e3c0b290af9115ab3fba32c toward 1.421.
Once that's released, we can update promoted-builds plugin to fix this issue.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/java/hudson/model/Item.java
core/src/main/java/hudson/model/Run.java
core/src/main/java/hudson/security/AuthorizationMatrixProperty.java
core/src/main/java/hudson/security/Permission.java
core/src/main/java/hudson/security/PermissionGroup.java
core/src/main/java/hudson/security/PermissionScope.java
http://jenkins-ci.org/commit/jenkins/f5e0f001c0c608205e3c0b290af9115ab3fba32c
Log:
Added the concept of scope to permissions so that permissions added by
plugins can be properly controlled by per-project matrix security.
See issues like JENKINS-6888.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/java/hudson/model/Item.java
core/src/main/java/hudson/model/Run.java
core/src/main/java/hudson/security/AuthorizationMatrixProperty.java
core/src/main/java/hudson/security/Permission.java
core/src/main/java/hudson/security/PermissionGroup.java
core/src/main/java/hudson/security/PermissionScope.java
http://jenkins-ci.org/commit/jenkins/f5e0f001c0c608205e3c0b290af9115ab3fba32c
Log:
Added the concept of scope to permissions so that permissions added by
plugins can be properly controlled by per-project matrix security.
See issues like JENKINS-6888.
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.