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

Hi everyone,

Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; unfortunately we don't have any plans to support this in JIRA for the foreseeable future.

There are also a few add-ons on the Atlassian Marketplace that offer this feature if you're using JIRA Server (and several developers are looking at bringing this to JIRA Cloud also).

Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.

I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

Regards,
Dave Meyer
dmeyer@atlassian.com
Product Manager, JIRA Platform

Yeap, but it will be supported soon

IMHO, SQL for JIRA (Server) is a so much revolutionary add-on that Atlassian might review its policy for including 3rd party add-ons on JIRA Cloud. it would allow all the JIRA cloud users to connect immediately to their instances in a secure way via JDBC remotely and make really powerful reports, extract data, etc and overcome almost all the JQL limitations and provide a truly standard alternative for reporting. Unfortunately, it will not happen ever .

The drawback of a native add-on for Cloud (built upon the Connect framework) is the performance because all the data must be fetched by using remote REST/JSON services...

SQL for JIRA is not supported OnDemand so I cannot use it

SQL for JIRA supports it in a very easy and flexible way:

issue in sql("
select i.key, count
from issues i inner join issuelinks l on l.issueid = i.id
where i.jql='project=MYPROJECT' and l.type='Blocks' group by i.key
having count > 0
")

You have to change the l.type='Blocks' condition in the where clause to meet your link type needs as well as you may also want to set a different threshold in the having count > 0 clause to query for issues with more than N links of type X, for instance.

NOTE: SQL for JIRA is a revolutionary add-on which brings all the features and benefits of SQL to JQL so you can extend JQL with SQL or even SQL with JQL (bi-directional integration is supported). As it is pure standard SQL solution you can also run JQL reports via JDBC remotely and integrate them to your corporate Java applications or industry-standard reporting tools commercial and free like Pentaho, BIRT, jasperReports, etc,

Hope this helps

The usefulness of this cannot be overstated. Go for it!

What does it meen that it moved to the verified status? Do you plan to fix the issue now?

Thanks Alot, Keiei Tanto. Its really of good help.

If you are open to using an add-on, we have designed Vivid Trace to categorically solve such situations. The following JQL queries address each of your examples and will make a good starting point for fine-tuning.

1. To find all issues that are duplicates of issue JRA-25640 (one direction, issue specified):
issue IN relations(JRA-25640, "issuelinktype = duplicates", "direction = inward")
Adjust direction to suit your circumstances.

2. To find all issues that are blocking issue JRA-25640 or that JRA-25640 blocks (bidirectional, issue specified):
issue IN relations(JRA-25640, "issuelinktype = blocks", "direction in (inward, outward)")
Or use the equivalent "sugar" JQL function to make the query more concise:
issue IN links(JRA-25640, "issuelinktype = blocks")

3. To find all issues that are duplicates of any issue, or which duplicate any issue (bidirectional, no issue specified):
issue IN relations("issuelinktype = duplicate")
Note: This scans all issues that the signed-in user has permission to browse.

4. To find all issues that are blocked (one direction, no issue specified):
issue IN relations("issuelinktype = blocks", "direction = inward")
Note: Setting the direction to both inward and outward will give the same results. This is because any issue that has a blocking relationship in one direction necessarily connotes that there is a corresponding issue on the other end of the relationship. The following is equivalent:
issue IN links("issuelinktype = blocks")

In compliance with your implementation notes, the existing JQL function(s) continue to work exactly as-is; Vivid Trace introduces a new suite of functions. Their names have been deliberately chosen to avoid conflicts to a reasonable degree. The relations() suite of JQL functions have vararg behavior, and don't inflict upon you the need to memorize nasty parameter orderings. The queries are designed to be performant as long as your Lucene index is fully within the JVM's memory (more info). Vivid Trace brings the missing JQL function plumbing. Full product documentation here.

BTW, this issue along with JRA-2544 served as a motivation & benchmark for the design of the JQL functions. We kept you in mind the whole time.

(Edited to link product)

I agree its really weird this is not yet in place.

Actually, this is well over 3 years and its appalling that this functionality still does not exist in JIRA. taking into account the fact that there are plug-ins out there that meet this requirement. This is a MUST have requirement as it provides effective jira management.

Seriously...we're coming up on 3 years of talking about this...

Developing a Function for Server installs is pretty easy, building one for Cloud is impossible. Surely Atlassian can spare 1 Dev for 1 day to have a red hot crack at implementing this functionality, if not, perhaps they could work with Jamie Echlin (Script Runner) or Jobin Kuruvilla (jTricks) and integrate their products - thus saving a whole swag of time and avoiding further issues of this nature by future-proofing with this/these extensible development kits and library's.

Thanks in advance guys!

Hi!

I'm working on the Add-On for Jira Cloud, that contains different workarounds for missing JQL features.
One of them is a function that you are looking for:

• linkType(linkType) - Find issues by link. Returns both directions (e.g. "is blocked" and "blocks" for "Blocker" link)

Since there is no way so far to integrate Atlassian Connect Add-On to the native search, JQL Pro simply returns a list of found keys, so you can put them to the native search and proceed with your own needs.

https://marketplace.atlassian.com/plugins/jql-pro

If you have any other needs, feel free either to drop me an email or log a ticket in our tracker

This would be great for planning and showing dependencies. It would be great to also have access to the confluence pages (mentioned in). It seems that this feature is half complete. Being able to search by this info is extremely useful, and then being able to report on it is also huge.

I am using Jira Server and would like to be able to filter out issues that are blocked by an open issue and this seems like the place to go about adding my two cents

This be a must have.

What is the best way to track blocked tickets in the system without this feature? Add a custom field? Why would it be easier to search a custom field than something that is already built into the product? Please add this! We are using the OnDemand version of JIRA and there don't appear to be any add-ons available in the marketplace for OnDemand.

This limitation in OnDemand is really a pain. I would really like to use link dependancies to help my team prioritize. Please elevate the priority of this feature!

Hi, we are also looking for this - and we are using OnDemand, so no way to use an add-on.

Hey Nicholas,
Thanks for the suggestion. This may work for those users who have their own installations of Jira. The add-in doesn't support the OnDemand version which is what many of us are running, though. Hopefully, with the upcoming changes to the platform to unify the add-in model, this might be something to consider in the future.

Cheers,
Russell Sinclair, Animoto

G'day folks,

It is possible to write JQL that shows issues linked to another with a specific link type. You can do this with an add-on called Script Runner that is available via the Marketplace for Download versions of JIRA. At Twitter we use Script Runner to visualise epic dependencies with the following JQL: issueFunction in linkedIssuesOf(“project = XYZ and issuetype = Epic and fixVersion = \”2013-Q2\”", blocks)

It works like a charm. If you are interested in learning more about how we use it have a read of Using the Epic Workflow in GreenHopper and Visualising Epics and Dependencies in JIRA with GreenHopper.

Jamie, the author of Script Runner, has done a superb job keeping it up to date alongside the latest JIRA versions. Jamie, thank you very much - you are a champion!

Cheers folks,
Nicholas Muldoon

I would appreciate this feature.
It´s hard motivating people to save their data in a sematic way if they can´t find it afterwards.

needs that as well.
searching for linking issue is really a pain and we can't find any workaround on ondemand

Hi I also need to create a query that would select the following:

filter the return based on the linkedIssues of the parent - similar to the following select logic:
project in (PROJX, PROJY, PWC, IT, ANERDS, REDFROG) AND hasLinks = ("where Project not in ANERDS, PWC").

We are unable to get plugins so I have to rely what is available in the basic package.

This would be a useful feature for us as well.

Added a vote to this - being able to filter for open issues which are linked as blocking any other ticket, or filtering for issues issues which are blocked by an open ticket is something which would be massively beneficial for our workflow.

Using plugins is not an option so we currently use a horrible system involving labels to work around this.

Most of this is also possible with the jql functions module in the script runner plugin. Sorry, yet another plugin.

However, the implementation is completely different from the other two mentioned, which in my opinion do not scale well. Functions like hasAttachments, hasComments, and hasLinks("blocks") all happen in O(1) time. I have tested on live instances with half a million issues and all execute in less than half a second.

linkedIssuesOf / parentsOf / subtasksOf happen in O(N) time, but even on a a huge instance take a few seconds when operating across every issue. They all provide a subquery argument to restrict to just your projects if you need to.

issueFunction in linkedIssuesOf("resolution is empty", "duplicates")

takes under 100ms.

Docs: https://studio.plugins.atlassian.com/wiki/display/GRV/Scripted+JQL+Functions

This would be great. Using the custom craftforge JQL plugin, but the performance impact to the board is dramatic

Perhaps this plugin might help:
https://marketplace.atlassian.com/plugins/org.craftforge.jira.craftforge-jql-functions-plugin

You can do queries like the following which will show you for a project "myProject" all unresolved linked issues of the type "Blocks" (direction inward) linking to an unresolved issue of your project:

project != myProject and resolution is EMPTY and 
linkedIssuesFromQuery("project = myProject and resolution is EMPTY", "Blocks", "inward")

This way you can see all impediments from outside your project.

Need this feature asap so the team can see that stories are blocked due to bugs.

linkedIssues(issueKey,linkType)

I tried using linkedIssues() function without providing the issuekey but just the linktype as it is mentioned that we can optionally restrict the search to links of a particular type(https://confluence.atlassian.com/display/JIRA/Advanced+Searching#AdvancedSearching-linkedIssues). This does not work. I have to provide the issuekey. This does not help me at all.

Waiting for this feature to be available soon.

+1 for AOD. Or fix the AOD plugin problem...

Is this being addressed at all? We use OnDemand and for project planning and proper tasking this is a critical need, which we cannot use JQL Tricks for.

We're using the JQL Tricks plugin to do this and it is great. There are no performance issues if you use the linkedIssuesInQuery() function as long as the subquery that you pass to the function doesn't have a huge number of hits. You can get really precise results using the various sub-query functions that JQL Tricks provides. This plugin makes me love JIRA again.

https://marketplace.atlassian.com/31399

Hi Chris, is there any update on this issue?

Hi Chris,
is there a plan already when this feature will be available?
Thanks, Christine

Rafael,

Right now, this issue is unresolved (see the "Resolution" field), the functionality hasn't been implemented or released.

regards,

Chris.

Sorry, but it is now released this functionality? why you say, now that we
indexed the links?
I have a OnDemand version of jira, and I can't add plugins.

El 28 de marzo de 2012 01:57, Chris Mountford [Atlassian] (JIRA) <

The reason JQL Tricks is resource intensive is because it probably calculates the link logic by doing database queries, like the existing link function. Now that we index the links, the JQL function and the JQL Tricks plugin can both be expanded in functionality and/or dramatically improved in performance by using the index rather than the database.

We use JQL Tricks and while it's extremely powerful, it can be quite resource-intensive with some of its functions.
We've got a 400,000+ Jira instance, so we're probably not the intended customer.
Nevertheless, the plugin did cause a few OutOfMemory or GCLimitOverhead errors, even on a system configured with a 12G heap.

In the event it helps others, here's the results of our testing each function:

Function	Fit for Use	Notes
groupsOfUser([user])
groupMatches(regex)
hasAttachments([Count],[Operator])		Too Many Clauses
hasWatchers([Count],[Operator],[User])		GC Overhead Limit Reached
resolvedByUser([User])		Results were returned, but search took extremely long time
movedToStatusByUser(Status, [User])		GC Overhead Limit Reached
hasSameValues(Field1, Field2, [Field3] .. [Field n])
commentedByUser([User])
commentedOnDate(date)
attachedByUser([User])
hasNumberValue(Field, Operator, Value)		Initial search was slow, but subsequent searches were instant
componentsFromProject(Project)
linkedAllIssues(issueKey,[linkType])		Too many clauses
linkedIssuesByDepth(issueKey,depth,[linkType])		Disabling as it's a variant on the function above
hasLinks([linkType])		Already disabled
unlinkedIssues([linkType])		Disabled as it's a derivative of the function above
linkedIssuesInProject(project,[linkType])
linkedIssuesInVersion(versionId,[linkType])
linkedIssuesInVersionByName(versionName,[linkType])		Results took 20-30 seconds to return, which is borderline acceptable
linkedIssuesInComponent(componentId,[linkType])
linkedIssuesInComponentByName(project, componentName,[linkType])
linkedIssuesHasStatus (status1, status2, .., statusN, [linkType])		Caused by: java.lang.OutOfMemoryError: Java heap space
recentProjects()
projectWithUserInRole(role,[user])
parent(JqlQuery)		Caused by: java.lang.OutOfMemoryError: Java heap space
subtask(JqlQuery)		GC Overhead Limit Reached
hasSubtasks([subtaskType])		NullPointerException
hasSubtaskAssignedTo([User])
hasParentAssignedTo([User])
hasSubtaskStatus(status)		This method is discontinued from v3.0. Use subtask function instead!
hasParentStatus(status)		This method is discontinued from v3.0. Use parent function instead!
membersOfGroups(group1,group2,..,groupN)
projectLeads()
projectLead(project)
usersInRole(project,role)
userMatches(regex)
dueVersions([Project])
currentVersionsBySeq([Project])
currentVersionsByDate([Project])
versionsAfterDate(date)
releasedOn(date)
versionsAfter(versionId)
versionsBefore(versionId)
workStartedOn(date,[User])
workLoggedOn(date,[User])
workUpdatedOn(date,[User])
workLoggedBetween(startDate,endDate,[User])		DB Dependent, query ran for a minute or so

This was a result of testing on Jira 4.3.4 with the latest 4.3 compatible JQL Tricks version.
We've yet to repeat the tests for Jira 4.4/5.0 with the newer JQL Tricks function.
I know that one JQL issues was fixed by Atlassian in 4.4.5 which should help the performance issue.

Thanks Bryan - however, some of us are using the OnDemand solution.

There is a ticket open to add JQL Tricks to the OnDemand hosted environment, so anyone who is interested, please vote on it: https://studio.atlassian.com/browse/JST-4710

There's actually a plugin which provides a number of issue linking extensions to JQL, called JQL Tricks. You can find it here

The list of functions it provides is below, which includes a "hasLinks" qualifier for JQL.

Issue Links Functions

• linkedAllIssues(issueKey,[linkType])
• linkedIssuesByDepth(issueKey,depth,[linkType])
• hasLinks([linkType])
• linkedIssuesInProject(project,[linkType])
• linkedIssuesInVersion(versionId,[linkType])
• linkedIssuesInComponent(componentId,[linkType])
• linkedIssuesHasStatus (status,[linkType])
• linkedIssuesInVersionByName(versionName,[linkType])
• linkedIssuesInComponentByName(projectName, componentName, [linkType])

I need this feature urgently

I also need this feature.

We are using linking of issues extensively. I had assumed (always dangerous) that JIRA would have the ability to report on linked issues. Seems a basic requriement.

Can anyone indicate when this feature will be available?

Hello Atlassian Dev Team,

I need to create a query that select the following:

more than one linkedIssues in more than one project - similar to the following select logic:
project in (Pxxx100, Pxxx110, Pxxx111, Pxxx112, Pxxx113, Pxxx114, Pxxx115, ..., Pxxx124) AND hasLinks = ("relates to", "depends on").

I am looking forward to see this statement in the standard JQL

Thanks for considering the request in your roadmap.

Agreed. This would be helpful as well for our company. We use a lot of issue linking, and it is often good to be able to create filters based on if an issue does or does not have a specific link type to another issue (the example given in the description of blockers comes to mind). Added my vote as well.

Yes, I added my vote too. It'll be great to know/search how issues are linked to each other. For example: Project = ABC and links in (ABC-123, XYZ-1)

More advanced would be to SHOW LINKS DEPTH = 3 will show relationships between projects, issues.

This feature would help us alot as we use Links extensively.

Our enterprise looks forward to having this capability.

Def consider this a priority for us.

Our enterprise looks forward to having this capability.

Also voted for this one as we use many liks between customers projects and internal projects

Superimportant. This will make handling/queries so much easier.!.

Superimportant. This will make handling/queries so much easier.!.

Our team would definitely use this as well. Would be very helpful to increase search efficiency.

I could definitely use this! I want to see which issues are blocking others so I can prioritize those first.

I voted for the issue and I am happy to see that this feature will be implemented soon

Thanks for taking the time to comment Ellen, I agree with you this is a useful feature we should implement.

While I can't promise it will be scheduled for a coming release, I have done the preliminary work to enable this function to be created, lowering the remaining work for this and related link features.

I see you have voted for this issue. Be assured we will be considering it and will make our decision based on what the total impact across all our customers is, how much work needs to be performed and also what other work we are doing that is closely related.

Due to the limited reporting capabilities on issue links, issue linking really isn't as useful as it could be. We are hesitant to use links when we cannot generate good overviews and dashboards showing which issues have which kinds of links to which other issues. There are numerous cases where this would be eminently useful. Please address this issue.