I've faced the same questions for Request Ranme or Delete plugin<https://wiki.jenkins-ci.org/display/JENKINS/Request+Rename+Or+Delete+Plugin>. Have a look at: https://svn.jenkins-ci.org/trunk/hudson/plugins/rrod/src/main/java/com/michelin/cio/jenkins/plugin/rrod/action/RequestRenameAction.java #isIconDisplayed Is how I define if the current has not the Rename permission and so when I should display the "Request Rename" Action.
I hope it will help you On Wednesday, August 15, 2012 6:48:27 PM UTC+2, nicolas de loof wrote: > > done as > https://github.com/jenkinsci/jenkins/commit/c14c7619c6157f7bb1006635483e44fe0964852b > > feel free to amend to only require CREATE, not DELETE > > 2012/8/15 domi <[email protected] <javascript:>> > >> actually I was thinking about the same a couple days ago to >> …I would go for the CONFIGURE and CREATE only, because the job already >> exists, and the user only wants to rename it - which at the end will create >> a new workspace directory on the slave. >> Domi >> >> On 13.08.2012, at 01:39, nicolas de loof <[email protected]<javascript:>> >> wrote: >> >> > Hi, >> > >> > looking at hudson.model.Job#doDoRename, I notice >> > // rename is essentially delete followed by a create >> > checkPermission(CREATE); >> > checkPermission(DELETE); >> > >> > >> > I wonder a user that can't create job but has all other permissions on >> job, including CONFIGURE, can't choose a name for his job. >> > Would it make sense to check CONFIGURE permission on rename, not CREATE >> + DELETE, or maybe a combination of them : >> > if (!hasPermision(CONFIGURE)) { >> > checkPermission(CREATE); >> > checkPermission(DELETE); >> > } >> >> >
