Seven JIRA Gotchas

So, let me start with the fact it’s good to be back on a normal schedule. I love writing for you guys, but last week reminded me why I only do so once a week. But…worth it. I heard from so many of you about how much you appreciated the recap. Also – this happened.

Yeah – we got noticed!

So between your enthusiasm, likes and comments on LinkedIn and Twitter, Atlassian’s tweet, and word of mouth spreading, we have overtwo-thirds many views in the first week of April than we had in the entire month of March.

Today’s topic was actually recommended by a team-mate and colleague at Coyote Creek, Olena McMurtrey. The thought is, what are the gotchas you need to look out for when doing various tasks. I’ve outlined seven that even after all my years, I’ll still occasionally trip over. Where possible, I’ll explain how to prevent falling into the traps, and how to fix it if you’ve already fell for them.

1. Internal Directory User Required

So, your IT organization is making some changes to Active Directory, and this will require you to adjust some settings. You go into JIRA with your System Administrator account, navigate to User Directories, and find….

There are no options to edit the AD Directory (or LDAP in my case…still). This is because you have just fallen for our first Gotcha. JIRA does not allow you to modify a directory if the account you are logged in with is a part of that directory. This is to prevent a situation where you modify a directory and manage to lock yourself and your entire company out of JIRA.

For this reason it is often considered best practice to maintain at least one system administrator level account within the JIRA Internal Directory – and to use that when making these changes.

So lets say you didn’t do that. Well, it’s an easy enough fix. Go to User management > Users, then click “Create User” in the upper-right hand corner.

From here, create yourself a user within the JIRA internal Directory, then add it to the jira-administrators group to give it permissions. Log into this account and use that to change the settings.

2. Did you update the field context?

So, you have a team request a new field. Looking into JIRA, you see that field already exists on another project in your instance. Sweet! Less work for you, right? You just slap that bad boy onto the requesting team’s screens and call it a day…

That is until you get an email saying that field is still not showing up for them. You have just fallen for our second gotcha. All fields have a Field Context that you can use to limit what projects that field is allowed to be used on.

To test if this was a case, go to the project, then click “Create” (YOU HAVE TO GO TO THE PROJECT FIRST). Once your create screen is up, click “Configure Fields” then “Where is my field?”

From here, type in your field name and click on it from the drop-down, and you’ll get a quick diagnostic on what’s preventing it from showing up.

As you can see, the bottom one is the offending item – which is your field context. However, this screen will even give you the link to where you need to go to adjust it. To fix this, click that link, then on the next page click “Edit Configuration”

From here, make sure your issue types and project context are appropriately set, then click Modify. You will need to reindex after this, but the field should now be accessible!

3. Updating your URL

So, for whatever reason you need to adjust your URL to JIRA. You do all the work on cut-over day. You have updated the base URL, DNS entries, and even setup Apache to redirect from your old URL to your new one. You get done, run one last test load of JIRA when you see….

Yep. That’s our third gotcha. Any time you change JIRA’s URL, you will need to change the proxy settings in conf/server.xml and restart JIRA. Specifically, the setting “proxyName” listed here:

Additionally, if you are changing the directory you access it from (lets stay from /jira to just /), you will need to update this path setting too.

Do that, restart JIRA and that error message should disappear!

4. App Compatibility

So, picture this. You’ve just completed a massive JIRA Upgrade, and everything appears to be running smoothly. However, come the next work day, you get reports that some features appear to be outright missing. Investigating, you look at your apps to find the following messages.

Image courtesy Atlassian.

Congratulations, you just fell for another gotcha. Your apps are not guaranteed to work version to version, so you need to check each time you plan an upgrade. If you are fortunate, the vendor has already released an updated version that works with your new version of JIRA, and you can just update it straight away.

However, sometimes (like in the case of the “Copy Space Plugin” here), there is no updated version available. You have few choices here.

  • First, you can try to request an update. Not every app is still supported though, so you may not get your update.
  • Second, you can try to find another app in the Marketplace that replaces the functionality. Again, this may also be a dead end.
  • Third, just decide that functionality was a nice to have, but not important, and go on with your life. Your users may disagree though – so be warned.

I suppose there is another option here if you know how to program, but I don’t expect all JIRA Admins to become Java Developers to, so this probably won’t be everyone.

5. Role based Permissions

