Good Morning, Jira Guys and Gals, and welcome to 2023! I have some exciting ideas coming into the new year, and I can’t wait to share them with you.

And that starts right now. I was using another application (Home Assistant, to be exact) when I got a notification.  

This notification is common and is reasonably easy to fix. I push the button, and the system upgrades and then restarts itself. Literally, one button push, and I have access to new features. And I don’t have to be on my computer – I can initiate this process from my mobile App. After doing this the other day, I couldn’t help but think, “I wish Jira Data Center was this easy to upgrade.”

So, having one feature I’d like to see in Jira, I asked the community what they’d like to see in Jira – and they replied. As I write this, the post has nearly 70 comments on LinkedIn, with in-depth discussions on several ideas. Let’s review some of the suggestions the community would like to see added and give some thoughts on this. I will look at each feature, how I think it should work, any downsides I can see, and what (if anything) Atlassian has said about this being added.

Push-Button Upgrades

This one is pretty simple. On Data Center instances, all you would need to do is push one button, and it would put your Instance into “upgrade mode,” upgrade the first node, restart it, then repeat for all other nodes in the system, then leave upgrade mode.

So my first note on this feature is that, yes, this is similar to the Release Track feature in Jira Cloud. It took an Atlassian all of a day to point this out. In fact, I’d argue that Jira Cloud Upgrades are even easier than what I’m asking for – as if you so deem, they just happen automatically. But my point is that no such thing exists on Jira Data Center. If any Upgrade Automation exists for a Jira instance, it’s because someone has done the work to write and maintain that automation using a platform like Puppet, Chef, or Ansible. 

Now – as easy as this would be on the Admins, don’t let me misrepresent this ask. The amount of Developer work and time required to pull this off now would be Herculean. This feature is easy to do when you build it into the design from the ground up, but trying to retrofit it into an existing system is a coding nightmare.

Also consider this: Jira must have write access to its install directory to accomplish this feat. That, ladies and gentlemen, is a security headache waiting to be had. Why? Well, it would be only a matter of time before hackers figured out some way to abuse that write access to initiate a remote-code execution attack. Let me repeat – I don’t think it’s a matter of “if they could.” If the Jira user has write access to its install directory – as Jira is architected now – it’s only a matter of time before someone is clever enough to abuse that access. 

So, how does Home Assistant get away with this? Well, the key is “As architected.” As I understand it, Home Assistant is two systems: a “Supervisor” that runs docker containers and the actual system which runs in Docker. So, when I upgrade, the Supervisor is just preparing my data, then killing Home Assistant’s current docker container and starting up a new one with the new version. This method means the thing serving data – the Docker container – doesn’t require write access to itself to upgrade – it just sends the command up to the Supervisor.  

Now, this system is still vulnerable to its own kind of abuse, but it’s still one of the best ways to allow push-button upgradeability without glaring security holes. And this is the kind of system Jira DC would need to adopt to allow the same, I think. Impossible – no. But I don’t think Atlassian is about to sink that kind of money into Data Center. But hey – they could always prove me wrong.  

Bulk User Management

This one was another popular ask when I put up my question. Imagine this – You’re quickly running out of licenses on Jira. There is a group that you know for a fact is no longer using Jira, and disabling their accounts can potentially give you enough breathing room to upgrade your license. So you go to the User Management screen, select that group from the dropdown, and filter for users in that group…and Grind. Seriously, the only thing you can do is go through the users, one by one, and disable their accounts. If you are lucky, you can have multiple people attacking the problem, but if there are many people on that list, you will be busy for a while. 

Seriously, it’s 2023. This is what people mean when they say the UI/UX needs an update. Yes, it does need to be prettified, but it also needs A LOT of these quality-of-life improvements. Give us a “Select All” checkbox, and let us run operations across an entire group, directory – whatever. 

In fact, Atlassian does know about this. If you go to ID-126 on their Jira Feature Request tracker, you will see this feature has been gathering interest since 2014. Let me put that into perspective – a few months after the Server Product is sunset, this request will turn ten years old. So we should all go over to this suggestion and give it a surge of votes…what do you think?

