App Review: Custom Charts for JIRA by Old Street Solutions

July 8, 2020July 10, 2020 Rodney N.Leave a comment

Just going to start this off with a simple statement: I love dashboard gadgets. I don’t think that’s controversial. The fact that JIRA gives us this excellent way to parse, sort, and display the data within issues makes it unique. But, sometimes, I find the default gadgets a bit limiting.

VisualScript does help. It’s crazy flexible, but to get the most out of it, you need someone who knows JavaScript. And we don’t always have that luxury. Don’t get me wrong, the built-in library and Community make it an easy purchases, but what else is out there?

That’s where this week’s App comes in. For the second week of App Month, we will review Custom Charts for JIRA by Old Street Solutions. This App claims to allow us to make custom reports for our Dashboards without any code. Let’s take a closer look to see how they pull this off!

As with last week, we’ll look at what it does and how it does it. Then we’ll review what it does well, what it could do better, would I recommend it, and where does it rank. Let’s get into this.

Custom Charts for JIRA

Charts

So, as a rule of thumb, any App I consider has to solve something your current instance cannot do well. If you already have an App for that functionality (or worse yet, it’s something JIRA can do on its own), why bother?

That also makes my first question for any App easy. “What problem does this even solve?” That is usually followed very quickly by “What do we have that also does that?”

In this case, the problem we are solving is that JIRA only has so many dashboard gadgets, and given that, you can only parse issues so many ways. Not to mention the built-in gadgets rarely respect any order, will not let you manually set a sort-order, and generally, you have to have a filter pre-setup.

Custom charts solves this by giving you a new gadget (aptly named Custom Charts). Here you can display several different graphs. Specifically, they are:

Pie Chart
1D Bar Chart
2D Grouped Bar Chart
2D Stacked Bar Chart
Funnel Chart
1D Table
2D Table

Now you might be saying, “Hey, Rodney, you might have a problem. Several of those are already on JIRA.” Well, if that’s you, You are correct! The Pie Chart, 1D Table, and 2D Table are already present in the default set of Gadgets. So, what sets them apart?

Customization Interface!

That’s correct. Unlike the built-in offerings, you can customize these charts to the nth degree.

You can also change the filter, as well as use JQL instead of a saved filter. This feature is significant – sometimes, when I want to change the information displayed, I don’t want to find the filter, bring up the filter, change it, go back to the dashboard, and repeat until I get the changes in place. This simple option lets me adjust the JQL right there in the gadget.

The gadget also lets you change the order to anything you desire, and tweak what the App shows on the gadget. On the appropriate charts, it will even let you change grouping (and its order)! Basically, there is no part of the chart that there isn’t an option for.

Search Gadget

This one is a bit harder to wrap your head around – but can be amazingly powerful. When you are setting up your charts, you have three options for the source.

You have saved filters, which works exactly as it does for the default gadgets. Next, you have the JQL setting, which we have already discussed above. And finally, you have a third option, the Simple Search Gadget. This feature lets you pull from a gadget that defines search criteria for all other gadgets configured to use it.

This gadget makes your dashboard a living board that responds as you adjust and refine the criteria. Let’s say you want to drill down into work being done by Van Helsing. Just change the settings on the Simple Search Gadget, and the rest of the board responds upon your button press!

Upcoming feature!

Old Street Solutions does something beautiful I wish more companies did. They have their roadmap available for anyone to view! No joke, you can see it here:

Custom Charts for JIRA Roadmap

I’ve been talking with the team at Old Street for a bit now. They acknowledge that they do not support Date fields currently. However, they are pending a release any day now that will fix this. As it is not a feature I can currently test, it should remain something you look at in your decision making.

Why this instead of VisualScript?

So, remember when I said part of my general App evaluations includes asking “Will JIRA already do this?” This is where that question comes in. I personally cannot help but to compare this App with VisualScript. So, why choose this one?

While they both perform similar functions, I see VisualScript and Custom Charts very differently. VisualScript is very flexible – it can do anything you want so long as you can program it. For some JIRA Admins, that is an okay tradeoff.

In comparison, Custom Charts is not as flexible. But that is alright. Their niche is to provide you richer and more customizable gadgets than the default set. They won’t do everything, and they don’t have to. If Dashboards gadgets are a line graph, the default Gadgets would be on one end, VisualScript on the other, and Custom Charts somewhere in the middle.

My Analysis

What this App does well

It does what it says – allow you to make fully customizable charts. There isn’t an option on the end view that you can’t tweak. The ability to tie all of them to a Search Gadget is just icing on the cake. I love it when a company provides me a feature I didn’t even know I wanted!

On top of that, the company is open about its Roadmap and what they intend to do. In a world where getting decent Release Notes seems impossible, having a roadmap was an unexpected pleasure.

What this App could do better

Honestly, I was hoping for more charts. In a world with seemingly a million ways to display data, the seven given feels a bit limiting. I see the line chart on their Roadmap, though, so I’m not the only one who missed it. Maybe this is something they intend to grow as they have time. But honestly, that’s about it. It’s a robust offering that you can tell was built with intent and care!

Would I recommend it?

Very much so. There is a niche here for people who want more control over the information displayed through Dashboards, but do not want all the setup and power VisualScript brings to the table. I feel Custom Charts sits comfortably in this niche.

Just be warned, once your users have a taste of what this App can do for their dashboards, they may never go back to only using the default set again!

Custom Charts for JIRA’s Rank

So, I like the idea of keeping up with my App Ranking board as I review Apps. I’ve added both of the ones I’ve done for App Month. I just feel it’s an easy way to represent how these Apps compare to each other.

Custom Charts was harder to place than the Admin Toolbox last week. It does only one thing, but it does that one thing VERY well. So, I felt it earned it’s “A” Rank.

This App won me over on its ease of use. Anything I can give users where they can just figure it out without hand-holding gets a win in my book. Then there were the features that surprised me. As I stated before, I always love to find a feature already present I didn’t know I needed – like the Simple Search. Great Job on this App!

So what do you think?

I am so far finding some great Apps this month that have just been lurking on my “To check out eventually” list. I know I always need to keep on top of what’s available in the marketplace, but it’s easy to get behind on that. What are some of the lurkers on your list? Have you been inspired to check them out?

If you enjoyed this post, stick around! We will have at least three more App reviews this month. We also have a whole collection of tips, tricks, and how-to’s to help you get the most out of your Atlassian Instances! Don’t forget you can sign up below to receive emails as soon as we release a new post.

You can also follow me on Twitter, Facebook, and LinkedIn! Be sure to like, share, and comment on the various social media platforms to tell them that they need to show these posts to others! You’d be surprised what a difference it makes! But until next time, my name is Rodney, asking, “Have you updated your JIRA Issues today?”

App Review: Admin Toolbox by Decadis

July 1, 2020July 10, 2020 Rodney N.Leave a comment

A few weeks ago, I posted my “JIRA App Tier List, ” You all loved it.

However, a few of you wanted to know why I didn’t include your favorite App. As I was going to speak on the strengths and weaknesses of each, I felt it wasn’t fair to judge an App with which I wasn’t familiar. So I decided only to include Apps I have either used before or have personally demoed.

However, in July, I intend to fix that. Each week I’ll be reviewing apps from different vendors in what I call “App Month.” These are all Apps that people have approached me about since publishing the article. If you have a favorite App we have yet to look at on the blog, please share it so I can look at it. I actually keep a list of these to review as I have time!

For our first run, we will be looking at one of the Xapps collection from Decadis: Admin Toolbox for JIRA. On the tin, it says it will help make admins’ lives easier. Let’s take a look and see just how they do this.

Admin Toolbox for JIRA

To quote the Marketplace listing for this App, “Admin Toolbox for Jira was built by Jira Administrators for Jira Administrators to save time providing the following functions.” Going down the list of functionality, I can see how some of these functions would have made my life easier. Let’s take a look at the features.

Configuration Search

This single feature, if I’m honest, would likely be my most used feature. By pressing “g” then “x” in short succession, you get a menu that can search all the configurations for settings.

Do you need settings relating to a specific field? Then type that field’s name, and boom, you’re there.

Same with Schemes, Projects, Screens, Workflows, anything! If you can find its name, you can go there directly. And if you include the Project Key in your scheme names, you can even do this excellent trick.

Considering you will spend most of your time in the UI, anything that will help you navigate it easier is an easy win. A thumbs up for this feature!

Copy Transitions, Validators, and Conditions

Completely custom workflows can be the worse, am I right? I mean, you have to go into every transition and do something. Add a validator. Add a post function. Tweak a condition. And it is often very repetitive, as you are just making slight variations on the same setup repeatedly. Makes you wish you have a copy and paste for workflows?

Well, Decadis heard out wish. The Admin workflow allows you to copy a post function, condition, or validator to any other part of the workflow – or even another workflow altogether!

I don’t know about you, but this would speed up my custom workflow builds by quiet a bit! It takes one of the most monotonous parts of the process and speeds it up. This is fast becoming a theme, no?

Workflow Report

This one solves a problem that even Botron’s Power Admin won’t fix. When you search an App in Power Admin, you might notice a blank spot.

However, when we use the Admin Toolbox’s Workflow report, under the Transition Attribute Report tab, we can see exactly how many transitions are using which apps.

