-
Suggestion
-
Resolution: Unresolved
-
1,614
-
34
-
Summary
Currently, portfolioChildIssuesOf() only accepts one input parameter in the form of an issue key. This makes searching for child issues of multiple parents unwieldy, and doesn't allow for flexible search of child issues based on other parameters. This function also does not include team managed projects.
Desired Results
Either or both of the below results would increase usability of the function and it would be great if this function also returns team managed projects which can be child or parent of an issue.
- Allow the function to accept multiple issue keys as a comma separated list. E.g., issuekey in portfolioChildIssuesOf("EPIC-001", "EPIC-002", "INIT-001") returns all child issues of EPIC-001, EPIC-002, and INIT-001.
- Allow the function to accept a subquery within JQL. E.g., issuekey in portfolioChildIssuesOf(project = ABC and issuetype = Epic and environment = "Desktop") returns child issues of Epics in the ABC project with a specific value in the environment custom field.
- relates to
-
- Closed
-
- Gathering Interest
-
- Future Consideration
[JRACLOUD-89892] Extend functionality of portfolioChildIssuesOf() to improve searchability
This is the single largest frustration among the PMs I work with. It's infuriating that you can't do this via quickfilter.
We are starting to use the Initiatives issue type, so having this functionality to search for Initiatives that are parent of issues within a range of projects, by key, would really improve the usability in plans, by building over a filter like this.
The main issue with nested JQL queries, and something to keep in mind is that they can be abused and create high load on the system. If Atlassian was to implement this, they would have to take that into consideration.
—
An automation workaround that may assist with some of the use cases on this JAC ticket.
We created an automation that copies the grandparent information from the parent into the child issue.
Eg:
The automation picks up the parent field from the Epic and then populates a field on the Story.
This then allows for JQL searching on the Story using the grandparent Initiative as a JQL filter.
Hope this helps someone.
Throwing support behind this
We have a use case where the demand is to update all children of tickets for ANY Epic or Initiative whenever the Components are updated, not just a specific Issue. It needs to be an issue type level function. Example #2 in the Desired Results would be a great way to implement this ask.
Currently A4J allows for a single child ticket to be updated by issue type but not all the way down the hierarchy.
+1
We urgently need this function to be updated with also supporting issues from team-managed projects.
Our use case:
We want to plan a huge initiative with Advanced Roadmaps/Plans. There are several projects (company- and team-managed) participating in this initiative which already contain hundreds to thousands of issues, but only 10 - 100 of them belonging to the initiative. When I now include the whole projects into my plan, I will reach the issue limit (5.000) pretty fast, so I would have to narrow down the included issues with a proper filter query. Unfortunately, without portfolioChildIssuesOf(), I don't find any filter query which would meet my needs: showing all issues through the whole hierarchy (initiative -> epic -> story/bug/task -> sub-task) belonging only to my planning-projects initiatives.
So I really need this function to include also issues from team-managed projects.
In the same context I'd also be very happy to see option #2 being realized to include all our initiatives in one easy function call, but I might have a workaround for this issue: I'm thinking about creating another hierarchy level above initiative, create one issue of this type and per default link all my initiatives to this one ticket. Then I would have to call the porfolioChildIssuesOf()-function only for this one ticket and keep it kind of dynamic for upcoming issues in the underlying hierarchy.
+ 1
Right now I am stuck with this query which I have to manually update every time someone adds a new issue within the two highest levels of our hierarchy (we have two issue types above Epic.)
"Parent Link" IN (EDZN-17196, EDZN-16950, EDZN-17183, EDZN-17436) OR "Parent Link" IN (EDZN-17911, EDZN-17880, EDZN-17838, EDZN-17816, EDZN-17807, EDZN-17777, EDZN-17771, EDZN-17768, EDZN-17764, EDZN-17763, EDZN-17760, EDZN-17759, EDZN-17758, EDZN-17756)
Same goes for new JQL function parent(). Only takes issues but no sub-queries. Taking this fact into consideration while thinking about the - theoretical - possibilities of Advanced Roadmaps makes me feel like riding a Ferrari with a Fiat engine 
BR, R
+1 more for this feature. on the whole getting data out of Jira is reasonable but this is a really shortcoming. and having to go to scriptrunner or jqlsearch is expensive and burdensome.
Both the desired results above would be magic btw
@ljones - make us all happier more fulfilled people
Pasted from
Just in case it benefits anyone, most but not all of what I am watching this issue for is now supported by
parentEpic in (EPIC-1, EPIC-2, EPIC-3)
in Jira Cloud without using other addons to support it, I realise that this isn't all that all are asking for, eg. I have to get the comma-separated list of Epics together first rather than being able to write JQL between the brackets, but after moving from cloud where "epic link" in (EPIC-1, EPIC-2, EPIC-3) was so intrinsic to how I was filtering, this was a massive step forward when I discovered it in November
(My response to Atlassian : https://support.atlassian.com/requests/MOVE-146157/ “@Rananjay this DID help but slightly by chance, because ParentLink DIDN’T do what I wanted, but ParentEpic DID, so please close and please ensure anyone else with same query knows about ParentEpic as likely means they won’t then be left waiting for https://jira.atlassian.com/browse/JSWCLOUD-19543 or considering paying for Premium when not required for ParentEpic to work.. Thanks, Tom “)
+1 I came looking for a solution like #2 portfolioChildIssuesOf(subquery)
I just cannot believe this seemly very straight forward feature is still not available ever since Portfolio was acquired by Atlassian back in 2017?
This makes Advanced Roadmap half dead for adoption by organizations that are running single plan tracking dependencies among the 5000 - 10K issues for annual or semi-annual releases.
Would certainly use this within my organization. We are in need of this feature for our workflows. Specifically to lookup and filter by child of parent with certain field values assigned (custom people field).
For me, the ability to filter Epics by labels, as an example, in a Jira structure, but then let the structure NOT attempt any filtering on the children would address this also. That allows me to identify some level of the hierarchy where I want the labels to apply, and only apply the filtering at that same level.
This is so basic. Please add the option 2. Need to be able to provide a subquery.
The construction like "Parent Link" in ( ) might be a workaround for some cases
I Need Option 2. I need to be able to search for all PortfoliochildissuesOf(Subquery)
It’s one (or two :wink: ) of those things that should have been developed at the very beginning and introduction to hierarchy in Plans (Advanced roadmaps). I am having a hard time selling the product without it.
Come on get this feature! Should not need to script for stuff like this.
Please add the feature like portfolioChildIssuesOf(project = ABC and issuetype = Epic and environment = "Desktop") as well as the results of another query like
portfolioChildIssuesOf(query=<queryname>)
I like this feature. What I was looking for is Desired result #2. Thank you!
This would be extremely helpful for out team. Hope it will be on your roadmap soon!
Pls PRIO this feature! This is super required for advanced roadmap usage
Agree with all the above, please add this feature (ideally through the subquery version/option)! Thx.
The ideal scenario would be to have the function accept queries as input. This will allow for dynamic queries at save considerable effort by no longer having to manually update JQL queries.
The cynic in me suspects this functionality will be added via way of a plug in, however I find it surprising the ability for nested JQL queries (even just a single nesting) is not part of the base product. We're all looking for ways to make reporting easier and more automated, and without nested queries, it feels like a sloppy work around.
Although the example above is for Epics and Initiatives, it would be it's most flexible if applicable to all levels.
eg, returning Subtasks, of all Stories or Tasks that match <criteria>
Being able to input a sub-query would be so valuable. For example, trying to create roadmaps and charts based on the child issues of all In Progress initiatives or epics.
This is a MUST DO if we don't want to make all the users exhausted from searching multiple times and make a plan with many filters associated.
This would really help us use and plan Initiatives and Advanced Roadmaps well.
This request was raised almost 2.5 years ago. Still not implemented
Please this is the basic functionality. This will help us to create a filter much easier for product owners. please get this feature ranked up.