|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [JIRA] (JENKINS-13975) Promoted-builds not... [email protected] (JIRA)
- [JIRA] (JENKINS-13975) Promoted-build... [email protected] (JIRA)
- [JIRA] (JENKINS-13975) Promoted-build... [email protected] (JIRA)
- [JIRA] (JENKINS-13975) Promoted-build... [email protected] (JIRA)
- [JIRA] (JENKINS-13975) Promoted-build... [email protected] (JIRA)

Currently "Promote" permission is not defined. "Job.Build" or "Job.Configure" would be candidates if we do not define "Promote".
In either case, I agree that using "Matrix-based security" or "Project-based Matrix Authorization Strategy" is a good idea. But we have to consider that a job might contain multiple promotion processes and that users want to set different approvers on them.
Also we have to consider that no one has "Job.Build" permission, and that what users can do is only to approve. In that case, using matrix-based secuity will force users to change their configurations if they update the plugin.
To avoid breaking changes, I prefer '!' notation.