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.
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.
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?”
The Jira Guy 