Hi - I'm looking for a visual cue to put on the ticket so when we look at the board we can see that it is blocked. A bright red label, a red boundary, flashing lights - whatever works!  Any enhancements in the works for this?

Hi all, I believe you will find really useful the following JQL functions provided by latest version of JQL Booster Pack (FREE):

• parentsOf()
• subtasksOf()
• epicsOf()
• issuesInEpics()
• linkedIssuesOf()

Is there a page with more examples?

I would like to add colors to cards based on filters. Marking a ticket which blocks another is quiete easy now (hooray). But what about the blocked tickets?

I would like to colorize in orange:

"This ticket is blocked by one or more other non-resolved tickets."

and in green:

"This ticket is not blocked by any non-resolved ticket"

@Joshua Wyss

"Solutions" like this are the exactl reason why my company is actively looking for Jira alternative (YouTrack by JetBrains, Azure DevOps by Microsoft, etc)

For those owning a license for Power Scripts (formerly known as JJupin] you have these features included.

@Joshua Wyss because I don't want to pay for scriptrunner to do something Jira already should have. 

when can we use this function issuelinks.. we have our own Jira instance in our server

OMG? JIRA still lacks this basic functionality? In Cloud?

Hi manohar.kurapati, 

This suggestion relates to Jira Server only. For status updates on Jira Cloud please watch the corresponding suggestion https://jira.atlassian.com/browse/JRACLOUD-25640

Best regards

Gosia Kowalska, Product Manager for Jira Server and Data Center

@Arthur Gniadzik

Please can you confirm when this basic functionality will be LIVE for customers?

We are using Jira cloud in our organization with 1100+ active users. To get a add-on to do this function will cost us $1000 per month. Really appreciate if you can get this feature live soon. 

Thanks

Thanks for detail update on current status.

@Artur Gniadzik

Thanks for the update! 

Do you have an ETA release for Jira 8? 

• Zac

@Artur Gniadzik

In your notes it says there was supposed to be an update within 6 months. It's been 8. Any update? 

This request, to me, is specifically requesting that Atlassian develop a JQL Function that caches and allows searching of Issue Link data based on arguments provided to the function.

Alternatively, I would say that asking for AutoComplete support for JQL Functions is a feature request in-and-of-itself. 

I'm not critiquing, I'm merely commenting on why that would be more difficult. 

For that purpose we have created this issue, right? we are suggesting Atlassian to provide this feature. Otherwise how can I get correct data of my project and sense for action??

That'd be nice but I don't think JQL functions support autocomplete.

filter should available for all linking including custom linking.

for example, it should be like, when we put 'type' and Jira shows all possible operator options.

Just to tell you that I'd need to create a filter where I can detect issues that are not blocked anymore, so can be worked (the issue is in "ToDo" and has blocking linked issues but all of them are "Done").

I would like for my automation rule to only run if a particular linkedissue type is not found on the issue. It doesn't look like the scope of this JRASERVER ticket will cover that

Wait! I see the issue now that Legna commented above. Thanks!

Hi all,

I would like to know if there is a target date for delivering this feature for cloud version that corresponds to the same request into this ticket. Since there are no updates over its status, I would like to know if there is any update about that.

That addresses is EMPTY and not EMPTY which is something that would be useful for our team.  However, it doesn't address the ability to search by issue type, eg. relates to, blocked by, etc.  Those would be very useful to our team, as well as to many other teams from the digging I've done.

Hi everyone,

Thank you for voting and commenting on this suggestion. As with most suggestions, this one also touches upon multiple problems and unfortunately there is no "silver bullet" solution that would address all of them.

As Jira Server Team, we are currently exploring ways to address some aspects of this suggestion, namely, making it possible to search by linked issues.

We have already asked some of you for feedback via email, but we would like to hear from more users.

Please spare 5 min of your time, review our proposal and respond to a short survey here: https://goo.gl/forms/whbCmntSe0Eu6tAv2

Let us know what you think. This will help a lot.

Thank you!

Gosia Kowalska
Jira Server Team

If you want it for the cloud, please vote for:
https://jira.atlassian.com/browse/JRACLOUD-25640

Echo Dan's opinion above: what about JIRA cloud? We need this!

What about JIRA cloud? This seems to me to be something that should be a part of the JQL

THANK YOU - this will be of great help for a variety of projects that we've seen. Looking forward to seeing in a future JIRA version.

