Details
-
Type:
New Feature
-
Status: Reopened (View Workflow)
-
Priority:
Minor
-
Resolution: Unresolved
-
Component/s: core
-
Labels:
-
Similar Issues:
Description
In our environment it would be very helpful to be able to set Permissions, who can see specific executors/slaves.
It should be like with jobs/projects, where the method "hasPermission()" is called, before you get all Items of the jenkins-instance.
So it would be just needed in the Computer.java a new attribute "Permission VIEW", and in the Jenkins.java in the Method "getComputer()" the check, if the user has the Permission to see this slave.
Attachments
Issue Links
- depends on
-
JENKINS-17200 SCM.TAG permission not eagerly loaded
-
- Open
-
- is blocking
-
JENKINS-5517 Hudson to hide slave ids for Anonymous ID
-
- Open
-
- is duplicated by
-
-
- Closed
-
- is related to
-
-
- Open
-
- relates to
-
-
- Open
-
- links to
Activity
I believe this would be useful as well. Especially in my case where I am deploying Selenium Grid Nodes through Jenkins Agents. If I wanted to dedicate a particular node to only automated testing and not have it bogged down by other build tasks, it would be ideal to hide them from view and make them "unavailable" to people.
Daniel Ng
added a comment - I believe this would be useful as well. Especially in my case where I am deploying Selenium Grid Nodes through Jenkins Agents. If I wanted to dedicate a particular node to only automated testing and not have it bogged down by other build tasks, it would be ideal to hide them from view and make them "unavailable" to people. Would also be useful to override SlaveComputer.hasPermission from those plugins which dynamically attach and then detach an agent in the course of a build—for example, dockerNode from docker-plugin, podTemplate from kubernetes—to delegate the permission check to READ on the corresponding Job. Thus, in a multitenant installation with segregated view permissions, these one-off agents would be displayed in the Build Executor Status widget only to users who would actually be able to see the build itself. Otherwise you see a bunch of containers running but cannot view the associated builds, which is pretty useless. CC Daniel Beck Wadeck Follonier
There are build queue and executors filters in Views, which omit jobs from unselected folders/jobs in the view.
But the filters are not recursive, making them recursive would be a start, so that you can create a View with a selected folder and view only the corresponding jobs inside the folder. which I assume is typical organization in Jenkins.
Tiago Lopes
added a comment - There are build queue and executors filters in Views, which omit jobs from unselected folders/jobs in the view.
But the filters are not recursive, making them recursive would be a start, so that you can create a View with a selected folder and view only the corresponding jobs inside the folder. which I assume is typical organization in Jenkins. Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA
This would be a good feature to have.
Using Folders, permissions and a few other plugins, our Jenkins is pretty much set in a "need to know basis", except for agents, which remain visible to any authenticated user.