Video: Self-Service Mode Overview

The video provides a helpful high-level overview of the user features available in Self Service mode within Delegated Project Admin Pro. See the documentation below for additional details.

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 this configuration has been done, a Delegated Project Administrator will 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 will not see this sidebar option if any of the following are true:

• 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

Entering 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 will appear 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 will remain 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 will be able to view the Delegated Project Admin configuration of the project. However, they will be unable to perform a Self-Service action unless a JIRA Administrator has delegated that capability to them

Overview of Self-Service Mode

By default, a project will be 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 Administrator 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 lesser capability than another, because of differing 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 will still be able to view its project configuration if the project is put into Self-Service mode, however you will 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 will have 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 various sections of the screen are:

1. Process Templates: renaming or removing Process Templates, or creating a new Process Template by copying another
   

2. Issue Types: Adding or removing Issue Types that are available to the project via the currently selected Process Template

3. 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

4. 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

5. Project Permissions: granting or revoking JIRA project permissions to a user, role, or group
   

6. Project Notifications: adding or removing recipients for a notification that is sent when a workflow transition or issue operation occurs

7. Self-Service mode: Exiting Self-Service mode

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 will be discussed in the following sections.

Working 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 will have 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 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 will affect that Process Template.
	Click this icon to rename the currently selected Process Template. The following screen will appear. Supply the desired 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 will appear. Supply a name for the new Process Template that will be 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 will be 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 will 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 will appear. 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.

Working 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 indicates it is of type "sub-task" rather than a "standard" Issue Type. There will be as many rows as there are Issue Types in the currently selected Process Template.
	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 will see the message shown below. You aren't allowed to have a Process Template with no Issue Types, hence it recommends 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.

Working with Fields

This is how the Fields section of the screen appears:

Each item is further described below:

 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.

Working with the Workflow

This is how the Workflow section of the screen appears:

Each item is further described below:

 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.

Working 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 will appear:

Adding a permission

To grant a permission to a new recipient, click Add permission next to the appropriate permission. The Add Permission screen will appear, 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, and User Custom Field Value. 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 will 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 will not appear unless the Jira Administrator has delegated one or more fields of type "User Picker (single choice)" or "User Picker (multiple choice)"
• You cannot select Application Role in the Permission Type field. This is by design, as it would make it too easy for a Delegated Project Administrator to grant a permission to all logged on users. If you are sure that you would like to grant a permission to an Application Role, please ask your Jira Administrator to do this for you using the native Jira Administration screen

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. 

Working 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 will appear, 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 will appear, allowing 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 will 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 will 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.