So, I’ve been encouraging people to comment on posts for a while now. The algorithms I deal with almost require it these days. But that also means I get a lot of good questions and comments that people will never see. Given that, I thought I would collect the most interesting ones from 2022 (so far) and make a compilation of them.  

2022 has been an interesting year, and certain articles have gotten much more attention than others. But I will try to balance things out so that particular conversation doesn’t dominate things. Don’t get me wrong – I still plan to follow up on Atlassian’s DC “Ask me anything,” but I was hoping to speak to a few people one on one before I put anything out there. 

So let’s dig in with a trio of questions I got on some past posts.

Question on “What is an Issue Security Scheme?” from Michael

This [post] was going great up until “Go to the top of the Permission Scheme, and under the “Actions” drop-down, click “Edit permissions.” — then, the screenshots didn’t match up with what I was seeing. Besides, why allow access to any logged-in user? That seems to defeat the purpose of locking it down so anyone can see the issues.

Still – despite all of this, there’s nothing in there that says, “If an issue type Overtime Payroll, then apply this new issue security scheme.” If I create an “Issue Security Scheme,” – how can I apply it to the “Overtime Payroll” issue type?

What am I missing here? Your example of having only x-number of people see an “Overtime Payroll” ticket type is exactly what I need to do myself – yet numerous videos and blogs like this seem unable to get me over the proverbial finish line. Granted, I’m very new at Jira, but I would think there’d be an easy way to do something like this.

Considering his trouble, I think I need to go back and clarify the post in question. Even though the Issue Security Scheme has unique functions, most issues see it as a field. To have users change it, you need to have it somewhere on your Screens for the issue type. However, this is not my preferred way to handle Issue Security Schemes. I’d rather have them set at Issue creation using a workflow Post Function or Automation for Jira. Doing this eliminates the possibility of an “Oops, I forgot to set the Issue Security, and now some sensitive information has leaked” problem entirely. 

Question on “More JQL Tricks” by Christina

How would I exclude stories that may have multiple comments when one of those comments has specific wording and is from a specific user?

Here is the problem I am trying to solve. We have automation that writes a comment to a story from a specific account. I know the account and what sorts of comment wording I want to exclude. For example, the [email protected] account can write a few automated comments with the keywords REQMOV, REQSTUFF, or REQACK. Additionally, we will post additional comments to the story with our accounts.

So, I need to be able to filter out any stories that contain a comment by [email protected] and has “REQMOV” in the comment. What appears to be happening is that if the story has more than one comment, and any of the other comments don’t match these two criteria, Jira will include it in the search results, even if one of the comments does match. Because other comments don’t, it gets filtered in anyways, even though I don’t want that story.

Well, let me start with this general statement. Where ever possible, you want to avoid doing JQL on comments. First, they are incredibly messy to deal with in JQL. Because you can have multiple comments on a ticket, you get a situation like the one above, where issues that Jira should filter out due to one comment instead get included because another comment does match the search criteria. 

More importantly, Comments are not stored or indexed like Field data is. Because comments are not Indexed, the server has to go to the database to search comments, which is a time-expensive operation compared to the index. To further complicate matters, the database stores comments in a different table, which means you need several SQL Joins to get the data you want, which again is another Time-Expensive operation. To get the same result for the JQL ‘comment ~ “*”‘, here is the SQL Command I had to run:

SELECT CONCAT(P.pkey,"-",JI.issuenum) AS issueKey, JI.SUMMARY AS Summary, JA.actionbody AS Comment
  FROM jiraaction JA
    LEFT OUTER JOIN comment_version CV
	   ON JA.ID = CV.COMMENT_ID
    LEFT OUTER JOIN jiraissue JI
	   ON JA.issueid = JI.ID
    LEFT OUTER JOIN project P
      ON JI.PROJECT = P.ID   
  WHERE JA.actionbody LIKE '_%'
    AND JA.actiontype = "comment"
    AND 
      (CV.DELETED IS NULL OR CV.DELETED = "N")

I’ve read somewhere that comments lie about three joins deep, and my experiments seem to confirm that.  

So, if this is something you can change, I would encourage you to have the automation set a Field instead of a comment. Your Jira instance will thank you.

However, if you cannot change the automation, here’s what we can do. First, we’ll create one filter that finds all issues that match your criteria – that is made by [email protected] and has REQMOV, REQSTUFF, or REQACK at its start. Of course, you will need Scriptrunner to do this, but assuming you have the App, your first query will look like this:

 (comment ~ "REQMOV*" OR comment ~ "REQSTUFF*" OR comment ~ "RECACK*") AND issueFunction in commented("by [email protected]")

Save this query – I named it “EXCLUDE_REQ” for future reference.  

You will use this in your second query using the “filter not in” clause, which will make it look like

Project in (VOL) AND assignee = rnissen AND filter not in (EXCLUDE_REQ)

And that’s it. The second query will exclude anything the first query returns, meaning mission success. If you do not have Scriptrunner, I believe you will be fine so long as you remove the issueFunction clause.

