Ah, the ACL thing does help; I'll have to mess around with that a little. The problem with revoking the create permission is that calling Hudson.getInstance().createProject() started failing after the upgrade to Jenkins, whereas it worked with Hudson.
For now I worked around this with a mod_rewrite rule to send anything to /hudson/.*/newJob to my plugin instead, and reinstated the Create Job permission. On Wednesday, June 13, 2012 7:31:00 AM UTC-6, Simon Wiest wrote: > > Hi Ian, > > you can escalate temporarily in your plugin code from the current user's > permissions to super-powered 'SYSTEM' permissions like this: > > // First, become the SYSTEM... > SecurityContext oldContext = ACL.impersonate(ACL.SYSTEM); > > // Then, do some stuff with super-powers here... > > // Finally, switch back to user's original permissions. > SecurityContextHolder.setContext(oldContext); > > You can find a real-word example of this procedure at > > https://github.com/jenkinsci/jenkins/blob/1a42a2f071f87b652f3746f8198cd6fcd6bee33e/core/src/main/java/hudson/DependencyRunner.java#L57. > > > > > The "new job" link should be hidden automatically once the current user > lacks the Job.CREATE permission. > > Does this work for you? > > Cheers, > Simon. > -- > Ian Simpson (12.06.2012 18:05): > > We recently upgraded from Hudson 1.385 to Jenkins 1.467. On Hudson, we > > had a plugin that we used to create jobs, which had a predetermined set > > of criteria for how a job was set up. The create permission was revoked > > across almost every ACL, and people that did not have create permission > > could still create jobs with this plugin. > > > > Since the upgrade to Jenkins, this is not the case. Using this plugin > > fails claiming that the user does not have permission. > > > > Ultimately, we want all of the users in our company to only have the > > option to use this plugin to create jobs, since it sets them up to our > > company's standard. That said, is there any way to: > > 1) Hide the new job link, or > > 2) escalate permissions within the context of one plugin > > > > Currently the plugin is still using the 1.385 apis. I'll be updating > > them to use the Jenkins apis soon, but given that this is a bug fix we > > need to try and push it would be prudent to keep the scope of changes as > > small as possible. However, if the only way to fix this is to use the > > Jenkins apis, I can perform that update. > > > > Any help is appreciated. >
