Skip to end of metadata
Go to start of metadata

Unable to render {include} The included page could not be found.

On This Page

Video: Self Service Mode Overview

The following video provides a helpful high-level overview of the user features available in Self Service mode within this add-on. See the documentation below for additional details.


A JIRA Administrator configures the Delegated Project Admin Pro for JIRA add-on 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 add-on.
  • A JIRA Administrator has not delegated any project administration capabilities to you or any group of which you are a member.

Sidebar (expanded)


Sidebar (collapsed)



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, and adding or removing values from a Select List.

  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:

ItemDescription
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 usable, 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.

(warning) 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:

ItemDescription

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.

(warning) 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:

ItemDescription

Affects Version/s,
Assignee, and Attachment
 

Each of these indicate a Field available to the project via the currently selected Process Template. There will be 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:

  1. Make the current Field required or optional.
  2. Add the field to the Create, Edit, or View Issue screen. Once it has been added, you will also be able to reposition it.

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.

The Delegated Project Admin Pro for JIRA add-on will display a warning at the top of the screen (as shown below) when a Process Template's 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 will have 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.



(warning) 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:

ItemDescription
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 will move 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 will appear. 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 () to move the field to another position on the screen or click Delete to remove a field from the screen. When you are done, click click Close to close the screen when you are through making changes.

        
Before adding the Affects Version/s field                              After adding the Affects Version/s field


(info) If you added a Field and no transition screen previously existed, one will be created and you will now see the icon next to the transition.

Click this icon to remove the 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 will appear.


  • From represents the status the issue is currently in. This can be any existing Status, as long as the JIRA Administrator has chosen to delegate it. You can also select "Any status" to make this new transition a "global transition" – one that is available to be triggered from any status.
  • To represents the status to which the transition will take the issue.
  • Transition Label is the name of the transition that the user will see.

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.

The following screen will appear. 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.

(warning) 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. 


  • No labels