@joshco are you able to elaborate on how this is solved by AI Rovo?

+1

Even Jira's own AI supports this suggestion!  It points to an addon (scriptrunner) but this really should be core functionality.

+1

+1

Please, please support referencing saved filters directly within another JQL query. The limits on this functionality is blocking my team from effective reporting and sprint planning.

use case:

issuetype = Epic AND "Parent Link" in (filter("FilterID"))

+1 We tie Epics to specific releases, so it would be good to view all child tasks for a particular release without having to mark each child task for the release.

Would not this affect other streams of income (plugins)? Maybe that is why Atlassian does not feel the need to rush it.  

+1

PLEASE implement this - it would solve for many use cases across the board in Filters, Plans, etc.

Yes, +1! Is much needed!

14 years and 800 votes
but still "Gathering Interest"
perhaps Atlassian should have the decency to put this to rest.

in the meantime Atlassian is advertising its own weakness in avoiding this type of pitiful outcome inherent to work management systems in general with a weak grasp of the long tail

+1

Badly needed feature.

+1

please implement this!

I have a (Kanban) board with JQL-based swimlanes, and without this feature I see no possibility to let sub-tasks appear in the board.

...At least no possibility that would work without the need to take care that each sub-task is individually flagged somehow to appear in the swimlane - which is just not an option.

To all awaiting that feature, since the advent of jql ai, let’s all ask to generate those kinds of querry, I'm sure Atlasian monitor more the ai issues than their bug tracker!

+1

I could really use this functionality in building reports, and am very surprised to learn it's still unimplemented.  We need to do things like "issue in linkedIssues(subquery(type = Type1 AND dueDate < now()))", which I guess is two things (let linkedIssues take a set of issues, and allow subqueries).

Yes please - make JQL more powerful

Would be very helpful

Would be very helpful. 

yes，please

It would be big help.

Yes pls

+1, it would avoid spending $$ for one more addon

Adding my vote to add this feature.

Yes please

Yes please - currently this functionality is only available in plugins, seems like it should be part of Jira Advanced

This would be very useful so I can run queries on whether certain subtasks have been completed for a parent ticket

We strongly recommend adding this feature. Unfortunately, it is not possible to filter and display issues in the hierarchy Initiative > Epic > Child task as the nesting of JQL is not supported.

Simple use case to find all children of all epics having a certain label: parent in (type=epic AND labels = test)

So if functions like "parent" would accept everything that provides a list of issues, this would massively enhance JQL. Every JQL functions should allow other JQLs as parameters as long as the returned value(s) is/are in the correct/expected format.

I also think this would be useful! Currently, I am trying to automate a rule: the trigger is a sub-task and I want specific subtasks of the triggering subtask's parent to be validated before moving the parent to another status. But there is no way that I can see so far. I can't even create a lookup table of all the subtasks inside that parent - it just returns all subtasks from every parent.

Hi team,

Like the Advanced Roadmap tool, which is based on the use of the Parent link field to establish the hierarchy, does not offer dynamic JQL functions that allow us to define the scope of a plan, actualy we cannot correctly and dynamically define the scope of our plans.
Indeed, we have defined a hierarchy of tickets (Initiative/Theme/Epic/story) and are on a Spotify type organizational model (PSI, Tribe, Squad) with the Jira PSI projects which only contain Initiatives, the Tribe projects of Themes and the Squad projects from Epic and Story.
Our need is to be able to define Advanced Roadmap PLANs for each PSI and each Tribe so that these high-level collectives can manage their achievement objectives which impact several Squads (an initiative impacts several tribes and squads and a Theme impacts several Squads of a tribe).
To define the PLAN associated with a PSI it would be necessary to be able to include all the initiatives of a Jira PSI project, all the themes of the different Tribes projects linked to these initiatives, as well as all the Epics and stories linked to the themes which are linked to these initiatives .
To define the PLAN associated with a Tribe it would be necessary to be able to include all the themes of a Tribe project, all the initiatives of different Jira PSI projects linked to these themes, as well as all the Epics and Stories linked to these themes.
And we can't do it...

Yes please this is just basic functionality that any reasonable user would expect to be there.

Please add this feature, it really is a must have.....

Hi team,

this feature would be really helpful, especially as we're starting to use Advanced Roadmaps with a custom hierarchy above Epics.