Hi everyone,

Thank you for your votes and thoughts on this issue.

We fully understand that many of you are dependent on this functionality.

After careful consideration, we've decided to prioritize this suggestion on Jira Server roadmap. We hope to start development after our current projects are completed. 

Expect to hear an update on our progress within the next 6 months. 

To learn more on how JAC suggestions are reviewed, see our updated workflow for server feature suggestions.

Kind regards,

Jira Server Product Management

+100 voting this feature.

I think it's a case of the Atlassian technical tail wagging the business dog.

Some of our non-technical but important users spotted Scum Board quick filters and were immediately perplexed when they found themselves staring at a stock field in a JIRA issue but couldn't use it in filters.  I had to tell them they could have it if they ponied up for a per-user license.   Oh, and it's advanced filtering that adds programmer-like query primitives that are daunting to non-technical users.  We have a LOT of active users. The more there are the more there are to be perplexed.

JIRA Advanced Query Guru is not a job title here. I could be one, but I have enough work to fill my day and then some.

The field comes built in with JIRA and it's there in every issue. Sorry, paying per-user license fees for the ability to filter on fields that are built in just doesn't cut it.

It's hard to manage JIRA by current JQL, is there a plan for this feature?

seems that Atlassian can't make money out of this. So they do not care!!!

Also voting for this feature

Considering JIRA issues dynamically populated in Confluence pages is a pretty important integration and the only real option is through JQL filtering this would seem like a very necessary feature out of the box. Its very sad when the integration between two products made by the same company are **so lacking and incomplete. The thought that JIRA's Product Manager Dave Meyer would pawn the responsibility of this to the marketplace is embarrassing.

I'll go one step further. The query needs to (optionally) return the issues and subtasks that belong to the epic that has the selected link type.

why this function still not available ?

It is a shame not having this functionality.

Understood this is unlikely to be worked on, but it would be a very useful feature for us.

this would hugely improve the power of JIRA 

+1 this is a huge pain point for our team, with cloud version even if we were willing and able, we dont have the option of an plug in.

Mike, and why not SQL for JIRA?

Ert, we removed JQL Tricks from our production instance because it let users easily build JIRA killing queries. Training and "co-worker feedback" helped but we're always hiring new people who don't get that "feedback" quickly enough to make the training important to them.

+1. Can't we at least just add the JQL tricks plugin to Cloud?

+1 - Our company is using Jira cloud and we cannot load any of the add-ons needed to get this type of functionality.

Function linkedIssues() only shows the issues linked to a particular issue, I want to find all issues those are linked to other issues marked by a specific link type, e.g., "is blocked by".

This function could incorporate querying issues that are linked to any issue with a given link type and bearing in mind that links have two identities, one in each direction, the link type could be direction specific or not.

Examples

• find all issues that are blocked (one direction, no issue specified)
• * find all issues that are duplicates of any issue, or which duplicate any issue (bidirectional, no issue specified)

Edit: Failed to mention... that the company we are working with uses a competitive product that is able to filter these out. At our sprint reviews we present a report of
Planned Story Points — Completed Story Points ---- Blocked Story Points
Blocked Issue List (Lists the issues that are Blocks or Is Blocked By)
Incomplete Issue List
Complete Issue List.

The built in Sprint Report is very similar - MINUS the ability to show Blocks or Is Blocked By.

Sigh, if I had a dime for every time a feature we needed was only available as an on-prem plugin I could contract out my own implementation of an issue system.

I think Atlassian should start to follow the lead of other software vendors like Autodesk. When a 3rd party comes out with a plugin that many people use, they purchase it and roll it into their base software. I prefer this model, because I actually get new features and added value for each license renewal. It also keeps the add-on costs low, and thus the TCO low as well.

As an addendum to my above comment, there is a plugin called "Vivd Trace" that claims to have this searching on linked issues functionality, however it is not currently available for JIRA Cloud instances (unsure of JIRA server compatibility).

I used to use this functionality, got my teams on board with linking issues, now we can't access the functionality + the plugin that could have worked around this problem has been discontinued

Hi domain,

You can learn more about how we use jira.atlassian.com to prioritize feature requests here.

Regards,
Dave Meyer
Senior Product Manager, JIRA

For what version it will be scheduled?

When will this be available?

