rename permission ?

[nicolas de loof-2]

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);

    }

[domi]

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 <[hidden email]> 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);
>     }

[nicolas de loof-2]

done as https://github.com/jenkinsci/jenkins/commit/c14c7619c6157f7bb1006635483e44fe0964852b

feel free to amend to only require CREATE, not DELETE

2012/8/15 domi <[hidden email]>

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 <[hidden email]> 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);
>     }

[danielpetisme]

I've faced the same questions for Request Ranme 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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="kpXB2eROu8IJ">do...@...>

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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="kpXB2eROu8IJ">nicolas...@...> 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);
>     }