Say what you will about Jira1, but I’ve almost always enjoyed using it. Still, when Jira breaks, it breaks in a way that can be difficult to debug: Was this error thrown because of read/write permissions, workflow compliance, or something else? The errors Jira throws can be quite obtuse. Take this one, for example, when a team member was trying to clone an issue:
The issue was replicable on my end, and so we were off to the debugging races. First, some facts about the issue I was cloning:
- It was a Bug issue type2
- Bugs have specific workflows
- Bugs had newly required fields within those workflows. (I made this change a few days prior.)
In my heart, I knew this had something to do with required fields: Cloning wasn’t broken before I made that change, and now it was. But I was somewhat distracted by the error message: “Check your connection”. Connection to what? An API? The internet? Was I not connected to another project?
A quick Duck Duck Go search showed that others have had the same problem:
Most of those links were specific to cloning Sub-Tasks, which are sometimes treated differently than other issue types in Jira, but they mostly behave the same. In these cases, the fix was adjusting permissions and the default assignee when creating new issues.
Quick side bar for context: When a Jira issue is created, it doesn’t need to be assigned to anyone (Agile purists, rejoice!), but if you have a default assignee, that assignee must have permissions to create tickets in the first place. Jira doesn’t call that out when you designate the assignee, and so sometimes things break. Fun!
But here’s the rub: I – the team’s Scrum Master – was the default assignee, and from a permissions perspective, I had all the access you could have. Still, the error was thrown. Boo!
Next, I tried a cloning a different Bug, picking one at random from the active Sprint. I went through the steps and…
What!
OK, so it wasn’t permissions, nor was it issue types or workflows. Again I suspected the required fields. And so I opened up both issues in their detailed view, side by side. I went field by field, comparing whether or not a given field was filled out (content here wouldn’t matter.) Eventually I came across the culprit: an empty Epic Link field in the original ticket. Stubbing in a random Epic, I was then able to clone the issue without any trouble. Nice – problem solved.
But why was the issue able to exist in that stage of the workflow without the required field? The field, after all, is required. Turns out when you change the workflow and field requirements, it isn’t retroactive, at least not in a destructive sense: The tickets breaking compliance (now the purists are pissed) are allowed to remain in their current state, but any future moves through the workflow are prevented until the required fields are provided. This makes sense, but the messaging from Jira about what’s required is poor.
And so, two take-aways:
- Jira doesn’t always handle errors very well. There were no “connection” problems, but that language threw me for a loop and led me on a bit of a goose chase. If you see a vague error, definitely check the forums, but don’t discount what you suspect to be true.
- Required fields are tricky, especially when required mid-workflow. For us Scrum Masters, the fields likely keep our reporting nice and clean. For team members, however, it could break their individual workflow. Tread carefully, and be prepared to roll anything back if it breaks.
1 Some in the agile community would argue Jira prevents teams from being agile, or encourages bad habits like using Story Points instead of more meaningful metrics. I disagree: If the team isn’t agile, Jira won’t help them be more agile, but if they are, it won’t hurt.
2 Every ticket in Jira is technically an “issue” – the issue type (e.g.: Story, Bug, Epic) defines where it sits in the hierarchy. This naming convention has always seemed like a poor choice and almost always leads to jokes like “Everything about Jira is an issue.” (Agile humor is, at best, poor.)
Goscin.ski 