I hope that helps!

Question from “Installing Jira on Windows” by ‘flexmyice’ 

(Not making this up!)

Hey Rodney, this is an incredibly good guide, amazingly simple and straightforward, as I like them.

After installing Jira on windows recently, I had some problems running the installer as an administrator. While launching Jira, it does not have access to all files, which results in an error at start. I did install it with my current user to do the trick, but I think I’m missing the point of starting Jira. Do you do something special to do this?

I also read here and there that creating a dedicated user for Jira is a good practice we should try to follow every time possible. But is it something we must do on Windows? If yes, I would kill to have the updated version of this guide!

This is my first comment, and I wish to thank you for all the good content. I always find real killer tips on this blog!

Keep up!

Hmm…well…you see. I’m not a windows expert. There, I said it.

I can do a few tricks on the Windows desktop platform, but for Servers, I’m vastly more knowledgeable about Linux. But the question has been asked, so I’ll respond to my best ability.

In general, yes. You always want to run Jira as a dedicated, unprivileged user. In theory, this will limit what kinds of things a Hacker can do if they were to use a remote code execution attack. However, that means you need to run the installer and the service as that user. Doing so will set up the permissions correctly, as I understand it.  

However, if you need to adjust permission, you can always right-click the Jira install folder, click “Properties,” then click the Security Tab to adjust permissions as needed. However, if things are done correctly, you shouldn’t have to do this – at least according to the official documentation. 

On LinkedIn, in reply to “Atlassian, we need to talk about Data Center,” from Francis Martens

Hi 👋 Rodney Nissen and others,

How do you see this move impacting your Atlassian consulting business? Do you see growth opportunities supporting customers on the Atlassian Cloud, or are you looking beyond the Atlassian ecosystem and focusing on other platforms?

Hey Francis! Fortunately, I am no longer an Atlassian Consultant – I’ve gone back to the dark side and now am a practicing Jira Admin again! That being said, I have some thoughts.

It’s been no secret that since Atlassian announced the Sunset of Server, the service Partners have been flooded with migrations jobs from customers to Data Center and Atlassian Cloud. This has, in turn, led to a hiring boom for qualified Jira Admins by these Partners – which is also leaving the market depleted of qualified Admins to work for companies themselves. 

So if (when) Atlassian announces that Data Center will be sunset, I see a few things happening. First, there will be several customers who have just spent a massive amount of money to move to Data Center and who will see this as yet another cash grab and decide their money is better spent elsewhere. Given how Jira tends to ingrain itself in workflows and culture, I don’t see many DC customers making this choice, but I’d expect as much as 25% of them to do so. 

The other 75% of DC customers – it depends on how well Atlassian does their homework. Simply put, how successful they will be at converting these customers to Cloud will depend on how much Atlassian does to make the migration path smoother. Right now, a move from On-Prem to cloud is no trivial challenge, especially if you are using Jira at scale. And if you have any custom automation, integration, or App, forget about it. But I can see as many as 50% to 65% of DC customers make the move to Cloud IF Atlassian can make the process as painless as they made upgrading to DC from Server. Of course, this does mean a bunch more work for the service Partners, which may offset the losses in the job market for those Admins let go by the first group that decides to leave Jira altogether. 

The last 10% will never be able to leave Data Center. Simply put, Cloud is never an option for them. The users are on an Air-gapped network or otherwise legally cannot do it. Depending on the size of these groups, they’ll either pay Atlassian for a special support contract for their particular instances or move somewhere else. And that decision will be determined by how big they are, how easily they can find another solution, and how important Atlassian is to them. 

However, the ultimate net effect is one we are already seeing. Let me explain with an analogy.  

In a mature forest, it’s rare to see saplings. All the established trees take up most of the light far above them, so smaller trees cannot survive. That is until one of the mature trees dies and falls. This tree’s death leaves an opening in the canopy, where smaller trees can suddenly get light, which leads to an explosion of growth in the spot, where new trees start to take root and compete to be the ones to take the fallen tree’s spot. 

If Atlassian’s Ecosystem is the Forest, the tree called Jira Server has now fallen. As a result, we are seeing an explosion of new competitors vying to be the next Jira for small to medium-sized businesses. If the tree called Jira Data Center were also to fall – well, just more room for more competitors – or more likely, more room for the existing competitors to grow into an even more significant threat. 

What do you think?

Hearing from readers, answering their questions, and talking to them about how much they get from the blog is one of the reasons I still do this. Seriously, hearing how I helped someone out of a tough spot because of an article I wrote is straight dopamine. So be sure to ask questions, respond to comments, and talk about the articles!

You can catch me on social media by following the links in my Linktree. Of course, I’m not the only one who enjoys your comments, so let’s all feed the algorithm today!  

You can also subscribe to get new articles delivered to your inbox by subscribing below. It’s the fastest way to get notified about new articles, so please consider it.

But until next time, my name is Rodney, asking, “Have you commented on your Jira issues today?”

---