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.