So, you get a ticket in saying a user can’t work inside a project. No problem, you add them to the Developers role and call it done. Then the user reopens the ticket saying that they still can’t do everything they need to do.

Congratulations, you’ve just fallen for a classic gotcha. Depending on the permission scheme, the Project Roles may map out differently than in an unmodified JIRA. That’s why it’s always important to know what kind of permissions your users need and how they map to the project roles.

Seriously, I’ve used this exact scenario in interviews for JIRA Admins before. You’d be surprised how many fall for it.

6. Did you set a resolution?

So, you get another ticket from one of your Service Desk teams. No matter what they do, they can’t get a ticket to clear out of their queue. You look, and all the tickets appear closed, but there they are, still in the queue.

You’ll find this in teams that have customized their workflow. They forgot to do one of two things: Either auto-set a resolution or put a screen up to allow the user to select a resolution. JIRA Does not consider any issue truly done until that field is set. And that’s for both Software and Service Desk. But you will see this more from Service Desk teams, as it impacts them to a greater degree.

The main takeaway here is to always double check you are giving a user a way to set the resolution in every workflow you make for them.

7. Auto-assignment Roulette

So our last gotcha may not be your fault, but your users. Lets imagine this scenario:

You get an email from a project lead. They are actively using components in their project, with the components having their default assignee be their component lead.

However, they like to add multiple components per story, and no matter what they do they can’t seem to make the components auto-assign in a consistent way.

As you may have guessed, they have just fallen for the for the last gotcha. When using multiple components on a story, JIRA Will use the default assignment of the first component added to the list. So, if your teams are adding them in a different order every time, they will get a seemingly random default assignee every time. This one is easy enough to fix – just instruct your users of this fact and tell them to get a consistent result, order matters.

And those are some Gotchas to watch out for!

Is one of these surprise you? Do you have a gotcha that I didn’t cover? Leave it in a comment!

This topic was recommended by a colleague, but I’m always looking for reader requests for posts. If you have a topic you’d like me to cover, let me know!

Job Seeker Profile

So, as you know, I really started posting to this blog regularly when I myself was in the job market. So every now and again I like to feature those JIRA Admins who find themselves in a similar situation. And I have another one for you to look at.

His name is Akuthota Venkatesh, and he is based out of Hyderabad, Telangana, India. He has been a JIRA Admin in one form or another since June 2011. However, he has recently lost his job due to the world-wide slowdown brought on by the Corona Virus.

Some of the projects he’s worked on include integrating JIRA to Rally and Salesforce, migrating data to and from JIRA, as well as the normal spread of Application upgrades and dealing with stakeholders.

If you are looking for a JIRA Admin and think you might be able to help him, please download his CV and reach out to him!

And in other news

So, I was caught a bit off guard last week. As part of Atlassian posting about the blog, they asked if I had a twitter handle they could @mention. Well, I do, but it was mostly used for sweepstakes entries – not the impression I wanted to make. So since then, I have fixed that. You can find The JIRA Guy on Twitter here: https://twitter.com/theJIRAguy

I intend to post new articles and posts to twitter about our Atlassian powered lives that I find interesting, as well as new posts from the blog! So be sure to give it a follow. You can also subscribe directly to the blog to get new posts directly to your inbox! To do so, just use the form at the bottom of the post.

So, I’ve got some interesting posts planned over the next few weeks – even some that are not JIRA related! *gasp* So I hope you will check back in to see what we’ve got. But until then, my name is Rodney, asking “Have you updated your JIRA issues today?”

A JIRA Guy’s New Years Resolutions

HAPPY NEW YEARS! I hope you had a good 2019 and look forward to a great 2020!

As you know, 2019 was at times….rocky, but all in all it wasn’t terrible. This blog has been one of the bright spots, actually! Hearing from readers out there about how much they are getting from the blog really just makes my day every time!

Where I live, it is a tradition that we resolve to improve at least one aspect about ourselves over the new year. So, that got me thinking, as JIRA Admins, what can we resolve to improve about how we work and how we run our instances. So without further adieu, here we go!

I resolve to not make any config changes without notifying all users first.

This one is easier said than done. But this one will save you so much headache in avoiding unexpected impacts from a change.

The challenge here is there are a lot of changes that you think will have no impact on user experience, and it’s tempting to just rush in and change it. Especially when explaining what you are changing and why feels like writing a light novel. I know, I’ve been guilty here too!

