@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

@Valadan Colovic I'm not sure what Atlassian's incentive to adding this feature is when ScriptRunner already has it and has more options. Plus, Atlassian surly make a profit off of the add-ons...

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.

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.

Hi, I have been using Jira for several months to organize delivery on distributed software factories (Europe, Centro America and South America).
Jira was very helpfully and powerfully tool for that, but definitively I think this is one of the most useful functionalities that is missing.
It would be nice to have something like:
> issue in linkedIssues(assignee = username, "testing discovered")
> issue in linkedIssues(assignee in memberOf("team"), "testing discovered")
> issue in linkedIssues(assignee in memberOf("team"), "is blocked by")
> issue in linkedIssues(priority > Major, "is blocked by")

Thanks for considering in your roadmap.