Atlassian must re-think about JIRA, AGILE & CAPTURE future enhancements/missing functionality to be added to the system to provide complete ALM solution to the market. Team has some wonderful ideas and end-users time-time providing valuable user experience feedback and suggestion to improve the missing functionality.

Overall end users is actually need these features, but unfortunately we couldn't get complete benefits from these features. We have to dependent on third-party plugins.....It is not a healthy solution to complete ALM product Atlassin is now offering to us.

Please consider all end-users feedback and organize end-user summit to discuss their needs and feedback/suggestions.

For us it is almost the same situation with buying plug ins.
Additionally it is always a nasty additional effort doing an upgrade (testing and reinstallation and organising latest plug-in versions etc). So we limit plugins and do not invest anymore. So at the end this will destroy Jira in future and after a few years we will definitely need to look for alternative tools. And what really makes me angry, when I read, that a plug in is now available, but only for the hosted version...
And so more plugins are installed, it seems that Jira slows down (it is not approved yet, but it is a feeling).

Hi @Dave Meyer,

I got the most of your points regarding add-ons. BUT I don't understand the pricing policy of Atlassian for add-ons (and I assume many of your customers as well). You should make a survey for this topic.

It is really annoying that the add-on tier always has to match with the tier of the Jira licenses although we need very often only a few for some plugins. When I'm looking for helpful plugins - and there are many indeed - you can often read comments like "only a few user would use the plugin so we cannot internally justify the costs". Then the vendor often answers that they don't have influence to the tier license policy of Atlassian.

In many cases we decide not to buy an add-on because there is no budget for a full tier license and we have to live with the lack of functionalty in Jira.

Why is it not possible to undock the tiers between add-ons and Jira core? In the end Atlassian may profit by a more customer friendliy pricing policy because more licenses will be sold. You should rethink your policy. I talked to some guys from other companies at a workshop who were searching for a good project / issue tracking software and some of them said, that they won't decide pro Jira because of its expensive pricing model for 3rd party tools.

But if your strategy is to focus only on big enterprises with big budgets than it's hopeless that you will change your rules, am I right?

Regards,
Christian Schmidt

Thank you for the thorough explanation.

Hi david.skreiner,

I feel obligated to say that there is absolutely no such policy. Our only goal, as a product team, is to build the best product possible for as many customers as possible. Obviously, promoting a vibrant and healthy ecosystem of free and commercial add-ons is part of delivering a great product, but I can unequivocally say that we will invest in what we believe will benefit the most customers at any given time.

Remember that JIRA is used by tens of thousands of companies, and each of them is using it in a different way, at a different scale, with a different set of priorities. JIRA's customizability and flexibility helps us support this, but at the same time it means that different customers perceive different features as "must-have" or "fundamental" as well as having vastly different perspectives on pricing. A feature that is critical for a small company that relies heavily on built-in JIRA reports may not register for a large enterprise that cares far more about JIRA's performance at scale.

From an add-on developer's perspective, the type of features that fit the description "highly valued for a number of JIRA customers, but not a core feature in the product" is exactly the type of add-on you want to build. If your goal is to build an add-on for the largest available market, your goal as an add-on developer should be to build the most highly desired features that aren't part of the core product. But the existence of these add-ons does not cause us not to invest in these features. More often than not, we have already elected not to invest in certain features and this creates opportunities for add-on developers to fill.

Obviously our priorities and needs as a product shift, and I can point to a number of features that we have introduced support for in the product that were previously filled by add-ons, like printing cards, a number of dashboard gadgets, importers, etc. Or we recognize that the demand from customers is so great that we need to invest in this with first-party support, as we have done with JIRA Service Desk and JIRA Portfolio.

We absolutely recognize that add-ons can be expensive and cause problems with upgrades. But we trust our Marketplace and add-on vendors to find the right price for their products, and the reality is that there is no way every add-on in the Marketplace could be a native feature in JIRA, so once you accept that, every customer is going to have a different perspective on which add-ons should really be "native features" and which should be "add-ons." With regard to upgrades, we are doing our best to improve capabilities for add-on developers with features like entity properties.

Regards,
Dave Meyer
JIRA Product Management

Unfortunately plugins tend to be either expensive, or cause problems with upgrades. I've met JIRA users and even JIRA Administrator Course teachers who say it's your policy to not implement stuff if there's an expensive addon for it, and warn against using Atlassian products because of these hidden costs