ironcerocloudbees while not ideal, this is currently done so by design for simplicity sake when developing JENKINS-27734 (which introduced the possibility to shelve any kind of item, including containers (eg folder)).

The issue with what you are proposing is that it would rely on the authorization scheme to inherit rights to children items which is not necessarily true, eg with the Project-based Matrix Authorization Strategy, one strategy is:

Do not inherit permissions: The most restrictive inheritance configuration. Only permissions defined explicitly on this agent or item will be granted. The only exception is Overall/Administer: It is not possible to remove access to an agent or item from Jenkins administrators.

What this means is that you can have delete permission on an item, yet not have it on a child item. I'm not sure how Jenkins reconcile this, I'll need to mount a test environment and run some tests to understand the behavior of the delete action in Jenkins.

Hi pierrebtz,

Thank you for reviewing the case so quickly.

I'm not sure if I understood correctly your concerns. I've been working on testing the inheriting and this is what I found:

I spawned four Jenkins instances with `Root Level User` (the user with delete permission at the root level) and `Project Level User` (the user with delete permission at the project level, when it is possible) and with two projects inside a folder:

1. Using `Logged In Users Can Do Anything`: In this case, any user can do anything and, obviously, both `Root Level User` and `Project Level User` users can shelve the projects.
2. Using `Matrix Based Security`: In this case, it is not possible to grant permission at the project level only. So, only by granting delete permission at the root level, we can shelve those projects.
3. Using `Project Based Matrix Authorization Strategy`:  The `Root Level User` was able to delete those projects and, also, to shelve those projects. However, the `Project Level User` was able to delete those projects but not to shelve them.
4. Using `Role Based Strategy`: Again, the `Root Level User` was able to delete those projects and, also, to shelve those projects. However, the `Project Level User` was able to delete those projects but not to shelve them.

I will try to make a pull request to explain better what I am trying to explain.

Kind regards.

ironcerocloudbees I opened https://issues.jenkins.io/browse/JENKINS-66419 that gives details about the situation I was mentioning. What I described for the delete action is transposable to the shelve one.

I am not able to open JENKINS-66419..
Regarding the job deletion we are also facing the issue. Example..
job1 – 'jenkins/job/HGxx_Goyy/job/haven/job/test_pipeline'.
user1,user2 has all kind of permission to 'run, create, delete, etc...' for this job (infact have all the permission for the parent folder, 'HGxx_Goyy').
But when 'user1/2' tries to delete the job '....../test_pipeline' its randomly throws error - permission issue for some other folder 'jenkins/job/HSzx_Clnn'.

> I am not able to open JENKINS-66419..

It was moved as a security issue so it's expected.

> But when 'user1/2' tries to delete the job '

I'm unsure I follow, this report is about an issue with the shelving of a job. If the user tries to delete it, it has nothing to do with the shelve project plugin.

Thanks for the reply. I will create a new one for the second part (delete a job throws error - Access denied to another job).

Regarding the permission inheritance I don't see a problem here. Right now the logic relies on the inheritance (at least for matrix auth). The shelve permission is nothing else than the delete permission. So if you can delete a project/folder and Jenkins can handle this then you can also shelve a project/folder.

I tested this by setting this up giving a user the delete permission on a folder and no delete permission on a project in that folder. The user has no global delete permission. Deleting or shelving the folder works without problems.