But giving yourself a chance to pause to explain what you are doing and why you are doing it will give both you and your users some perspective. If you are having trouble stating why you are making a change in a way that normal users can understand, do you really understand the change you are about to make? And if that’s the case, why are you making a change you don’t fully understand?

Now another thing here is this requires some lead time. If you send out a rushed email than immediately make a change, you haven’t really notified anyone. It’s the giving it time for users to digest the information and send in the feedback that will show the true power of this resolution.

I resolve to clean up Custom Fields from JIRA.

I see this one all too often. JIRA went through a “wild west” period where either a) all user requests for new fields were automatically stamped “Approved”, or b) everyone had admin rights and just added fields without a care in the world. It’s nothing to be ashamed off, but it is something you should resolve to fix, as an over-abundance of custom fields can cause system performance problems.

Now I’m not going to lie, this is a political quagmire if ever there were one. Users LOVE their custom fields, especially Project Managers. So if it were me, I’d start with the low hanging fruit. In this case, that would be duplicate fields. This one is easy for users to see why it can be a problem. Try doing a JQL search on a field that shares it’s name with another. Which field is which? Which has the data you need? Who knows!?

This does lead to the problem of what to do with the information contained in whichever copy you are getting rid of. Not going to lie, that is not an easy question to answer in Vanilla JIRA, and rightfully deserves a post all it’s own. However, the ever helpful folks at Atlassian Community has a few pointers to get you started.

If you manage to clean up those fields, then comes the next easiest category: Those that are “close” to each other in purpose or meaning. For example, lets say you have the following list of fields:

  • Dev Customer
  • Customer
  • Customer (Accounting)
  • UX Customer
  • Customer Number
  • Customer ID

You now have six fields, which all contain essentially the same kind of information. In an ideal case, any custom field you create should be “generic” – that is to say it should be general enough you can drop it in any project where it’s needed and it makes sense. In this case, I’d work with five of these groups and migrate them all to use the “Customer” field. It’s generic enough that the meaning can be used for all of these applications, and gets rid of five fields in one go.

I resolve to gain and/or regain control of my JIRA instance.

So this one isn’t as universally applicable, but for those of you dealing with it, it can be a hassle. You do the work, get things cleaned up in JIRA and the system working smoothly, just to have some guy – who lets be honest should NOT have JIRA Admin rights – come in, create 20 new projects with 40 new fields.

It’s a story that does happen. That is why you should strive to regain control over your instance, and be the gate-keeper for any such changes. Do you really need 20 projects, or because they are all short lived, could you do with one and utilize Versions/Releases to organize that work?

Now, I’m not going to say this will be easy. Anybody with JIRA Admin rights that aren’t you might have some clout – or at least the ability to complain very loudly to the right people. You will need to defend your decision to take away their rights by showing how the changes they are making are not following best practices, and are actually having a detrimental affect on the instance. But remember, YOU are the JIRA Admin. The health of the instance is ultimately your job, so state that clearly. And remind them that you are open to requests, but you will guide the discussion to something that is better for both the users and the platform.

I resolve to make myself as much of a priority as my systems.

I get it. Your teams and users depend on you to keep the system running and updated. You know what makes it easier to depend on you? Not burning out.

I’ll see it on reddit from time to time where a Sysadmin has passed away from a heart attack, or otherwise burned out and is switching careers. They are always the type who hardly ever took vacation, never took personal days, and felt like the weight of the company is on their shoulders. I’m telling you now – don’t be that guy. I mean I play around with these systems for fun in my spare time, and I still have to unplug every once and a while!

So if this sounds like you, just relax. And if you are at a company that would fire you for taking a few days off every now and again, you’re at the wrong company! Every company should be concerned about burn out, and if they aren’t that isn’t a healthy environment, and you should start looking now for a better year ahead.

Again, Happy New Years!

So, what are your JIRA Admin Resolutions? Are you doing one of the ones I listed here, or are you doing something different! Please let me know. Next week I’ll be reviewing a app (or plugin for us curmudgeons) that literally blew my mind when I saw what it could do. But until then, I hope you have a great start to 2020! I’m Rodney, asking, “Have you updated your JIRA Issues today tomorrow?” Happy New Years Everyone!