This would definitely help as we could create sources for Advanced Roadmap Plans easily, based on the top-level issues.

Upvoting this...

It's time that you guys release this feature (nesting functions and queries). It's a PITA when we try to build a query using (so-called-highly-advanced-and-flexible) JQL for hours and scratching our head only to realize that we might need some expensive plugin to do something like this.

You have 'gathered enough interest' on this one. Hoping to see this feature being worked upon soon and released as GA on Jira cloud.

Upvote it is

upvote for adding this feature. current project has a lot of granularity with subtasks and i need a nice way to include the subtasks in the sprint board without having to identify every parent ticket.

We strongly recommend adding this feature

Needing this on my team. I need a way to get a list of subtasks containing a specific text in the summary and which are linked to bugs closed in the last month. Kind of like:

type = Sub-task AND parent in (type = Bug AND status = Closed AND status changed during (2023-07-01, 2023-07-31))

I guess it's worth mentioning that the nesting feature doesn't have to do with using the filters function, but instead to allow nesting functions and queries.

An example would be: issue in linkedIssues(myApproval("project in ABC"))

Why is this marked "fixed"? The ask is to allow nested JQL statements, such as:

issue in portfolioChildIssuesOf("Project = initiatives and resolution = empty")

which would return all of the hierarchical children of issues in the "Initiatives" project whose resolution is not set.

This is still widely not-possible; indeed 23ef3e30d63c if there is an example of this available on Cloud, please share it. Otherwise, please reopen or change the resolution to "Won't Do".

Hey 7306b6a00137 the ability to include filters in JQL queries has existed for some time. If you are not able to use it we recommend creating a Support Ticket with us and please reference this ticket (JRACLOUD-21936). Thank you!

Tentative time line by when we can expect this feature available across all Jira Cloud users ?

This feature, as outline in this ticket's description now exists:

There is a related but distinct feature discussed in some comments here which is tracked on a separate ticket, here: JRACLOUD-18839 Create a JQL functionality to filter the sub-task / child issue for a field value of the parent issue

A ver muchachitos de atlassian.... cuando se van a poner las pilas con estas cosas? :... docenas de temas sin resolver desde hace mas de 10 años ..

Cada vez q quiero usar la parte de Planes (tengo licencias Premium para esto). .caigo en lo mismo ... no tengo forma de obtener todas las incidencias debajo de un grupo de iniciativa... todo lo que ofrecen para solucionar eso es usar una serie infinita de portfolioChildIssuesOf("XXX-100") OR portfolioChildIssuesOf("XXX-101") OR portfolioChildIssuesOf("XXX-102") OR portfolioChildIssuesOf("XXX-103") OR portfolioChildIssuesOf("XXX-104") OR portfolioChildIssuesOf("XXX-105") OR portfolioChildIssuesOf("XXX-106") OR portfolioChildIssuesOf("XXX-107") OR portfolioChildIssuesOf("XXX-108") OR portfolioChildIssuesOf("XXX-109") OR portfolioChildIssuesOf("XXX-110") OR portfolioChildIssuesOf("XXX-111") OR portfolioChildIssuesOf("XXX-112") OR portfolioChildIssuesOf("XXX-113") OR portfolioChildIssuesOf("XXX-114") y cada vez que se crea una inciativa nueva ir a tocar el pu$# filtro.
la otra opción que me dan es comprar un componente .. que lo necesito yo y otro lider del equipo ... pero tenemos que pagar licencia por los 200 usuarios que son mayormente stakeholders q usan el jira solo para reportar errores. y ahi tenes otro jira sin resolver o sin respuesta que es https://jira.atlassian.com/browse/JRACLOUD-59932 donde todo el mundo con una logica sensata les pide q no cobren los plugins el total de los usuarios sino por los reales usuarios.

Si no le van a dar pelota a las cosas que pedimos los usuarios . o si ya tienen una bajada de linea comercial de que solo laburen en lo que es redituable, avisen y no perdemos tiempo esperando cosas q nunca van a suceder..

GA!
Many thanks to the reporter for formalizung this necessity.
Any updates about this issue??
Many thanks!

This feature would be extremely useful to my team

Any updating for this??

I am wondering why Jira team is not taking this on priority when it is a most required functionality.