Change Field Types Natively

This. This right here is a headache I know personally. You have a user request a field. You warn them, “Be sure you’re confident in your selection – we cannot easily change it later.” They go off, use it for a bit – and come back to you. Despite your warnings and recommendations to use the more common field types, they still come back and say they want a change. Maybe they aren’t happy that the number field auto-injects the relevant commas, or they need a multi-group selector rather than a single-group selector.  

Either way, they want a change, and you have to figure out how to move data from the old field to the new one – because you cannot change Field types natively in Jira. My first run-in with this problem was the number field. They were using it to track corresponding ticket numbers in an external system, but the auto-injected commas were screwing up the whole process. We eventually used ScriptRunner to copy over the data, but it needed some learning to work out.

Unfortunately, I do understand why Atlassian doesn’t do this. My first instinct is to write a converter that can convert any given field type to every other. Unfortunately, this quickly becomes an exponential problem, as each field type you add down the line requires that many more conversion protocols. 

But looking at it a second longer – the problem isn’t that dramatic. Let’s take my previous example – the Number field. How many field types is it reasonable to convert such a field to? You can convert it to text, which gives you the options of Label, Text Field (Single-line), Text Field (Multi-Line), and MAYBE the URL Field – if and only if you were tracking IP addresses in some weird format. There is no need to convert it to a Group Selector or User Selector. Any options like the Checkbox, Dropdown, or Radio Boxes are also not likely to be targets and likely would only be converted between the single-select and multi-select versions of each field type. So no, you can limit the scope of this ask pretty dramatically with a bit of coordination. 

However, looking at the Atlassian Suggestion Tracker again, I see a pair of issues to address this – one for the On-Premise solution (JRASERVER-19312) and one for Cloud (JRACLOUD-68930). And honestly, what I see on these does not make me happy. While the Cloud version of this ticket is still “Gathering Interest,” The Server one has been closed as “won’t fix.” Honestly, though, the Server version was closed back in 2010 with no indication of why Atlassian will not consider this. This feature request is something I hope Atlassian will take another look at for Data Center because the existing options to get this done are horrible. 

Multiple Assignees on a ticket

This one is something I see more and more. It’s often mentioned why some people prefer Azure Dev-Ops over Jira. Often, more than one person is solely responsible for a ticket, and people want that to be reflected in their tickets.  

I’ve had this request a few times in the past. Usually, I’d set up a Group Selector Field called “Assigned Group” to handle this task, which was fine. Not a great solution, but serviceable. But now that a real competitor does this by default, this solution is becoming less and less acceptable. 

Looking to Atlassian – they are also aware of this request. As of right now, I see a Server and Cloud Request, with the Server request closed as “Won’t Do.” The issue for Server was closed due to low demand, and considering it has three votes after two years, I can’t blame them. But given their new competition, I truly hope they’ll reconsider this, not just for Jira Cloud.

What is your dream feature?

When I posted this question – I got a lot of responses. Even just picking out those I felt I could speak on – I still had more than makes sense for a single post. So expect me to revisit this topic soon. In the meantime, comment here or on Social Media with your favorite feature request! If you have a link to it on jira.atlassian.com, post that too! Maybe others will go there and vote/comment on your favorite!

So far, I have the next couple of week’s articles planned out, and looking at some others that still need fleshing out. But this year’s theme for me is “Back at it,” so expect to see a lot more of me in 2023!

In speaking of seeing more of me in 2023, I’ll be live on YouTube at 5:15 PM Eastern today, reviewing some of the other suggestions I got from the community. I’ll do exactly what I did above – weigh in on the ones I feel I can talk about, see what Atlassian has said about them, and discuss how likely it is we’ll ever see these features.

Don’t forget you can follow me on my Social Media Profiles found on my Linktree link. Please like, comment, and share the post on the social media of your choice, as that helps convince the algorithms that more people need to read The Jira Guy.  

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