Re: Ability to hide the New Job link without revoking create job permissions?
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.
Re: Ability to hide the New Job link without revoking create job permissions?
Hi Ian, Ian Simpson wrote (13.06.2012 17:42): Ah, the ACL thing does help; I'll have to mess around with that a little. Glad this helped ;O) 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. Ah, that's explainable: Hudson, up to version 1.394, checked for proper permissions when receiving the HTTP request from the browser (see the doXXX methods in the Hudson class) and then redirected to an internal method that actually performed the hard work. This internal method did not check for permissions again. As your plugin called that internal method (here: Hudson.getInstance().createProject()) directly, this did not require any permissions at all. Starting from Hudson 1.395, the permission checking was moved from the HTTP request receiving method to the internal method. So from this version, proper permissions are required when calling this internal method - even when called directly from your plugin. Cheers, Simon.
Ability to hide the New Job link without revoking create job permissions?
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) Temporarily 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.
