[JIRA] (JENKINS-13975) Promoted-builds not following jenkins access control policies

2012-08-17 Thread jos...@java.net (JIRA)














































Jose Sa
 commented on  JENKINS-13975


Promoted-builds not following jenkins access control policies















Regarding "!anonymous" there is actually a special group in Matrix or Project-Matrix Auth Strategy called "authenticated" that matches any logged-in user as a counterpart of "anonymous" (not logged-in).

But it seems you are trying to define yet another Auth layer in each Promote Action. Wich makes sense if you want to override or complement the Authorizations in upper levels (Job or Global).



























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 following jenkins access control policies

2012-08-16 Thread ohtake_tomoh...@java.net (JIRA)














































OHTAKE Tomohiro
 commented on  JENKINS-13975


Promoted-builds not following jenkins access control policies















How about this one?
"#Job.Build,user1" allows user1 and any user with Job.Build permission to approve.
It enables us to do what this issue says.
We have to decide which charactor is the best to denote permission later.



























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 following jenkins access control policies

2012-08-16 Thread ohtake_tomoh...@java.net (JIRA)














































OHTAKE Tomohiro
 commented on  JENKINS-13975


Promoted-builds not following jenkins access control policies















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.



























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 following jenkins access control policies

2012-08-16 Thread jos...@java.net (JIRA)














































Jose Sa
 commented on  JENKINS-13975


Promoted-builds not following jenkins access control policies















I would expect the promoted builds which are inside the context of a specific job to follow the authorized defined on job level (or global if Project Matrix is not in use), either using the "Update" permission or a specific "Promote" permission (if it exists)



























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 following jenkins access control policies

2012-08-16 Thread ohtake_tomoh...@java.net (JIRA)














































OHTAKE Tomohiro
 commented on  JENKINS-13975


Promoted-builds not following jenkins access control policies















Since there are a lot of AuthorizationStrategy'ies in Jenkins,
it's not a good idea to distinguish FullControlOnceLoggedInAuthorizationStrategy.

What do you think '!' notation.
For instance, "!anonymous" allows non-anonymous users to approve,
and "group1,!user1" allows members in group1 except user1 to approve.

Implementation would be https://github.com/jenkinsci/promoted-builds-plugin/compare/jenkinsci:1653a48...ohtake:9c9ab04



























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 following jenkins access control policies

2012-05-31 Thread bruce.e...@gmail.com (JIRA)
Bruce Edge created JENKINS-13975:


 Summary: Promoted-builds not following jenkins access control 
policies
 Key: JENKINS-13975
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13975
 Project: Jenkins
  Issue Type: Bug
  Components: promoted-builds
Affects Versions: current
 Environment: Jenkins head release with updated plugins on Ubuntu 11.10
Reporter: Bruce Edge
Priority: Minor


If the jenkins master config setting is set to "Logged in users can do 
anything", I would expect that to apply to build promotions as well.
Instead, if there's no user restriction on the build promotion setting, 
non-logged-in users can still promote builds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira