Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


This plugin adds a new role-based strategy to ease and fasten users management. This strategy allows:

  • Creating global roles, such as admin, job creator, anonymous, etc., allowing to set Overall, Slave, Job, Run, View and SCM permissions on a global basis.
  • Creating project roles, allowing to set only Job and Run permissions on a project basis.
  • Creating slave roles, allowing to set node-related permissions.
  • Assigning these roles to users.

Table of contents

Table of Contents

User guide

Getting started

Using the plugin is fairly simple:

  1. Activate the Role-Based Strategy by using the standard Manage Jenkins > Configure System screen:
    Image Removed
  2. Define and assign roles by using the Manages Roles item which appears in the Manage Jenkins screen:
    Image Removed
    You then get following options:
    Image Removed#* Manage Roles is the place where to set up roles:
    Image Removed
    There's nothing much to say here, this is self-explanatory. The only tricky field is the Pattern one. This field consists in a regular expression aimed at matching the full name (including the folder name, if you're using Cloudbees Folders Plugin) of the jobs which the role will apply to. For example, if you set the field to "Roger-.*", then the role will match all jobs which name starts with "Roger-". Note that the pattern is case-sensitive. To perform a case-insensitive match, use (?i) notation: upper, "Roger-.*" vs. lower, "roger-.*" vs. case-insensitive, "(?i)roger-.*". If you have a nested folder structure where you want to provide the particular access to the second folder (or deeper), consider having a two-level security structure as well (Say you want to provide exclusive write/ modify type access to foo/bar and not everything else under "foo": First, assign that user/ group to read/ discover permissions with pattern " ^foo.* ", then assign that same user/ group to the more particular permissions with pattern " ^foo/bar.* " - Similar to what you'd do in a Unix/ Linux environment.
  1. #* Assign Roles is the place where to assign the defined roles to users:
    Image Removed

Global Roles vs. Project Roles

It should be noted that the Global Roles override anything you specify in the Project Roles. That is, when you give a role the right to Job-Read in the Global Roles, then this role is allowed to read all Jobs, no matter what you specify in the Project Roles.

It may therefore be advisable to leave most (all) options unchecked in Job, Run and SCM in the Global Roles section for normal users.

Built-in Roles

There are two built-in roles:

*Anonymous* — Users who have not logged in

authenticated — Logged in users

Macros support (since 2.1.0)

Macros allow to extend analysis of user's access rights (see @RoleMacroExtension). If user's sid meets criteria in Roles and Assignments, then analysis will be propagated to extension, which makes decisions according to instance and parameters.

Available macros

You can get list of available macros and theirs descriptions at the JENKINS_URL/role-strategy/list-macros page. At the current state, plugin has minimal set of available macros, but they can be added by extensions from plugins.

Known macros:

  • Built-in: @BuildableJob
  • Ownership plugin: Ownership-based roles: @Owner and @CoOwner (will be released in ownership-0.2)

Macro usage

Macros can be used in the following fields:

  • RoleMacros - name of the role
  • UserMacros - Not supported yet
    Macro format: @macroName[:id][(parameter1, parameter2, ...)]>
  • macroName - name of the macro (see available macros in the table below)
  • id - identifier of the macro. Technical parameter, which allows to use same macros for multiple patterns
  • parameter - additional parameters. At the current state, they don't support variables or TokenMacros

Macro string examples:

  • @BuildableJob - Primitive macro invocation. Such invocation can be used only once in each roles category.
  • @BuildableJob:1 - Macro with id
  • @ParameterizedMacro(param1) - Invokes macro with one parameter
  • @ParameterizedMacro:2(param1,param2) - Invokes macro with two parameters. Id prevents naming conflicts

External add-ons

The management interface becomes difficult to use with a large number of users and/or roles. Several Greasemonkey userscripts exist to make the UI easier to use (Jira issue):

Jenkins Role Strategy UI enhancer
This userscript adds a tooltip to the checkboxes indicating the row (e.g. user name) and column (e.g. permission).
Image Removed

Jenkins Role Strategy Role Management Enhancer and Jenkins Role Strategy Role Assignment Enhancer
These userscripts rotate the text in the column title cells on the Role Strategy configuration pages by 90 degrees so they use less horizontal space. Additionally, the first (header) column is repeated at the end of the table.
Image Removed

Version history


See the plugin documentation on GitHub:

Version history

Version 2.11 and newer versions

See the changelog here

Version 2.10 (Feb 11, 2019)

  • (info) Jenkins 2.60.3 is now the minimal requirement of the plugin
  • (plus) JENKINS-44472 - "Manage roles" table now supports preview of jobs matching the regular expression 
  • (plus) PR #45 - REST API: getRole now also returns SID assignments
  • (info) JENKINS-55804,  JENKINS-55803 - Improve performance of the plugin on instances with many roles
  • (info) JENKINS-49102 - "Manage roles" page now displays patterns in quotes to properly visualize whitespace patterns
  • (info) JENKINS-45942 - REST API: Throw error when a non-existent permission is added in the addRole call
  • (error) JENKINS-54900 - REST API: Prevent concurrency issues when permissions are checked in parallel with REST API calls


Version 2.6.1 (Oct 04, 2017)