This handy little tool will also tell you when your workflows have problems through the Error Tab.

Yes, I purposely uninstalled the JMWE App to produce this error. Thank you for noticing.

This kind of reporting was always a blind spot in my Plugin analysis. I’m glad to finally have a tool in the tool-belt to deal with this once and for all.

Project Shuttle

So this feature I’m mostly on the fence. What it does is add a new menu that lets you define your projects and how they relate to each other. For larger companies that have a lot of projects, this could be a game-changer.

However, I’m always hesitant to change JIRA’s navigation too much. It can cause problems for new employees at your company that are familiar with JIRA from other companies.

Another problem I have is it reuses the term “Project Category” without using the existing settings by that name. This change is yet another source of confusion for JIRA Admins that are not familiar with this App. A minor pet-peeve, I’ll admit, but there it is. I cannot tell you how many times I feel for traps like this when I was a new JIRA Admin.

However, I feel the win for ease of navigation far outweigh any (admittedly) personal hang-ups I have on how it’s done.

My Analysis

So, I’m going to try something different for App Reviews moving forward. I’m going to look at four things: what I think the App does well, what I think they could improve on, would I recommend the App to you, and where it ranks on the Tier list. I don’t know how well this will work, so I’d love to hear your feedback! Let me know what you think of the featured Apps this month!

What this App does excellent.

It seems their tagline of “built by Jira Administrators for Jira Administrators to save time” appears accurate. Every feature saves you time in either navigation or information collecting. I can easily see scenarios within my career where tools provided would have saved me so much time.

For Example, there are days even now where I’ll look at some change I want to make, and I’ll have to go, “Where is that setting again?” And I’ve already discussed how monotonous it could be making a bunch of the same transition post functions in a large workflow. So yeah, the main benefit of this Apps is the time savings it can give you by making your life that much easier.

What this App can improve on.

As I stated, my biggest quip is the reuse of the term “Project Category” in the Project Shuttle feature. I’d personally like them to use the built-in categories already in JIRA. But, I also don’t see an easy migration path to that without upsetting a lot of customers, so I think I’d have to deal with this.

My other thought on what it can improve is also not easy to fix, based on its concept. As a general rule of thumb, any App that only benefits one team has a higher burden of proof than one that can be used by everyone. That is to say; I’ll need to see a greater need for it than I would say a dashboard gadget.

This policy isn’t me being picky. Apps can be expensive! Spreading that cost by having more users use it makes it easier to justify. Therefore, the inverse is also true – an App that only benefits a few should be harder to justify.

Would I recommend it?

Yes. Absolutely yes.

I bet you already figured that if I went through all this trouble to write this post. It either had to be that bad or that good. Thankfully this one is the latter.

Look, fellow JIRA Admins. Our jobs are hard. We have to balance management’s need for insight, the user’s need for ease-of-use, and the system’s need for stability. So I’m all in on anything that will make that job more manageable. And I see this App doing just that.

So do yourself a favor. If you have a few cycles, load this up on your Testing instance, and play around with it. You won’t be sorry.

Tier List Ranking

So, now that it has my recommendation, how does it rank? To be clear, every App on the tier list has my recommendation. But I fully acknowledge that some are just better than others.

Looking at this App, it’s a robust offering. It does have a few flaws, but those are admittedly nit-picks. More importantly, it actually does what it sets out to do. It’s not groundbreaking, but I feel it earns an easy “A” Rank.

And that’s the First App of App Month down!

So, let me start with another thank you to all the readers out there. When I started posting regularly to the blog, I would have honestly been happy if my potential employers would have read it. After finding a job, I would have been happy if I at least helped someone else in their career.

But this is just crazy. As I’m writing this, we just hit out 1700 page views in June. And we also topped 1000 visitors to the blog! You readers didn’t just break the one-month record; you smashed it! That is more than I ever thought would ever visit my humble blog. So thank you to everyone who shares the blog with their colleagues, comments on it on social media, and helps this blog continue to grow. You all are what drives me to keep posting each week.

In speaking of social media, don’t forget to follow the blog on Facebook, Twitter, and LinkedIn. While you are on the various social media platforms, don’t forget to like, comment, and share the blog. Doing this lets the platforms know you like the content we have here, which will cause them to share it on! You can also subscribe to receive posts directly to your email by using the form below! But until next time, my name is Rodney, asking, “Have you updated your JIRA issues today?”

Integrating your Atlassian Cloud with Azure AD

June 24, 2020July 10, 2020 Rodney N.Leave a comment

Well, today, it seems we are going to do something I admittedly rarely do on the blog. That’s right; today, we are going to admit that JIRA Cloud exists!

It’s not that I have anything against JIRA Cloud. My specialties tend to lie around making sure the underlying JIRA system runs as smoothly as possible, which is hard to do when you don’t own the underlying system. However, there is still plenty of overlap between JIRA Server/DC and JIRA Cloud, so it’s not like I’m unqualified to speak on it!

So it’s no secret at work that I maintain a whole collection of personal test systems. I do this to replicate and test just about anything I want without waiting for permission. The environments include (but are not limited to):

VCenter Environment for VM’s
More Raspberry Pis than I rightly know what to do with
AWS Account
Azure Account
Cloud Environments of Confluence, Bitbucket, JIRA Software, and JIRA Service Desk
Server Environments of Confluence, Bitbucket, JIRA Software, and JIRA Service Desk
Several VPS online, including one running (wait for it…) Confluence.

This is RACK01. As in, “Yes, there is also a RACK02”. I…I might have a problem.

So, when my manager wanted some help looking into some oddness he saw in JIRA Cloud using Azure AD, he knew who had the tools to recreate and test that setup.

However, I didn’t know how to set up the integration when I started. So I had to learn that. And since I had to learn, I might as well help you learn too!

Pre-reqs

To pull this off, you will need a few things first.

An Azure AD subscription. If you don’t have a subscription, and just want to do some testing, you can get a one-month free trial here.
Atlassian Cloud single sign-on (SSO) enabled subscription.
To enable Security Assertion Markup Language (SAML) single sign-on for Atlassian Cloud products, you need to set up Atlassian Access. Learn more about Atlassian Access.
A Claimed Domain with Atlassian. To do this, you will need to be able to modify the DNS records for your domain.

Also, we cannot forget the documentation. This actually was from Microsoft, and not Atlassian! Shocking, I know. But it was on point and guided me through most of the process.

Setting up Single Sign-On (SSO)

Single Sign-On, or SSO, is a mechanism that does what it says on the tin. If you log in to any application participating in the SSO environment, you will not be required to re-enter your password to sign into any other participating app. So if both your JIRA and Confluence are a part of the same SSO environment, you can start working in JIRA, then move over to Confluence without having to pause to authenticate again.

To get started, go to your Azure AD Directory, then click “Enterprise Applications” in the sidebar (underscored in red). This page is where you will set up the Integration with Atlassian Cloud.

Now that you are on the Enterprise Applications Screen click “New Application.”

In the search bar shown, type “Atlassian Cloud”. Doing this will bring the integration up in the search results. Once it appears, click on it.

Clicking the search result will cause the following menu to Pop up on the right-hand side. You won’t need to modify anything here, so you can click “Add” at the bottom of this menu.

We can safely skip “1. Assign users and groups” for now. Proceed by clicking “2. Setup Single sign-on.”

On the next screen that appears, you are presented with three choices. Select the second option that says, “SAML.”

Next, you will get a pop-up asking about Saving. For now, click ‘No, I’ll save later.”

You can save Section 1 on the next screen for later – as you will need information from Atlassian to complete this section. Instead, move onto Section 2 by clicking it’s “Pencil” icon.

Here, we’ll only need to update one attribute. By default, Azure AD wants to send the user’s Principle Name to Atlassian Cloud. However, Atlassian wants the email address in this field. So to change it, click “Unique User Identifier (Name ID).

Doing so will cause the following form to appear. Change “user.userprincipalname” to “user.mail” under Source attribute, then click “Save.”

On the Navbar, click “SAML-based Sign-on” to return to the previous section.

With the Attributes & Claims ready, we can start collecting information Atlassian will need. To begin with, download the Base64 Certificate in Section 3 to your local system.

The next three pieces of data we will need are in Section 5. Copy the three URL’s highlighted below to a notepad you can reference later. To find them, you will need to expand the “Configuration URLs” Dropdown menu.

Now we can switch over to Atlassian and start the setup there. Under your https://admin.atlassian.com admin page, Select Security →SAML single sign-on

On the page shown below, click “Add” SAML configuration.”

Now we can start entering the information we got from Azure AD. Be sure to pay attention to how I have it mapped below, as Atlassian and Azure have different names for each field.
- Enter Login URL from Azure into the Identity provider SSO URL field
- Enter the Azure AD Identifier from Azure into the Identity provider Entity ID field

Now open the Certificate you downloaded in Step 12 in a text editor of your choice. Copy the contents into the Public x509 certificate Field, then click “Save.”

Now we will need to give Azure some information on your Atlassian Cloud setup. To do so, copy the “SP Entity ID” and “SP Assertion Consumer Service URL” fields from the next page.

You remember in Step 8, when I had you skip Section 1 on Azure’s SSO Configuration? Now is when we will go back and fill it in by clicking the “Pencil” icon.

