We call these users the Atlassian AllStars.
They are an online community of Atlassian users, experts, and fans.
This community offers opportunities to learn more about our products,
to take part in exclusive surveys and interviews, to leverage content and to connect to like-minded fans.
If you think you have what it takes to become an Atlassian AllStar, apply here!
This week we will focus on tips and tricks for JIRA Admins and power users.
Create an email subscription to an issue filter where priority is critical and the issue is unassigned. Set it to email a support group every 15 minutes (or x minutes) until someone takes the issue. This has been great for us in identifying high priority issues.
Don’t forget to set the "Fire an event that can be processed by the listeners" post function on each transition in your workflow. This will make sure that the correct notifications will be sent out.
Requirements traceability between Confluence and JIRA has been useful for keeping our requirements in one place as a single source of truth. Using the Requirements Blueprint in Confluence we can create all our requirements (and documentation) and then generate the JIRA issues from the requirements table.
This automatically creates the JIRA issues based on the information in the requirements, as well as creating a two way link between the Confluence page and the JIRA issues. Now when we need to make changes to requirements we just edit the page (one single source of truth) instead of using the JIRA comments.
You can set up an organisation-wide simple "to do" project for personal use by individuals by using JIRA’s "Reporter Browse" permission to allow only the person creating their to-do items to see them.
The JIRA REST API was a major help when doing the initial migration of tens of thousands of Bugzilla issues. Only a small number of API calls and a handful generated scripts were used with great efficiency.
My quick tip for JIRA is the CHANGED option in JQL. Effectively, this allows you to find out much more information about how a particular field has changed over time. Let’s say we’re a Project Admin, and we need to know which issues have moved from "In Test" to "In Progress" this week (even if they’re back in testing now). With the CHANGED function, this is simple:
status CHANGED FROM "In Test" TO "In Progress" AFTER startOfWeek()
A big thank you to all contributors, you are awesome! Be sure to come back for the next part next week!