Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

NEWS

New location on issue screen

Based on customer feedback, the "Group Sign-Off" panel has been put on the (larger) left side of an issue view, now.

If you do not see it, just open the "more" menu and click on the "Group Sign-Off" menu item as displayed on the sample image. Then, your approvers will be listed on the left side of Atlassian new issue layout. All other functionalities remain the same as documented below.



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

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 by the specified user or by the provided JQL function currentUser(). Saving such JQL filter by name and share it, each user can self-configure how often and when receiving such feedback from the system like every morning from Monday to Friday at 8:00 AM. 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. If you combine this with auto-transitioning, you can update the JQL by also taking the issue's status into account. So, just issues which are pending would be populate on the filter result list.

Easily, you can search for all issues, which have to be decided by a specified user and being in status e.g. "onhold" via a JQL like:

issue.property[approvals].decidersĀ ~ "fpolscheit" 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.

According to the necessities of GDPR, the user's account Id will be written into the property instead of the human readable username, now!




  • No labels