Here we’ll copy in the two URLs we copied in Step 18 into the two highlighted fields. Be sure to pay attention below, as again, Azure and Atlassian disagree on what to call these fields.
- The SP Entity ID field from Atlassian goes into the Identifier (Entity ID) field in Azure
- The SP Assertion Consumer Service URL field from Atlassian goes into the Reply URL (Assertion Consumer Service URL) field in Azure
- Be sure to click the “Default” checkbox next to both, then click “Save”

You should get a Pop-up asking if you want to Test single sign-on. Click “Yes”. This will open the following screen. If your user is already provisioned in Atlassian Cloud, click “Sign in as current user”

Congratulations, SAML SSO is now setup!

Setting up User Provisioning

So, we have SSO setup. Great!

As things stand now, you still have to go and manually populate every new user in your Atlassian environment. Not Great.

To resolve this, we’ll next setup User Provisioning, which also does what it says. This process will automatically set up new users in your Atlassian Cloud system as you add them in AD. Which, once again, will be Great.

Go back to the Atlassian Cloud Integration page in Azure. This is the page from Step 5 of the SSO setup above. Once there, click “Part 3. Provision User Accounts.”

On the next screen, we will select “Automatic” under Provisioning Mode:

Next, we’ll need to set up some things under your Atlassian Access screen (https://admin.atlassian.com). To get started here, click “Back to organization” → Directory → User Provisioning.

Now we will click the “Create a Directory” page to get started here.

Enter a Name for your Directory. To keep it descriptive, I like to copy the name from the Azure Directory. After we enter the name, click “Create”:

With this created, Atlassian presents us with two pieces of information that we’ll need to give Azure. Copy both the URL and the API key.

Back within Azure, we will enter both of these into the Admin Credentials section. Again, be careful here as Atlassian and Azure disagree on what to call them.
- The Directory base URL from Atlassian will go into the Tenant URL field in Azure
- The API key from Atlassian will go into the Secret Token field in Azure
- Be sure to test the connection after you enter both
- OPTIONAL: You can also enter a Notification Email to get failure notices.

On the next page, Mappings, you can use the defaults as-is. Just click “Next.”
Under Settings, Set “Provisioning Status” to “On,” then Set Scope to “Sync Only Assigned users and Groups.”

Click “Save,” and you are done!

Azure AD will not sync your selected users to Atlassian automatically! But which users will Azure sync? That is the focus of our next section!

Adding Users and Groups to sync to Atlassian Cloud

So with our setup right now, we have Azure syncing over only selected users to Atlassian. We set it up like this because if you sync everyone and have a large AD environment, you can quickly find yourself out of licenses on JIRA. So let us explore how we tell Azure which users it needs to set up in Atlassian Cloud.

Back on the Atlassian Cloud Overview Page (again, from Step 5 of the SSO Setup), click “Users and Groups” from the sidebar.

On this screen, click “+ Add User” at the top of the screen.

Click “Users” then select the Users that Azure should sync with Atlassian Cloud. Repeat for Groups that you would like to also sync over to Atlassian Cloud.
Note: As I did my testing on Azure’s free tier, I didn’t have groups available to get a screenshot of. Sorry!

Select Role then click Assign. Congratulations! These users will now be populated into Atlassian Cloud during the next sync operation!

And that’s it!

You now have your Atlassian Cloud environment setup and ready to use Azure for Authentication! If you are already leveraging Azure AD to manage your users, it is just one less headache to worry over.

Job Seeker Profile!

So, it does happen where someone searching for a job will contact me to ask if I know of any open positions. Unfortunately, I am not always able to help them in that regard. However, given the uncertain times we live in, I want to do something. So I’ll feature them here.

That is the case today with Siva Kumar Veerla from Hyderabad, India. He has recently been thrown into the job market due to the COVID-19 Pandemic. From his CV, he is a solid Atlassian Administrator who has led several projects, including upgrades and system installs. He is currently looking for opportunities in India or Europe. If you think he might be a good fit for you, please feel free to contact him on LinkedIn or through the information on his CV.

sivakumar_resume Download

And Other exciting things!

Let me just say…Wow. This month has been amazing! For starters, look at this.

https://t.co/ih9AYrgTAN Blog just hit 1200 page views in a month for the first time ever! And we still have a week left in June! XD pic.twitter.com/Mal6y3v9V0
— Rodney N (@theJIRAguy) June 23, 2020

Yes, that is a new record month for the blog! Thank you for continuing to read, comment, like, and share the blog on the various Social Media platforms.

I’d also like to thank Predrag Stojanovic especially, who pointed out an Atlassian Group on Facebook. And well, that group loved last week’s blog post! So, I’ve gone ahead and set up a Facebook page for thejiraguy.com blog! Like Twitter, like this page to get the latest posts from the blog and random Atlassian news I find interesting! You can also subscribe below to get new posts delivered directly to your inbox!

Also, I will be giving a presentation tomorrow on Monitoring your Atlassian Applications using Nagios! If you are in the Atlanta, GA area, tune in Thursday! If you are not, I am trying to refine this presentation to submit to Atlassian for Summit. So, with a bit of luck, you’ll be hearing it from me next April!

But until next time, this is Rodney, asking “Have you updated your JIRA Issues today?”

More JQL Tricks

June 17, 2020July 10, 2020 Rodney N.2 Comments

Well, we’ve made it another week. And let me tell you what a week it was. You guys killed it on the previous post – it’s currently the second most viewed post on the blog – and on it’s way to becoming number one! Thank you all so much!

Today’s topic also mirrors another popular post. I am looking at several more JQL tricks you can use to optimize your queries. Some of these are suggestions that I got in response to my previous post, some are new tricks I’ve learned, and some are stuff I cannot believe I missed. Lets get rolling on this.

Starting with the Basic search

So this was one of the ones I got as feedback from my previous article on JQL, thanks to Ed Gaile. And the trick is so simple I am ashamed I forgot to include it. This trick is when you start building a new query – start in basic mode.

Starting with the basic search will allow you to define parameters easily. Then, once you do so you can switch to Advanced, you can see and edit the JQL String.

One of the most significant benefits of using the basic mode first comes with adding a time-based parameter. When you do so, this handy pop up will appear to let you define your exact timeframe with no hassles!

membersOf()

We covered previously how powerful the currentuser() function is. It will let us easily customize a single query to whoever views it. Let’s consider this situation.

Your QA team consists of Bob, Lisa, Jerry, Beth, and Chris. You want a query that will return everything assigned to QA. And go!

Your first instinct is to write a query similar to this:

assignee in (Bob, Lisa, Jerry, Beth, Chris)

While functionally correct, this can cause problems. Let us say Jerry is tapped to become a Program Manager. You now have to go back and update your query. Tom joins the team now to replace the vacancy left by Jerry. Another update. What if there is another way?

If your team is within a JIRA group, you can reference that group directly in a query. Let’s assume the same situation, but we know the JIRA Admins use group jira-qa to manage permissions specific to QA. We can then replace the above query with the following:

assignee in membersOf("jira-qa")

The benefit here is that the Admins will update the group to change out Jerry’s job function and on-board Tom, so your query requires no changes to stay up to date.

If your instance is using Active Directory syncing, you might also be able to leverage AD Groups directly in JIRA. The benefit here is as your AD Groups are updated, the change is automatically reflected in JIRA, and therefore your query!

lastLogin()

So this one is very situational. Let us assume that as part of a triage operation, you want to make a query that shows everything that users created since the last time you logged into JIRA.

You can write a query that looks for everything created in the past day, but that will only get half the data from the weekend. Plus, for most weekdays, that will include issues you’ve already triaged. Not ideal.

That is where the function lastlogin() comes in. This function will return a timestamp from your last login so that you can find new issues. In practice, it looks something like this:

issuetype=Bug and createdDate >= lastLogin()

This function also works with updatedDate and resolutionDate, so you can find issues that were updated or resolved since your last log in. For Triaging and reporting, definitely a good thing to have in your toolbox.

Filter using another filter

All right, here’s one I found as research for this post. And honestly, I didn’t even know it existed. You can reference another filter in your query, and add onto it!

filter = "Filter Name" AND ...

Yes, this is a real thing! You can use this trick to narrow down the results of a query further, or two build several variations on a query while abstracting out the common parts. It amazes me to this day that I can have studied this platform extensively for years, yet I can still find something I genuinely did not know!

Subscribing to a Saved Filter

So, let us go back to the Triage example from the lastLogin() section. You’re happy with the results, but you hate that you have to log in to JIRA each morning to get started. Maybe you’d like to review the results on the train while on your way to get a head start? You can use JIRA’s Mobile App, but that won’t remind you to do it.

There is a way to get JIRA to email you the result of your query on a set schedule. This trick is called a subscription, where JIRA will run the saved filter based on your permissions, and send you the results via email.

To set up a subscription, first navigate to your saved Filter. Then click “Details -> New Subscription”

Once there, you can set up which groups (to which you are a member) will receive the query. You can also select “Personal Subscription” (which is the default) to send it to yourself. Afterward, select how often you would like to receive the filter results and click “Subscribe.” Congratulations, you will now start regularly receiving the Query results.

Searching through the Past

So, it is now time for “Admin Storytime” with Rodney. Once upon a time, a Project Manager came up to the brave JIRA Admin nervous. One of the villagers wasn’t too smart and had closed many issues that shouldn’t have been. The Project Manager was scared that this would mess up their project, so he needed our hero’s help in finding all the closed issues and reversing the dreadful curse.

So what did the hero do? He did a historical searched using the Changed functionality.

For those not familiar, you can use “changed” to take a look at what a field value was, who changed it, what they changed it to, and when they changed it. In this case, the query looked like this:

status changed to Closed by Villager after startOfDay()

I would note that not all fields support this kind of searching – in fact, the vast majority doesn’t. Status, however, is one I can usually search the history on, so it’s handy to keep in mind.

sorting

Sorting your returns

So, most of the time, the order you get issues back in is not essential. But sometimes, it does help you understand the data if you can sort it by one metric or another. This situation is where the “Order By” function comes in.

reporter = currentUser() order by created ASC, updated DESC

This function allows you to specify what order you’d like to receive the results. For example, you can sort it by date created in Descending (DESC) to get a list of results sorted from the newest to the oldest. Put the field you’d like to sort by, and then the direction you want to sort on, and you are off to the races.

You can also sort by more than one field. For example, you can first sort by the assignee to get an alphabetized list of issues by assignee, then sort by Updated to get the newest issues touched by each user on top of each user’s results.

I should note that not all gadgets respect the Order By function, so your mileage may vary on Dashboards, but it’s still something handy to keep in mind.

So, what are your favorite JQL Tricks?

As I have noted, some of these I got from your comments on the previous JQL post. So what other JQL tricks do you have? Post your favorite tricks, and I may share them on a future post!

If you are in the Atlanta, GA area next week, I’ll be speaking during the first half of the (Remote) Atlassian Community Event on how to set up Nagios to monitor Atlassian Applications. I hope you will join us!

Don’t forget to comment, like, and share this post on social media of your choice to help spread the word! As I said, you guys have been killing it this month on the numbers, and I want to see if we can get an all-time high! Also, be sure to follow me on twitter at @theJIRAguy.

And as one last note, check out the newest Atlassian Blog on the block, run by my good friend Kris. She will also be posting weekly! Her blog will be more focused on the Super-User aspect, so it should be an different yet much needed point of view. http://www.notesfromkris.com/

But until next time, my name is Rodney, asking, “Have you updated your JIRA issues today?”

JIRA App Tier List

June 10, 2020July 10, 2020 Rodney N.2 Comments

Well, I wasn’t planning on doing another App Roundup for another few months. However, I was watching some back episodes of Tier Zoo on Youtube, and I had an idea that was too tempting to let go. What if I make a list of some JIRA Apps I’ve used before, and list them into tiers based on my experience?

So that is what we are doing today. I have a list of 15 Apps I’ve used on JIRA in the past and have ranked them based on their functionality, ease of use, stability, and general “it” factor.

Disclaimer

I should note that the below is my opinion. I have chosen every app on this list at one point or another, so I feel each app is worth the money. You are entirely free to disagree! I’ll be including a link at the end of the post to the tier list template, and I would love to see how you rank them!

Edit: It was brought to my attention I should probably note: These were originally tested using JIRA Server & Data Center. While I have used a few of these in JIRA Cloud, not all of the functionality is present or the same, so your results may vary.

The Tier List

So here is my Tier List. The rankings go from “S” for Superior, then “A”-“D.” The Higher up on the list you go, the better the App. My thought for the “S” Tier is that it should be genuinely mind-blowing and game-changing. That is why there are only two there now—the rest kind of fell where they did on a snap decision. However, I do intend to go through each App and explain my logic in placing it where I did.

“S” Tier

Automation for JIRA

Author: Atlassian

Marketplace Link: Here

So, some history – automation was never an easy thing to achieve in JIRA. Before this App arrived, your choices were:

Learn the API’s and have something operate elsewhere
Learn Groovy and use Scriptrunner
Leverage Post Functions in workflows – which would only run when someone changed status.
Write a plugin to do whatever you needed it to do.

Not fun options. Automation for JIRA changed the game by allowing you to define robust automation actions that can be triggered by a variety of activities within JIRA. All without any coding required. That is why I put it in “S” Tier. Atlassian agrees – they bought Code Barrel!

Power Admin

Author: Botron Software

Marketplace Link: Here

Here is another plugin that changed how I administer a system. As I’ve already reviewed the App in full, I won’t go too deep into detail here. But the amount of time it now saves me in searching for and analyzing the current configuration in innumerable. That is why this has also earned its place in the “S” Tier.

“A” Tier

Configuration Manager

Author: Botron Software

Marketplace Link: Here

Here is Botron’s second entry into the list. This tool lets you migrate settings from one JIRA instance to another. With some careful testing, you can also use it to migrate JIRA data as well. However, migrations are not a task for the faint-of-heart, which stops this from being “S” tier.

Jira Misc Workflow Extensions (JMWE)

Author: Innovalog

Marketplace Link: Here

JMWE is one of two utilities that give you a ton of options to play with within a workflow. Honestly, for most of my Atlassian career, this was my go-to tool for Automation within a workflow. While handy to have, it always seems that I’ll run into that one use case where it can’t help me at the worse time. However, it is an excellent tool to have in the tool-belt of any JIRA Admin.

JSU Automation Suite for Jira Workflows

Author: beecom Products

Marketplace Link: Here

JSU is the other workflow toolbox that you can work with to achieve some Automation. Much of its functionality overlap in one way or another with JWME, but there are a few things each does that the other doesn’t, so it’s often worth having both. However, just like JWME, this only really helps within a workflow, meaning that anything else, you will need another way to Automate.

SAML Single Sign On (SSO) Jira SAML SSO

Author: re:solution

Marketplace Listing: Here

Sometimes, an app doesn’t need to do everything. Sometimes, it just needs to do one thing well. That is the case with Single Sign-on from re:solution. This App does what it says on the box – allow JIRA to connect and authenticate through a SAML. However, it does it so well that I honestly prefer it to even Data Center’s built-in functionality. However, while it’s good at it, it just lacks the “wow” factor to put it clearly into the “S” tier. It was a close call, but just not enough to get there.

ScriptRunner for Jira

Author: Adaptavist

Marketplace Listing: Here

In complete contrast to the previous App, I have heard of this plugin referred to as the “Everything” plugin. That is because it is flexible enough to do anything you can think of – if you know the Groovy to get it done. I have used this to setup fields that aggregate data from several other fields, clone projects from a template, migrate data from one field to another for consolidation, and set up a multi-tier cascade field. To be honest, it was another JIRA admin on my team that did most of those considering I don’t know Groovy, which is why ScriptRunner earns an “A” Rank. It can do a lot, but there is a barrier to entry.

“B” Tier

Insight – Asset Management

Author: Mindville

Marketplace Listing: Here

Sometimes you find yourself trying to track issues against an inventory of items. You can manually link them to an outside resource – but that can be clunky and inefficient. That’s where Insight comes in. It allows you to track assets within JIRA, and then link tickets and issues to those assets. While I consider this useful at times (Fun fact: I wrote such an asset tracker for a college project once), this isn’t universally applicable. Which is why I felt this should be in B Tier. If you need it, it’s invaluable. If you don’t, it’s just there.

eazyBI Reports and Charts for Jira

Author: eazyBI

Marketplace Listing: Here

Look, I know that JIRA Dashboards can sometimes fall short of the deep, meaning full Analysis management may want. JIRA is a Project Management tool, not a Business Intelligence tool. So what to do then? EazyBI allows you to take the data already within JIRA, and do a more in-depth analysis to help you more clearly relate how the business is doing to management. So if it’s so useful, why is it in the “B” tier? Well, installation isn’t as straight forward as a standard plugin. The App has excellent documentation; don’t get me wrong. But you will have to do a good bit more work to get this working correctly.

Jira Command Line Interface (CLI)

Author: Bob Swift Atlassian Apps (an Appfire company)

Marketplace Listing: Here

JIRA Command Line Interface or CLI does what it says. It gives you another option to authenticate and command JIRA from, well, a command-line interface. There are times when this is the easiest way to do tasks such as copy one field’s value to another for consolidation, perform specific automated tasks, and integrate some custom tools. However, it does require some set up and some time to learn – hence the “B” tier rank.

ProForma: Forms & Checklist for Jira

Author: ThinkTilt

Marketplace Listing: Here

So, I need to put a disclaimer here. ThinkTilt, the company that makes Proforma, will occasionally post links to the blog on their twitter page. While I am hugely appreciative of the support, it has in no way influenced their inclusion or ranking.

Proforma is a tool that lets you have something I’ve wanted in JIRA for a while – Dynamic forms. That is screens that vary what fields are shown based on what fields you already have selected. This feature that, to me, just makes sense. It’s not an easy request, which is why Atlassian hasn’t done it, but with Proforma, you can. So, if I do want this feature, why is it not ranked higher? It’s because you have to set up the forms in advance – which if you have a lot of permutations, means you can be there a while.

VisualScript Reports and Charts for Jira

Author: SmartDraw Software

Marketplace Listing: Here

Here is another App for which there is already a review posted. As I stated, I love the ability to customize your dashboard gadgets and can see this being a valuable tool down the line. So why is it in the “B” Tier? Well, as with some other entries, this requires some javascript know-how to get running. They have a library of pre-made scripts ready to go to combat this, but the barrier to entry is still there for anything custom.

“C” Tier

Clone Plus for Jira

Author: Bob Swift Atlassian Apps (an Appfire company)

Marketplace Listing: Here

This App is a quality of life plugin. I ran into an issue the other day that I needed to split to show the work accurately – and had I had this App, I would have saved me SO much time. However, it doesn’t add too much functionality to JIRA. Honestly, if the budget were tight, this would be one of the plugins I’d consider letting go first. Is it fair? Maybe not, but compared to the functionality games of some of the others on this list, it was hard to justify a higher ranking.

Project Configurator for Jira

Author: Adaptavist

Marketplace Listing: Here

There was a time this was my go-to tool for doing JIRA Instance Migrations and Consolidations. Like Configuration Manager, it makes the process of moving JIRA settings and issues from one instance to another a lot easier. However, I’ve started to use Configuration Manager recently for one simple reason: It’s faster. To be fair, this isn’t Project Configurator’s fault. Their data import mechanism relies on JIRA’s built-in mechanism – which is also slow. But when you have 60K issues to move over one weekend, time matters.

Timetracker – Time Tracking & Reporting

Author: Everit Kft.

Marketplace Listing: Here

So, JIRA’s great at a lot – but time tracking isn’t one of them. If you want to run a report based on the time estimate fields – notably logged work – well, good luck with that. However, this App does just that – let you run reports on the user’s logged work time to make sure it’s in line with estimates and expectations. This earn’s it’s “C” tier ranking because this is another case where if you need it, it’s invaluable. But if you don’t, it can be something that will look tempting to cut during budget planning. The value-added for the cost can be hard to justify sometimes.

So, now it’s your turn.

The great thing about Tiermaker is you can share the template and let others create their ranks. Disagree with me? Good! Make your own ranked list and post it for me to see using the hashtag #JiraAppTierList. If you have any Apps you’d like added, let me know, and I’ll work to get them added to the template. I can’t wait to see what you do!

JIRA App Tier List Template

In other news

The leader of the Atlanta A.C.E. group reached out to me this past week and asked if I’d like to co-present based on last week’s blog. Of course, I accepted! So I’ll be speaking with Ed Gaile on Monitoring Atlassian Applications on Thursday, June 25th, at 6 PM Eastern. If you are in the Atlanta, GA area, please consider joining the event!

And that’s it for this week!

Remember, if you enjoyed this post, you could sign up below to have new theJIRAguy posts delivered to your inbox! You can also follow me on twitter at @theJIRAguy. I also love to hear from readers, so be sure to comment, like, and share posts to Twitter and LinkedIn. But until next time, my name is Rodney, asking, “Have you updated your JIRA issues today?”

Alerting on JIRA Problems using Nagios

June 3, 2020July 10, 2020 Rodney N.Leave a comment

So I ran into an interesting situation this past Monday. Apparently my Primary DNS had been down for at least a week. I went to go look at my network monitoring tool (LibreNMS) – and THAT was down too – for what I can guess is at least two weeks! Granted I haven’t been doing as much on my Homelab since early March when I went into the hospital, this was still not a good state of affairs.

So I decided to stand up a Nagios instance to monitor and alert when I have critical systems down. After getting it stood up, it didn’t take me long to start thinking about how I could use this with JIRA, which is now the topic we are going to cover today!

A bit of history

As you know, when I started my Atlassian journey, I was in charge of more than just JIRA. Nagios was one of my boxes I inherited as well. So I’m somewhat familiar with the tool already and how to configure it. I’ve had to modify things during that time, but never do a full setup. However, I knew I wanted to do more than monitor if JIRA was listening to web-traffic. So as part of the whole installation, I decided to dive in and see what she can do.

How to select what to Alert on.

Selecting what I want to be alerted for has always been a balancing act for me. You don’t want to have so many emails that they become worthless, but you don’t want to have so few that you won’t be alerted to a real problem.

The goal of alerting is to clue you into problems so you can be proactive. Fix back end problems before they become a user ticket. So I always try to take the approach “What does a user care about?”

They care that the system is up and accessible, so I always monitor the service ports, including my access port. So that’s three.

A user also cares that their integrations work. If your integrations depend on SSL, and your clock drifts too far out of alignment, those integrations can fail – so I want to check the system is in sync with the NTP Server.

A feature that users love is the ability to attach files to issues. This feature will eventually chew up your disk space, so I’ll also want to monitor the disk JIRA’s home directory lives on.

Considering I’m using a proxy, I’ll want to be sure the JVM itself is up, so I’ll need to look at that. I’ll also want to be sure that JIRA is performing at it’s best, and isn’t taking too long to respond, so I’ll want an alert for that as well.

Do you see what I’m doing? I’m looking at what can go wrong with JIRA when I’m not looking and setting up alerts for those. The idea here is I care about what my users care about, so I want the Nagios to tell me what is wrong before my users get a chance to.

So…configurations.

Now comes the fun part. Nagios’ configuration files is a bit much to take in at first. However, I will be isolating the Atlassian specific configurations to make things a bit easier on all of us. First, lets start with some new commands I had to add.

###############################################################################
# atlassian_commands.cfg
#
#
# NOTES: This config file provides you with some commands tailored to monitoring
#        JIRA nodes from Nagios
# AUTHOR: Rodney Nissen <rnissen@thejiraguy.com
#
###############################################################################


define command {
    command_name    check_jira_status
    command_line	$USER1$/check_http -S -H $HOSTADDRESS$ -u /status -s '{"state":"RUNNING"}'
	}
	
define command {
    command_name	check_jira_restapi
	command_line	$USER1$/check_http -S -H $HOSTADDRESS$ -u /rest/api/latest/issue/$ARG3$ -s "$ARG3$" -k 'Authorization: Basic $ARG4$' -w $ARG1$ -c $ARG2$
	}
    
define command {
    command_name    check_jira_disk
    command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -l nagios -C "/usr/lib64/nagios/plugins/check_disk -w $ARG2$ -c $ARG3$ -p $ARG1$"
    }
    
define command {
    command_name    check_jira_load
    command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/usr/lib64/nagios/plugins/check_load -w $ARG1$ -c $ARG2$" -l nagios

The first two commands here are VERY tailored to JIRA. The first one checks that the JVM is running, all with a handy HTTP request. If you go to your JIRA instance and go to the /status directory, the JVM will respond with a simple JSON telling you the state of the node. You use this feature in JIRA Data Center, so your load balancer can determine which nodes are up and ready for traffic. Buuut…it’s on JIRA Server too, and we can use it for active monitoring. So I did. If JIRA returns anything other than {“state”:”RUNNING”}, the check will fail and you will get an alert.

The second is a check on the rest API. This one will exercise your JIRA instance to make sure it’s working without too much load time for users. The idea here will search for a known issue key, and see if it returns valid information within a reasonable time. $ARG1$ is how long JIRA has before Nagios will issue a warning that it’s too slow (in seconds), and $ARG2$ is how long JIRA has before Nagios considers it a critical problem. $ARG3$ is your known good Issuekey. $ARG4$ is a set of credentials for JIRA encoded in Base64. If you are not comfortable just leaving your actual credentials encoded as such, I’d suggest you check out the API Token Authentication App for JIRA. Using the App will allow you to use a token for authentication and not expose your password.

The third commands here are for checking JIRA’s home directory ($ARG1). $ARG2$ and $ARG3$ are percentages for the warning and critical thresholds, respectively.

The fourth is for checking the system load. This one is relatively straight forward. $ARG1$ is the system load that will trigger a warning, and $ARG2$ is the system load that shows you have a problem.

Now for the JIRA host configuration:

###############################################################################
# jira.CFG - SAMPLE OBJECT CONFIG FILE FOR MONITORING THIS MACHINE
#
#
# NOTE: This config file is intended to serve as an *extremely* simple
#       example of how you can create configuration entries to monitor
#       the local (Linux) machine.
#
###############################################################################



###############################################################################
#
# HOST DEFINITION
#
###############################################################################

# Define a host for the local machine

define host {

    use                     linux-server            ; Name of host template to use
                                                    ; This host definition will inherit all variables that are defined
                                                    ; in (or inherited by) the linux-server host template definition.
    host_name               jira
    alias                   JIRA
    address                 192.168.XXX.XXX
}


###############################################################################
#
# SERVICE DEFINITIONS
#
###############################################################################

# Define a service to "ping" the local machine

define service {

    use                     generic-service           ; Name of service template to use
    host_name               jira
    service_description     PING
    check_command           check_ping!100.0,20%!500.0,60%
}


# Define a service to check SSH on the local machine.
# Disable notifications for this service by default, as not all users may have SSH enabled.

define service {

    use                     generic-service           ; Name of service template to use
    host_name               jira
    service_description     SSH
    check_command           check_ssh
}



# Define a service to check HTTP on the local machine.
# Disable notifications for this service by default, as not all users may have HTTP enabled.

define service {

    use                     generic-service           ; Name of service template to use
    host_name               jira
    service_description     HTTP
    check_command           check_http
}

define service {

    use                     generic-service
    host_name               jira.folden-nissen.com
    service_description     HTTPS
    check_command           check_https
}


define service {
    use                     generic-service
    host_name               jira
    service_description     NTP
    check_command           check_ntp!0.5!1
}

define service {
	use				generic-service
	host_name			jira
	service_description		JIRA Status
	check_command			check_jira_status
	}
	
define service {
	use				generic-service
	host_name			jira
	service_description		JIRA API Time
	check_command			check_jira_restapi!2!3!HL-1!<Base64 Credentials>
	}
    
define service {
	use				generic-service
	host_name			jira
	service_description		JIRA System Load
	check_command			check_jira_load!5.0,4.0,3.0!10.0,6.0,4.0
	}
    
define service {
	use				generic-service
	host_name			jira
	service_description		JIRA Home Directory Free Space
	check_command			check_jira_disk!<JIRA Home>!75%!85%
	}

So, first, we define the host. This section is information specific to JIRA. Then we start setting services for JIRA. Within Nagios, a Service is a particular check you want to run.

The next four options are pretty standard. These are checking Ping, the two service ports (HTTP and HTTPS), and the SSH port. The SSH Port and HTTP/S port checks will also check that those services are responding as expected.

The next check is for NTP. I have this setup to warn me if the clock is a half-second off and give me a critical error if the clock is off by one second. These settings might be too strict, but it has yet to alert, so I think I have dialed it in well enough.

The next is the JIRA Status check. This service will check /status, as we mentioned earlier. It’s either the string we are expecting, or it’s not, so no arguments needed.

After that is my JIRA API Check, which I set up to check the HL-1 issue. If the API Call takes longer to 2 seconds, issue a warning, and if it takes longer than 3 seconds, Nagios issues a critical problem. This alert won’t tell me exactly what’s wrong, but it will tell me if there is a problem anywhere in the system, so I think it’s a good check.

The last two services are systems check – checking the System Load and JIRA home directory disk, respectively. The Load I haven’t had a chance to dial in yet, so I might have it set too high, but I’m going to leave it for now. As for the Disk check, I like to have plenty of warning I am approaching a full disk to give me time to resolve it, so these numbers are good.

The last step is to add these to the nagios.cfg file so that they get loaded into memory. However, this is as easy as adding the following lines into the cfg file.

# Definitions for JIRA Monitoring
# Commands:
cfg_file=/usr/local/nagios/etc/objects/atlassian_command.cfg

# JIRA Nodes:
cfg_file=/usr/local/nagios/etc/objects/jira.cfg

And that’s it! Restart Nagios and you will see your new host and service checks come up!

Nagios in action.

So I’ve had this configuration in place for about a day now, and it appears to be working. The API Time check did go off once, but I did restart the JIRA Server to adjust some specs on the VM, so I expected the delay. So I hope this helps you as you are setting up alerts for your JIRA system!

And that’s it for this week!

We did get a bit of bad news about Summit 2021 last week. Out of an abundance of caution, Atlassian decided to go ahead and make all in-person events of 2020 and Summit 2021 virtual events. However, they have almost a year to prepare for a virtual Summit – as opposed to the 28 days they had this year. So I am excited to see what ideas Atlassian has to make this a fantastic event!

Don’t forget our poll! I’m going to let it run another week!

Don’t forget you can check me out on Twitter! I’ll be posting news, events, and thoughts there, and would love to interact with everyone! If you found this article helpful or insightful, please leave a comment and let me know! A comment and like on this post in LinkedIn will also help spread the word and help others discover the blog! Also, If you like this content and would like it delivered directly to your inbox, sign up below!

But until next time, my name is Rodney, asking “Have you updated your JIRA Issues today?”

Dragon Slayer Part 2: The Revamp

May 27, 2020July 10, 2020 Rodney N.2 Comments

Well, I’ve finished the revamp! It took me a little longer than expected, but here we are.

Of course, you guys enjoyed last week’s article on Automation for JIRA. While I would not like it to be the sole focus of the blog, if you guys bring me good ideas for potential Automations, I would love to do more of those kinds of pieces. But that’s not why we are here today.

So in total, I reworked all nine pages, each about as long as a typical blog post. Today I’d like to go into some thoughts, tricks, and pitfalls to be aware of if you try to do it from my instructions.

Time is not on your side.

So, to be clear, the last five modules all depend on a Mercurial Repo hosted on Bitbucket Cloud. It’s something that works well in this situation – except for the following complication.

Atlassian has announced they are ending support in Bitbucket Cloud for Mercurial, with all existing Mercurial Repos disappearing on July 1st, which leaves the Dragon Slayer Challenge in a bit of a pickle.

As of right now, I intend to monitor it to see if they update their instructions with a git repository. If that does not happen, I’ll be taking down my instructions on July 1st as well. It only seems right, honestly. I would not like to be answering comments for the next few years that everything past Stage 5 isn’t working.

So if you are looking to try this yourself – do it now!

Fish eye gadgets are still…off.

So, I spent half a day debugging this – only to get nowhere. There are a few answers out there for the problem, but they are six years old. To further complicate things, my testing proved that their problem back then was not my problem today.

What problem is that? Simple, I could not get a Fisheye Gadget to return a valid Repository no matter what I tried. Every time I’d get the same, “The specified FishEye repository is not configured” – which was malarkey. The Repositories would work correctly within the JIRA Development Panel – just not the gadgets. Upping the logging on the FishEye plugin revealed nothing of usefulness in the logs either.

At a certain point, I just had to decide I wasn’t the one to fix this issue. However, if you do have a fix, please PLEASE let me know!

A few last notes

I tried to go through and click every link, touch every instruction, and redo every screenshot. But there may be parts I missed. If you notice something that isn’t working, please let me know so I can update it!

There are points where things weren’t working as described, and I had to find out why and fix it. Every time this did happen, though, I did go back to the appropriate place and update the instructions. I feel this is an improvement on the old instructions from Atlassian and is something I am happy to put out.

That being said, this is Atlassian’s work originally. If they ask that I take it down, I will do so without warning to you guys. I don’t want to bite the hand that feeds me. I honestly don’t think it will come to that, but I figured I’d give you fair warning.

So, Get on with it!

You can find the start of the journey here. If you’ve never messed with the system side of running the Atlassian Stack yourself, it’s a great place to get started.

Dragon Slayer

I’ve spent a good bit of time on this update, so if you appreciate it, please give it a like and cI’ve spent a good bit of time on this update, so if you appreciate it, please give it a like or comment on LinkedIn or a retweet on Twitter. That’s all it takes to help others discover this blog! You can also subscribe to the blog using the form below to get new posts directly to your inbox. Don’t forget to follow me on Twitter at @theJIRAguy.

Also, a discussion at work got me curious. How do you spell it: Subtask or Sub-task? Answer below!

But until next time, my name is Rodney, asking “Have you updated your JIRA issues today?”

Automation for JIRA

May 20, 2020July 10, 2020 Rodney N.Leave a comment

So, I can already hear you, readers. You’re saying, “Aren’t we supposed to have a part 2 to the Dragonslayer post where you modernize the instructions?” And you are correct. However, that turns out to be a more significant task than I first imagined.

However, I want you to have something to read this week. That was when I had a request from a client this week. Upon reviewing the solution to the request, I felt it would be perfect for posting about this week.

Automation for JIRA

One question users always ask me is how they can automate actions in JIRA. For example, when they move a story into the sprint, how can they automatically have the subtasks moved too. And for the longest time, I didn’t have a useful answer.

Sure, you can make it work in Scriptrunner, but the amount of work it would take would make it not worth it. Then I discovered Automation for JIRA. This one allows me to tailor automations to specific projects, and so so using no programming.

So for this post, I thought I’d go into the request I was given and how I approached solving it using Automation for JIRA. Let us begin.

The Request

So, my first recommendation is to understand the request entirely. Figure out not only what the users are asking you to do but also why they are asking it in the first place.

In this case, the client asked me if there was a way to automatically create sub-tasks on an issue based on what components are on the parent issue. That’s great, but that doesn’t solve the “why.” However, I was fortunate that the client already explained their thinking here.

It turns out that the client has the components in their project broken down by functional teams, and for each task, they want to add Components to the issue based on who has an active role in it. They then want to create a sub-task for each component so that the individual teams involved can track their work.

The reason for the requests tells me a good bit about the request that the initial ask did not. For example, Components may not only be added at issue creation but at any time during the Issue’s lifecycle. This fact comes into play soon. It also tells me that I need to be able to support any combination of components. This requirement can make things tricky, but I don’t think impossible.

Getting started

The Trigger

The first thing I think about when I start building an automation is, well, the starting point. What kicks it off. Let me explain. For every automation rule you have, you need some event to kick it off. Some marble that is falling to set off your Rube-Goldberg machine.

In Automation for JIRA, this is called the Trigger. There are a number of these available within the tool.

That is quite the list, no? While it may be something to go through, I think it’s a natural choice here. Remember when I mentioned that we discerned from the request that we would need this to happen at any point during the Issue’s active life cycle? That means we can rule out anything that doesn’t have to do with the Issue. We can also rule out anything that takes place during specific events of the lifecycle, such as a transition or creation.

Furthermore, we have a trigger that can focus specifically on when a field is changed.

So when we select this option, we are presented with several settings. Because we are focusing on the Components, we choose that for the field setting, and leave the “For” setting to it’d default “All issue operations.” Once done, we click “Save.”

Conditions

So, now we need to think about when we don’t want this rule to run. We can specify when an automation rule runs by using “Conditions.” Here is a view of what our rule looks like after saving the Trigger.

We know we only want this rule to run when the parent issue is active. So lets put a condition on here to check that the Resolution field is empty.

Having this immediately after the Trigger keeps it from executing when this condition isn’t true (in our example, when the Issue is resolved). There are many conditions available, and we can use a few of them here in a moment.

The “Component Block” – More Conditions and Actions

Now comes the tricky part. We need to be able to split off actions based on the components. We also need to check – per Component – that it’s appropriate sub-task doesn’t already exist. This requirement stumped me for a second until I settled on the “If/Else” block. Using this condition creates a situation where you can have actions run if the condition is true, but if it’s false, it won’t stop the entire chain from running.

Here we have the If block with two conditions. The first checks for a specific Component – in this case, “Ducks.” The second checks all sub-tasks to make sure we don’t already have the one we want. If any have the summary “Test Ducks,” this Trigger fails, and any actions we have on this branch don’t run.

What do I mean by branch? I mean this If block, once saved, creates a branch in our rule flow.

Here is where we will add our actions. In this case, we will want to create an issue within the current project with issue type “Sub-Task”. This will allow us to specify the responsible user, description, and most importantly summary. For this to work properly, you need to make sure you summary you are creating matches the check you have in the If Statement.

Click Save, and that’s the block done for this Component. Rinse and Repeat for each Component you desire to automate, and you should be good to go.

Branches

So, we didn’t end up using them for this request, but I still wanted to touch on Branches. We used the If/Else Block for some rudimentary branches, but what happens when you want to run an Automation Rule against all the Issue’s Sub-Tasks?

In this situation, you want to use a Branch rule. This rule allows you to execute a set of actions on issues based on their relation to the Issue that triggered the rule.

Something handy to keep in mind, but as I’ve stated, not always something you need.

And that’s it!

I am sorry for not having the second Dragonslayer post – but I do hope to have that available for next week. But this request struck me as an interesting problem and a great example of how to develop and use an Automation Rule.

If you like the content you find here, don’t hesitate to sign up below to receive emails when I post new content. And you can also check me out on twitter at this link. But until next time, my name is Rodney, asking “Have you updated your JIRA Issue today?”

Dragon Slayer 2020 – Pt. 1

May 13, 2020July 10, 2020 Rodney N.Leave a comment

What’s up, everyone? It’s been a busy week for me. However, in the “excellent things” department, I passed my exam!

That means I’m exactly one Cert away from Atlassian Certified Master status. And I think we all know that my next certification exam is the ACP-200.

However, that is going to have to wait. I am not losing to that exam, so study time is needed. No, this week is going to be a bit of a throw-back. I’m going to be attempting the Atlassian Dragon Slayer challenge to see how it holds up. This challenge is to set up a fully integrated development suite using JIRA, Confluence, Fisheye, Crucible, and Bamboo. Considering I already have a test JIRA instance, I’m going to follow the directions linked.

Next week for part 2, I’m going to re-write it with modern JIRA, Confluence, Bamboo, and Bitbucket in mind so that if you want to follow this old quest with modern tools, you can. So, let’s not dally any longer.

Dragons with JIRA Stage 1 – Set Up Environment and JIRA

As my JIRA Instance is already running and relatively up to date, I can skip steps 1-4 and go directly to Step 5.

Anyone else remember when Atlassian version numbers would get that high? Needless to say, I think we’re over the required version.

All told, Step 5 is mostly setting up users and groups for the other system. Step 6 is setting up the project and Dashboard. The only question I ran into here is the project type. The instructions ask for a “Software Development’ Project,” however, this was before JIRA 7, where JIRA Agile became JIRA Software (with three different types of Software Projects). I opted considering the criteria to go with a “Basic software development” project – as I felt that most closely followed the instructions so far. That may come to bite me in a moment, as it’s time to move onto the next Stage.

Dragons Stage 2 – JIRA Add-Ons

Well, that whole JIRA Agile/Software thing ended up not being a problem, as the first step on the next page asks me to set up a new project and board. That is one thing I’ll give Atlassian – this kind of deal is A LOT easier than it used to be. The instructions have you create the project, then the board. You can now do this all in one go in JIRA Software. So, create the Scrum project, create the bugs they specify, create/start a sprint, and I get this.

The next section for this Stage involves setting up Capture for JIRA by ~~Zephyr~~ Smartbear. This App lets you capture screenshots of web pages (among other things). This tool is great for capturing more information on bugs, which is how the challenge has us use it

Dragons Stage 3 – Install Confluence

So, Stage 3 is installing Confluence. And well…

I still needed to do some basic configuration and setup work here. I added JIRA as a directory in Confluence (honestly, it’s easier than the OpenLDAP config I had going), and created the DRA Space and started modifying its home page. And this was where I ran into trouble.

This…this innocuous looking line from my Apache config cost me 2 hours worth of time to fThis innocuous-looking line from my Apache config cost me 2 hours worth of time to figure out. This setting would unset the authentication every time Confluence tried to talk to JIRA, which meant the JIRA Issues/Filters Gadget would not work. The most infuriating part – there was no error in either Confluence’s or JIRA’s log. I only figured it out as I happened upon the right KB Article on it…

However, with that fixed, I finally got everything up and running normally, and was able to finish Stage 3.

Dragons Stage 4 – Install Team Calendars in Confluence

Team Calendars – now this one I know just works. I install it per the usual method (I am certainly burning through the free trials today). Honestly, this one just worked pretty straight forward – follow the instructions here.

Dragons Stage 5 – Install FishEye and Crucible

Stage 5 is installing Fisheye – and honestly, this has not been something I’ve done since early in my Atlassian Administrator career. However, the instructions included seemed a bit dated. So I instead popped over to the Atlassian KB and found this article on Installing Fisheye on Linux and Mac. You have to love it when you find the article you need. Then it was a matter of connecting my internal bitbucket server instance (for thoroughness), as well as the remote Bitbucket repo mentioned in the Stage 5 instructions, and we’re off to the races!

Dragons Stage 6 – Get JIRA and FishEye Talking

So Step one is setting the link between the Repo from Stage 5 and the DRA project in JIRA. It’s relatively simple to set up. It was at this point that I had to figure out why the “Source” tab they mentioned wasn’t showing up. Then I remembered that JIRA had moved this to the Development Panel some time ago.

“It’s fantastic when stuff just works,” is what I’d be saying if not for Step 3. No matter what I did, I could not get the gadget to work. The gadget would keep saying, “The Repo was not configured.” I knew the Repo had been configured properly. Other Fisheye Gadgets worked with the Repo, just not this one. I need to move on with this one.

Dragons Stage 7 – Get JIRA and Crucible Talking

This one was fairly straight forward. I linked a Crucible Project to the DRA JIRA Project and went through the process of creating a review, finding a defect, creating a JIRA issue from it, and resolving it. The only problem I had was when I couldn’t find the “Create Issue” link – but that one was purely an ID-10T error on my part. Another one down!

Dragons Stage 8 – Install Bamboo

I can see the light at the end of the tunnel – but this one is another install challenge. I I can see the light at the end of the tunnel – but this one is another install challenge. I overbuilt the Fisheye server also to host Bamboo as both are temporary in my setup. This one also needed some updating, so I followed the more up-to-date KB Article Installing Bamboo on Linux. Afterward, I set up Bamboo to use JIRA for Authentication and double-checked that the groups were set up.

Now it was time to get all the application links in place. With five applications now, this process is getting a bit long, but not painful.

Now it was time to configure the actual build. This one took me a second as I had to figure out where the tools directory was on the host system ( /usr/share/maven/ if you are wondering), but I got it set up, debugged, and a successful build, which completed the next to the last Stage!

Dragons Stage 9 – Bamboo Gadgets and JIRA Victory

So last stage – looks like it’s more gadgets time. And…there’s a problem. When I go to add So last Stage – looks like it’s more gadgets time. And there’s a problem. When I go to add the gadgets they request, I can see and add them to the Dashboard. But then they don’t load their settings panel at all.

It turns out – it was my browser. Because I’m not bothering to put these behind an SSL proxy, Firefox did not like that. Disable the protection (temporarily), and they work!

Final thoughts

So, here’s the deal. These guides were last updated in 2017, and based on the repo data, written much earlier. May and June may be our last chance to run this for a bit, as Atlassian is removing Mercurial Ropes from Bitbucket Cloud.

However, this was a fun little run-through of all the various bits of the Atlassian Development Stack. I got to touch several products that I haven’t looked at in years and got some practical experience in installing them from scratch. It’d be interesting to do a speed run of these to see how long it would take.

So now comes the fun part – updating this with new instructions and getting it all working on the modern versions of the tools! If you want to check that out, be sure to sign up to receive emails from the blog. You can also follow me on Twitter at @theJIRAguy. But until next time, my name is Rodney, asking, “Have you updated your JIRA Issues today?”

What is a Consultant?

May 6, 2020July 10, 2020 Rodney N.Leave a comment

Well, here we are, another month down. At let me say, you guys killed it last month!

We got well over 1,000 views last month! That almost doubles the previous month and is easily the biggest month the blog has had to date. Thank you all for commenting, liking, and sharing the blog with your friends and colleagues! You guys are what makes this all possible!

Today’s topic is a bit different. This item was suggested to me by a colleague. In a nutshell, he wanted me to look at the difference between being an Atlassian Admin and an Atlassian Consultant.

As you may now, I was a JIRA Admin before starting my current job. But seeing as I have only been a consultant for six months, I decided to call in some help. So welcome to the blog David Higdon, Olena McMurtrey, and Neil Taylor. They will be lending their thoughts onto the topic and answering some questions I posed to them!

How did you get started with Atlassian Components?

Neil: So, the first job I had out of college – they were running a helpdesk – and this was before JIRA Service Desk was around. But they were like, “Hey, We’re using this new product called JIRA.” And that was when JIRA was on version 4. So I got to adapt that to run a Service Desk for about ten thousand Dialysis Facilities. It was an interesting use case for the product, and I don’t know if they chose the right product for that, but it got me in the door with working on Atlassian.

Olena: Coyote Creek had both Microsoft and Atlassian teams; I started in the Microsoft division, and with time transferred to Atlassian team. I got passionate about Atlassian products, and enjoy helping clients to tune their systems with best practice approach.

David:

So, one of my good friends leaves the company I’m working for and joins a software company. And their Engineering Team at this software company was looking for somebody to help manage their middleware space from a Unix SysAdmin perspective. At the time, I had 27 years of experience as a Systems Administrator – of which I had spent six managing the middleware space, and they felt I would be a great addition to their team.

As this company was coming out of the startup phase, they were looking to get a little more structure in place and a bit more formality in their processes, and for someone to help them standardize and automate things of that nature. And being an Engineering Department, they are big on Atlassian Products. They had two instances of JIRA – one external for Professional Services and their Customers, and then an internal system for their Software Developers. They were using two instances of Fisheye/Crucible. The Professional Services instance looking at SVN and Engineering instance was looking at GIT.

So, my first day on the job, they sat me down, and they said, “Here you go, here are two instances of JIRA and Fisheye, and here are the hostnames.” I had to learn Jira ASAP and prepare to upgrade the system. So, I’ve never heard of Atlassian at that time, so this is how I got introduced to Atlassian – literally diving into the deep end.

Rodney: I was working as a consultant for First Responder Dispatch systems at the time – that being the systems the operator is typing into when you dial the emergency number.

However, that job required a lot of travel, which was not a good situation. Looking around my company, I noticed an open position for a Linux Administrator. Now this company prided itself on being a Microsoft shop – so of course, I was the one dumb enough to raise my hand and say, “Yes, I know Linux!” I applied and interviewed, and was honest about my experience, and got the position of managing some Linux based development systems.

So day one, I go in, and I’m getting the grand tour. We go over my server closet, the perforce server, our backup process, and finally, JIRA and Confluence. I’m given admin rights to the systems and told, “Congratulations. You have a day before you start getting tickets, and by the way, we want to upgrade the systems this quarter.” At that point, nothing left to do but start learning one ticket and google search at a time.

How did you become a consultant?

Neil: So, I put JIRA on my LinkedIn, and a consultant company contacted me and said, “Hey, we want you to come be an Atlassian consultant for us,” because they had a client that was using Atlassian products. I interviewed for the position, and they offered me a job, and I thought, “Well, hey, let’s give this a try and see some other Atlassian environments out there.”

I have to admit that Atlassian wasn’t on my radar when I was in college. I also didn’t see my career going from Atlassian Admin to Atlassian Consultant, but I’m happy with the way it worked out.

David: Over my years, I had quite a few opportunities presented to me before I joined Coyote Creek. I had offers for Backend Sales or Consulting but never took the opportunities. Before I joined Coyote Creek, however, I had two separate Engagements with them and enjoyed the experience and the expertise they provided. It was a combination of being a little older in my career. After twenty years of being on the front line supporting mission-critical applications, I was ready for a new role.

My introduction to I.T was as a Computer Operator working graveyard at Oracle. And about a year into the job, I met some Senior SysAdmins that worked in the Development Datacenter, and they had all the latest cool toys. As I built a relationship with these guys, and they told me more about what they did day today, there was one aspect of their job that stood out. There were never on call. I quickly discovered that being an Engineer for Developers and supporting their systems was the dream scenario. You get all the cool toys, do the same kind of work, but nobody cares if a system is down Saturday at 10 PM.

That job at the software company was my first opportunity for that kind of work – only supporting Engineers and Developers, and there is nothing mission-critical about code deploys because it was all about the next release. So that was my first dip into that situation I always wanted since starting I.T. Consulting is kind of a natural progression there, so when the opportunity came up, I made a move.

Rodney: Honestly, I avoided becoming an Atlassian Consultant for a long while. My previous experience with it left a bad taste in my mouth, and I worried about a repeat of that experience. However, when I was in the job market last year, it got the point where I had multiple offers. I was clear during the interview with Coyote Creek that I didn’t want to return to a scenario where I was traveling more than 25% in any given month ever again. They agreed, and all told they had the better offer, so I signed on with them. And it has been a much better experience than with my previous time as a consultant.

What do you feel is the biggest difference between being an Admin and a Consultant?

Neil: I think the most significant difference is that the consultant has the space to look at the bigger picture and to make the recommendations towards best practices. When you’re an admin in the trenches, you get so busy with the day-to-day “Hey, I need this workflow” and “I need this project” that you can lose sight of that. That’s where a consultant can come in and lead you away from some nasty rabbit holes.

David: You do not own the system or application. For where I am at in my career now, I am not looking to support environments 7x24x356, so this works out great. It can be challenging, though, if you want to make updates or correct areas you were not requested. That is still the old Admin in me. However, I still really enjoy Architecting solutions and problem-solving. I spent many years in the service industry, so it’s also the customer service aspect, and being able to provide solutions to people is what drives me today.

Rodney: That when we come in, we are there to solve problems. If these were easy problems to solve, the company wouldn’t have hired us. But, it’s not a “You vs. Us” kind of deal. We are ultimately there to help you, so don’t be afraid to ask questions and figure out what’s going on. After all, when everyone is on the same page, it will lead to a better outcome.

What do you wish more Admins knew about being a Consultant?

Neil: That our role is to make everyone’s lives easier – including yours. We’re not there to try and complicate anything, but instead to make everything easier. And a lot of times that includes making the Admin’s lives easier, because we don’t want the interface to be messy and there to be a bunch of overhead either.

At times I feel admins think, “Oh, they’re bringing in a consultant, they are going to try to to over-complicate this project.” But that’s not the case, we want to make everything easy too.

Olena: I think a lot of Admins don’t know how exciting it can be, how there is this non-stop race to learn new technology. It takes a very hungry approach where you want to learn new things and take on new problems all the time.

David: You do not come right out of school into a consulting role – spend time as an Admin or an Engineer to develop the technical skills to take on such a role. Additionally, develop the soft skills for communicating with your clients.

Rodney: That when we come in, we are there to solve problems. If these were easy problems to solve, the company wouldn’t have hired us. But, it’s never a “You vs. Us” kind of deal. We are ultimately there to help you, so don’t be afraid to ask questions and figure out what’s going on. After all, when everyone is on the same page, it will lead to a better outcome.

Final Thoughts

Neil: Being a consultant is unique because you are jumping from one thing to another. At times, it can be fast-paced and intense, but it keeps you from getting stuck in a rut. You are always learning something new, so you never feel you are getting stale.
Also, no one’s setup is the same, everyone is doing a slightly different thing, so it’s always an adventure.

Olena: To be a good consultant, you have to be a good Admin first, as you have to learn first-hand the pain-points of someone using the products daily. It’s like learning colors before you start the whole painting. It provides a background on how better to support clients to close the gap between the business and technical sides.

David: The best and worst aspect of JIRA is you can do anything 10,000 different ways, and as a consultant, you have to peel that back. It may or may not be the best way. But there have also been times I’ve discovered that the way I did it wasn’t the best, and the way that someone else implemented it was better than mine, so I can learn from that way.

Someone told me this a long time ago, “There is nothing more permanent than temporary!”. After all my years supporting everything from mission-critical environments to lab systems, I found this to be true. Countless times someone told me they would need access for X amount of time, or they rack some computer here for a week or need root for the day or need to run their app on my system until the budget is approved to buy new hardware.

Rodney: I feel that being a Consultant and being an Admin are two sides of the same coin. Each one emphasizes different skill sets, but you both build off of the same necessary base skills. But at the end of the day, it’s still up to all of us to learn and grow.

And that’s it for this week!

So, I’m trying something new with this interview format here – and honestly, I’m nervous about how it will play out. So if you enjoyed this post, please do take the time to like it and leave a comment!

Don’t forget you can also subscribe below to the blog to get it delivered each week directly to your inbox. You can also follow theJIRAguy on Twitter!

But until next week, this is Rodney, asking, “Have you updated your JIRA issues today?”