Switch to Manage permission and future Jenkins compatibility - #126
Conversation
The code was incorrectly checking the permission ${it.ADMINISTER}
however it when vewing the root of Jenkins (and other views) is an
instance of AllView. As such the permission check failed silently and
was then not shown.
jenkinsci/jenkins#10678 sets ${it} to Jenkins
now, and then this causes the incorrect permission check to blow up as
it is a single permission that is set for permissions (which expects an
array).
This fixes the issue and actually removes the permission check from the
task, as the permission is already checked in the layout.
We now take advantage of the Manage permission also so that users
without Jenkins.ADMINISTER but with JENKINS.MANAGE can clear the build
queue.
| <groupId>io.jenkins.tools.bom</groupId> | ||
| <artifactId>bom-${jenkins.baseline}.x</artifactId> | ||
| <version>3696.vb_b_4e2d1a_0542</version> | ||
| <version>4710.v016f0a_07e34d</version> |
| <changelist>999999-SNAPSHOT</changelist> | ||
| <jenkins.baseline>2.452</jenkins.baseline> | ||
| <jenkins.version>${jenkins.baseline}.4</jenkins.version> | ||
| <jenkins.baseline>2.504</jenkins.baseline> |
There was a problem hiding this comment.
lowest LTS where the MANAGE permission is not Beta
| @RequirePOST | ||
| public void doPurge(final StaplerRequest request, final StaplerResponse response) throws ServletException, IOException { | ||
| Jenkins.get().checkPermission(Jenkins.ADMINISTER); | ||
| Jenkins.get().checkPermission(Jenkins.MANAGE); |
There was a problem hiding this comment.
Switch to MANAGE as this does not allow arbirary command execution or esclation of privalledges
| <l:hasAdministerOrManage> | ||
| <l:task icon="symbol-trash-outline plugin-ionicons-api" confirmationMessage="${%Purge the build queue?}" | ||
| href="purge-build-queue/purge/" post="true" requiresConfirmation="true" | ||
| title="${%Purge Build Queue}" permissions="${it.ADMINISTER}"> |
There was a problem hiding this comment.
permissions="${it.ADMINISTER}" was the bug that caused this not to be compatable.
it is not Jenkins in all current versions as such it.ADMINISTER would return null and then the permission would not be checked.
In Future version it will be an instance of Jenkins and as such this becomes valid, but it is a single permission when permissions is expecting an array.
Given this is already protected by the permission check in layout we can simply rmeove the extra check.
|
build fails due to the lack of "trust" to change the Jenkinsfile which is needed to remove Java11 support. |
jtnord
changed the title
2 participants
Compatability with Future Jenkins version
The code was incorrectly checking the permission
${it.ADMINISTER}however it when viewing the root of Jenkins (and other views) is an
instance of
AllView. As such the permission check failed silently andwas then not shown.
jenkinsci/jenkins#10678 sets
${it}to Jenkinsnow, and then this causes the incorrect permission check to blow up as
it is a single permission that is set for permissions (which expects an
array).
This fixes the issue and actually removes the permission check from the
task, as the permission is already checked in the layout.
We now take advantage of the Manage permission also so that users
without
Jenkins.ADMINISTERbut withJenkins.MANAGEcan clear the buildqueue.
Obsoletes #124
Testing done
mvn hpi:runSubmitter checklist