Use self-service mode - 2.35
- Ramarao Gaggara (Deactivated)
On This Page
Overview
A Jira Administrator configures Delegated Project Admin Pro for Jira to indicate what can be delegated and who can perform project administrative actions as a Delegated Project Administrator. Once configured, a Delegated Project Administrator can see the Delegated Project Admin option in the sidebar when viewing a project for which they have project administration rights. The project administration rights are based on the Permission Scheme associated with a project and correspond to the "Administer Project" permission.
You cannot see this sidebar option if:
- You do not have this permission on the current project
- A Jira Administrator has not delegated anything when configuring the app
- A Jira Administrator has not delegated any project administration capabilities to you or any group of which you are a member
- The project delegation is stopped or disabled for the current project using the Stop Delegation option in Advanced Settings
- The project delegation is enabled for only few of the projects using the Enable Delegation option in Advanced Settings
Sidebar (expanded)
Sidebar (collapsed)
Enter self-service mode
When a project is in Guided Path mode, Delegated Project Administrators who have been given Self-Service ability by a Jira Administrator will see an Enter Self-Service Mode button in the top right corner of the Delegated Project Admin screen.
After clicking Enter Self-Service Mode, the following screen is displayed to warn you of the ramifications of switching to this mode.
Please note that if you (or another Delegated Project Administrator) switches the project to Self-Service mode:
- The project remains in Self-Service mode until a Jira Administrator, or Delegated Project Administrator with the permission to enable/disable Self-Service, deliberately exits Self-Service mode for the project.
- Other Delegated Project Administrators can view the Delegated Project Admin configuration of the project. However, they cannot perform a Self-Service action unless a Jira Administrator has delegated that capability to them.
Overview of self-service mode
By default, a project is in Guided Path mode, unless the ability to enter Self-Service mode has been granted and a Delegated Project Administrator with the appropriate ability has opted to enter Self-Service mode.
Your view depends on what has been delegated to you
Self-Service mode allows Delegated Project Administrators to do more granular configuration of a project, beyond what can be done in Guided Path mode. What you can do while a project is in Self-Service mode depends on what a Jira Administrator delegated to you, your role on the project, and the groups to which you belong. In addition, it is possible that one Delegated Project Administrator has greater or less capability than another because of different roles on the project or group membership.
It is possible for a Delegated Project Administrator to be unable to do some things or perhaps anything at all in a project if s/he was not delegated any capability pertinent to that mode. If you have been delegated the ability to work in Guided Path mode but not in Self-Service mode, you can still be able to view a project's configuration if the project is put into Self-Service mode, however you see a warning banner like this at the top of the screen:
What happens when a project is placed into Self-Service mode?
When a project is placed into Self-Service mode, the project's current configuration is analyzed and one or more Process Templates are created to represent that configuration. A Process Template is a collection of schemes that, together, represent the entire behavior of the project. A project consists of multiple Process Templates if it uses:
- One set of Create/View/Edit screens for some Issue Types, and a different set for other Issue Types.
- One set of fields for some Issue Types, and a different set for other Issue Types.
- One Workflow for some Issue Types, and a different one for other Issue Types.
This is what the Delegated Project Admin screen looks like once a project has been placed into Self-Service mode:
The group name of the project (DELPROJ 2/16 in the screenshot) is displayed next to the project name in this page. Hover over this group name to view the other projects that belong with the group. You can also navigate the these project by clicking the respective links.
The various sections of the screen are:
Process Templates — renaming or removing Process Templates, or creating a new Process Template by copying another
Issue Types — adding or removing Issue Types that are available to the project via the currently selected Process Template
Fields — adding or removing a Field from the Create/Edit/View screens, making a Field required or optional, reordering a Field on the Create/View/Edit screens. Fields can be filtered out based on their name or description and field type using the Search option provided in the same section.
Workflow — adding or removing a Workflow step, editing the fields available on a transition screen, reordering the Fields available on a transition screen, or switching to another workflow
If there is any orphan workflow status, you are notified by a warning message at the bottom of the Workflow column.
Project Permissions — granting or revoking Jira project permissions to a user, role, or group
Project Notifications — adding or removing recipients for a notification that is sent when a workflow transition or issue operation occurs
- Project Priorities — adding or removing priorities that are available for issues in a project
Actions — allow you to either exit Self-Service mode or join an alternate project group if the Administrator has granted those rights to you
A Process Template is a set of configuration options that control the workflows, fields, issue types, and groups that can be applied to a project.
Each of these is discussed in the succeeding sections.
Connect projects with project groups
Connecting a project with another causes the projects to become a Project Group. At this point, any change done to one project is done to all of the projects in the same project group. In order to create a project group, the user has to have been granted the "Project Group" permission by the Jira administrator. Once a user has selected to enter Self-Service mode, they are then prompted with a series of dialogs asking them if the project should join a project group.
| Do not join a Project Group | Create a new project group | Join an existing project group |
|---|---|---|
​ | ​ | ​ |
By selecting the independent option, the project does not join a project group. | By selecting this option and specifying a name, a new project | If there are already existing groups and the user is a project administrator on these projects, they can select to join the project group. |
If the user selects to join an existing project group, the system scans the configuration of both of the projects joining and the associated project group. If it identifies any issues that are incompatible with the project group's configuration, a dialog is displayed and the project cannot join the project group:
If the project is able to join the project group, but there are changes that is made to the project due to the various schemes being different (Workflow Schemes, Issue Type Schemes, etc.) a dialog is displayed with the details of the changes:
The user can at this point select not to add the project to the group by clicking on Cancel.
Work with process templates
As mentioned above, when a project is placed into Self-Service mode, the project's current configuration is analyzed and one or more Process Templates are created to represent that configuration. A Process Template is a collection of schemes that, together, represent the entire behavior of the project. A project consists multiple Process Templates if it uses:
- One set of Create/View/Edit screens for some Issue Types, and a different set for other Issue Types.
- One set of fields for some Issue Types, and a different set for other Issue Types.
- One Workflow for some Issue Types, and a different one for other Issue Types.
Jira Administrator can configure the 'Number of Process templates' that can be created. So user may see below warning message whenever the number of process templates exceeds the configured number. User can reach out to Jira Administrator in this case.
This is how the Process Templates section of the screen appears:
Each item is further described below:
| Item | Description |
|---|---|
| Process Templates (2) | The "(2)" indicates the number of Process Templates. By default, the templates are named "Untitled process template 1", "Untitled process template 2", and so on. The name of the currently selected Process Template is shown in the dropdown. Any change made in the Issues Types, Fields, or Workflow sections affects that Process Template. |
| Click this icon to rename the currently selected Process Template. The following screen is displayed. Supply the required name and click Save.
|
| Click this icon to make a copy of the currently selected Process Template in order to create a new Process Template. The following screen is displayed. Supply a name for the new Process Template that is created from the currently selected one. Click the radio button for any Issue Type you want to be available in the newly created Process Template, and then click Copy.
Please note that if you select an Issue Type that is already being used by any Process Template associated with the project, the selected Issue Type is removed from that other Process Template so it can be added to your new copy. In addition, if that results in the other Process Template now having no Issue Types associated with it, then you see a message as shown below. This warns you that the Process Template is unusable, and thus can be removed by clicking the "remove this template" link.  |
| Click this icon to remove the currently selected Process Template. The following screen is displayed. If you are sure you want to proceed, click Remove Process Template.
|
| Hover over this icon to see a helpful description of Process Templates. |
The visibility of the above icons is based on what administrative tasks the Jira Administrator has delegated, as well as the Delegated Project Admin permissions granted to you or the groups to which you belong. Some Delegated Project Administrators may see more or fewer icons than you because of this.
Work with issue types
This is how the Issue Types section of the screen appears:
Each item is further described below:
| Item | Description |
|---|---|
| This indicates an Issue Type available to the project via the currently selected Process Template. In this example, "Sub-task" is the name of the Issue Type and |
| Click this icon to remove the corresponding Issue Type immediately, with no further confirmation. Please note that if you attempt to remove the last Issue Type in a Process Template, you see the message shown below. You aren't allowed to have a Process Template with no Issue Types, hence it recommends that you remove the Process Template if you no longer need it.  |
| Click this icon to add a new Issue Type to the currently selected Process Template. |
| Click this icon to view the History screen, which shows an audit trail of previous changes made to Issue Types in the currently selected Process Template. The Change Type column indicates if the Issue Type was added or removed. Click the Undo link next to any Issue Type to undo that change.
Changes can be undone in any sequence, and an undo itself can be undone. In the screen above, if the first Undo link was clicked, you would see the following screen confirming that the "Epic" Issue Type was removed.
|
| Hover over this icon to see a helpful description of Issue Types. |
The visibility of the above icons is based on what administrative tasks the Jira Administrator has delegated, as well as the Delegated Project Admin permissions granted to you or the groups to which you belong. Some Delegated Project Administrators may see more or fewer icons than you because of this.
Work with fields
This is how the Fields section of the screen appears:
Each item is further described below:
| Item | Description |
|---|---|
Affects Version/s, | Each of these indicate a Field available to the project via the currently selected Process Template. There are as many rows as there are Fields in the currently selected Process Template. |
| Click this icon to edit the Field, which causes the following screen to appear.
Through this screen, you can:
Click Close to close the screen when you are through making changes. |
| Click this icon to remove the corresponding Field immediately, with no further confirmation. |
| Click this icon to add a new Field to the currently selected Process Template. |
| Click this icon to view the History screen, which shows an audit trail of previous changes made to Fields in the currently selected Process Template. The Change Type column indicates if the Field was added or removed. Click the Undo link next to any Field to undo that change.
Changes can be undone in any sequence, and an undo itself can be undone. In the screen above, if the second Undo link was clicked, you would see the following screen confirming that the "Sprint" Field was added back.
|
| Hover over this icon to see a helpful description of Fields. |
Field Contexts
When configuring a custom field, a Jira Administrator is able to define a default value and, for fields of type "Select List (single choice)" and "Select List (multiple choice)", a list of options. At that time, the Jira Administrator can choose the issue types to which the configuration applies. The default value, options, and the issue type(s) with which they are associated is collectively known as the "field context." The field context provides the flexibility of having different default values or options for each issue type supported by your Jira project.
Delegated Project Admin Pro for Jira displays a warning at the top of the screen (as shown below) when a Process Template field has a context that is available to only some of the issue types that can be used on that Process Template.
In addition, each field with such a context consists an icon like this next to it in the Fields section of the screen: 
You may want to ask your Jira Administrator to reconfigure the field(s) shown so they are available to all issue types used on that Process Template.
The visibility of the above icons is based on what administrative tasks the Jira Administrator has delegated, as well as the Delegated Project Admin permissions granted to you or the groups to which you belong. Some Delegated Project Administrators may see more or fewer icons than you because of this.
Work with the workflow
This is how the Workflow section of the screen appears:
Each item is further described below:
| Item | Description |
|---|---|
| Start Progress | This indicates the name of the Workflow transition. OPEN and IN PROGRESS represent the status from which and to which, respectively, the transition moves the issue. |
| This icon (shown above for the Resolve Issue transition) is shown when a transition screen is displayed during the transition. This icon is not clickable. |
| Click this icon to add or reposition Fields on the transition screen for the transition. The following screen is displayed. Select a Field you'd like to add to the screen and click Add. Once a field has been added, you can click and drag the grabber handle (
|
| Click this icon to remove the transition from the Workflow in the currently selected Process Template, with no further confirmation. |
| Click this icon to add a new step (aka transition) to the Workflow. The following screen is displayed.
After making your selections, click Add to add the transition or Close to dismiss the screen without adding the transition. |
| Click this icon to update the Process Template to use a different (pre-existing) Workflow. It is important to note that while Guided Path mode works with Workflow Schemes, Self-Service mode works with Workflows – not Workflow Schemes. Here the workflows are hidden from the list that the delegated project admin lacks access to. The following screen is displayed. For any Workflow shown, click Preview to review a visual representation of the Workflow or click Select to have the project begin using that Workflow. Click Close to dismiss this screen.
|
| Click this icon to view the History screen, which shows an audit trail of previous changes made to the Workflow in the currently selected Process Template. The Change Type column describes the type of change and, if applicable, the Transition Name column identifies the transition on which it occurred. Click the Undo link next to any entry to undo that change.
Changes can be undone in any sequence, and an undo itself can be undone. In the screen above, if the first Undo link was clicked, you would see the following screen confirming that the "Ready for review" transition step was removed again.
|
| Hover over this icon to see a helpful description of Workflows. |
If you added a Field and no transition screen previously existed, one is created and you now see the 
The visibility of the above icons is based on what administrative tasks the Jira Administrator has delegated, as well as the Delegated Project Admin permissions granted to you or the groups to which you belong. Some Delegated Project Administrators may see more or fewer icons than you because of this.
Work with project permissions
To grant or revoke permissions to a project, click the Project Permissions button located at the top of the screen. The Edit Project Permissions screen is displayed:
Adding a permission
To grant a permission to a new recipient, click Add permission next to the appropriate permission. The Add Permission screen is displayed, allowing you to select the permission type and the recipient.
The Permission Type field supports these choices: Current Assignee, Reporter, Project Lead, Single User, Group, Project Role, Group Custom Field Value, User Custom Field Value, and Application Role. Please note that:
- When the Permission Type is set to "Group," the groups that can be selected as the recipient are based on what the Jira Administrator has set for the Groups delegation.
- The Group Custom Field Value option does not appear unless the Jira Administrator has delegated one or more fields of type "Group Picker (single choice)" or "Group Picker (multiple choice)."
- The User Custom Field Value option does not appear unless the Jira Administrator has delegated one or more fields of type "User Picker (single choice)" or "User Picker (multiple choice)."
- A Delegated Project Administrator can grant permission to logged in users to access and work with specific applications such as Jira Service Desk, Jira Software, and Jira Core. Select Application Role in the Permission Type field to grant a permission to an Application Role for all logged on users.
Once you have supplied the Permission Type and recipient, click Add to save your changes or Discard to abandon them.
Removing a permission
To remove a permission, simply click the Delete link alongside the desired permission.
Click Close when you are through adding or removing permissions.
Work with project notifications
To add or remove a notification recipient, click the Project Notifications button located at the top of the screen. The Edit Project Notifications screen is displayed, listing each event that can be triggered via a workflow transition or an issue operation, along with each recipient for that event.
Adding a recipient
To add a notification to a new recipient, click Add notification next to the appropriate event. The Add Notification screen is displayed, allowing you to select the recipient.
The Notification Type field supports these choices: Current Assignee, Reporter, Project Lead, Component Lead, Single User, Group, Project Role, Single Email Address, All Watchers, User Custom Field Value, and Group Custom Field Value. Please note that:
- When the Notification Type is set to "Group," the groups that can be selected as the recipient are based on what the Jira Administrator has set for the Groups delegation.
- The Group Custom Field Value option does not appear unless the Jira Administrator has delegated one or more fields of type "Group Picker (single choice)" or "Group Picker (multiple choice)."
- The User Custom Field Value option does not appear unless the Jira Administrator has delegated one or more fields of type "User Picker (single choice)" or "User Picker (multiple choice)."
Once you have supplied the Notification Type and recipient, click Add to save your changes or Discard to abandon them.
Removing a recipient
To remove a recipient, simply click the Delete link alongside the desired event recipient.
Click Close when you are through adding or removing notifications.
Work with project priorities
To add or remove priorities, click the Project Priorities button located at the top of the screen.
Priority Scheme in the self-service
The "Selected Priorities" section shows the priorities present in the priority scheme associated with the project. The "Available Priorities" section shows the remaining priorities available in Jira.
You can drag and drop priorities and click on the save button to save the changes. Priorities present in the "Selected Priorities" section is associated with the project similar to Jira.
Migration dialog (Similar to the dialog shown in Guided Path mode) is shown if the source priorities (associated with the project) and the destination priorities (selected priorities for the project) are different and there are some Jira issues with the source priorities.
Priority Migration in the self-service Project Group
There are 3 cases where the priority migration dialog is shown for the mapping between old to new priorities:
- When a project is joining an existing project group — If the project joining a project group has different priorities than the projects in the project group and has issues with those priorities, the migration dialog is displayed for priority mapping
- When the priority scheme is edited in the "Project Priorities:Edit" dialog
- When a project is exiting a project group and select "Remove ONLY this project from the Project Group"
When a project is exiting the Self-Service and you select the below option:
The following message dialog is shown if there are some projects that have issues that need an old to new priority mapping.
If a user selects Yes, all the projects present in the group are restored to their original schemes (schemes present prior to joining the Self-Service) and old to new priority mapping does not occur.
If a user selects Cancel, all the projects are in the Self-Service project group.
If a user wants to separate the project from the project group, Exit Project Group can also be selected from the "Actions" dropdown.
User is asked for confirmation before exiting from project group.
When user disables the Self-Service mode for a project, user is asked for confirmation like below whether to retain current configuration or restore original configuration of a project.
- In case if user chooses the option "Return the project to its original configuration" and confirms, all the changes that were made to the project while in Self-Service mode will be lost.
- In case if user chooses the option "Retain the current project configuration" and confirms, all the changes that were made to the project while in Self-Service mode will be retained even after exiting from Self-Service mode.
