| Table of Contents |
|---|
Specify the location on issue screen (larger left or smaller right side)
Please ask your administrator for putting the "Group Sign-Off" fields as larger panel on the left side or alternatively as openable panel on the right side. On the sample screencopy, you see "Group Sign-Off" panel left and e.g. "Traffic-Lights" on the right side.
So, you can choose what suits your needs: add the "Group Sign-Off" panel on the larger left side or use it on the right side (default). Left side panels will be automatically expanded.
Team-managed projects
Using a team-managed project, please click on the project key in the breadcrumb on the top of your screen to get the menu as displayed on the sample screen copy: there, you'll find the menu item "Group Sign-Off fields" to configure additional fields like an admin does, globally or for all company-managed projects.
Usage
Being logged in as a decider
Viewing an issue as a valid decider, the responsible user has the opportunity to click on the button "sign-off" or "decline": inline editing without the need to click on the "edit" button in order to enhance user experience. All other deciders are also visible.
Auto-Transition if finally signed-off / declined
If your Jira administrator has configured auto-transitions depending on the final decision (signed-off or declined) as well as blocking-conditions on related workflow transitions, then an issue will be automatically switch it's status, for example: it has been blocked until a final decision is available and then transitioned to "To Do" if signed off.
Being logged in as normal user
As normal user, you will just see "pending" decision: individual decisions are not visible as this is out of scope, here.
Transparency for everybody
The final result of the decision will be displayed as comment of the related issue to everybody, regardless if normal user, decider or administrator: a list containing all individual decisions, deciders and timestamps of deciding for transparency. This may also help to remember own voting.
Notifications for deciders (search issues for pending decisions via JQL)
Each time, an issue is displayed on screen by any user, all current deciders are determined and updated within issue.property[approvals].deciders. This field can be used within a JQL statement as show on the screen shot on the right.
I try to reduce the number of email notifications to the minimum, based on my experience of the last 15 years in many customer projects: instead, I recommend to use Jira's filter subscriptions to get frequent overview emails containing a list of all issues, which have to be approved. This is much more effective then continuous breaks by disturbing, poping up emails!
If you are not familiar with Jira's feature of filter subscriptions, please have a look into the Atlassian documentation at https://confluence.atlassian.com/jira064/receiving-search-results-via-email-720416706.html
Using a JQL as displayed on the right, a decider will get a list of all issues, she/he participates on at least one approval. May be, that's too much, but you can also combine that JQL with other JQL functions to reduce the result set to your needs.
Easily, you can search for all issues, which have to be decided by the logged-in user and being in status e.g. "onhold" via a JQL like:
| Code Block |
|---|
issue.property[approvals].deciders ~ currentUser() AND status = "onhold" |
The indexed data are a list of all deciders including their decisions within a single string like: "admin (multi users) | fpolscheit (multi users)" having no vote or "fpolscheit(Manager)=Y:2018-09-16 13:57 | someOneElse (Manager)". The name in brackets after the user name is the name of the referred field within the related conditional/dynamic rule and set automatically. The equal sign is followed by the voting: "Y" for yes or "N" for no as well as a timestamp after a separator colon. So, you can also search for e.g. all issues, which have been vote dated on "2018-09-16", too.
More privacy and GDPR
According to the necessities of GDPR, the user's account Id will be written into the property instead of the human readable username, now! Therefore, the JQL statement has to be adjusted accordingly. Instead of the prior username you have to enter the related account id or use the JQL function "currentUser()".
| Code Block | ||
|---|---|---|
| ||
project = ASAMPLE AND issue.property[approvals].deciders ~ "557058:7b5dfd59-30f7-4f0e-864d-34fb8ba6e452" AND NOT issue.property[approvals].deciders ~ "557058:7b5dfd59-30f7-4f0e-864d-34fb8ba6e452=Y" AND NOT issue.property[approvals].deciders ~ "557058:7b5dfd59-30f7-4f0e-864d-34fb8ba6e452=N" |
The simplest way to find out the account id for a user is to navigate to the People page inside of your Jira cloud instance which you can view by navigating to the URL of https://yourJiraCloudBaseURL/people/search. On this page you can search for the name of the user that you need to find the accountID for: you will find the account ID in your browser's URL after /people/ like within the sample below.
