Curt Holley Community Champion

Hi @Cary Lewis I would do it like this....not perfect, but easy enough automation to write. trigger = issue created Condition = If/else block Where if reporter is one of [Insert all team members for the relevant team/component] Action: Edit issue to add the relevant team/component Repeat for each team. Yes!! the downside…

Actually, if you added New feature above Epic, in Jira you could still add sub-tasks to them, as Jira still sees all issue types as Standard. But I would not recommend this, as it gets mighty confusing when you try and use the upper levels with level 0 functionality (i.e. sub-tasks) You could also rename Epic to Story,…

Hi @Benjamin Peikes With your current set-up, "New Feature" must be a standard issue type (like Story) for sub-tasks to be associated with them. So, in Advanced roadmaps/Jira Hierarchy "New Feature" would have to remain there (level 0) to maintain that functionality. It is simply not possible to mess with the core…

The other way could be to do a bulk update (or one-off automation rule might be easier 🤔) once the new level is in place and some "Features" added to replace the Parent link from Epics to the newly created Features and then also linking those features to the Initiatives. A bit of work to do as part of the "Change", but…

Hi @Antun Štefančić The only way (I can think of) to achieve this would be via automation. Where estimation figure dictates the Due date field entry when compared to whatever baseline start date is used. Arguably this would be more effort than setting a start and due date...and would depend on where the estimation info is…

@Tim Cooley (TMNA) Plan settings/configure/scheduling/estimation (set to Story points) As ⤴️

Hi @Digvijay Bisht Welcome to the community. I don't believe that is possible as the Zephyr query language isn't accessible from Confluence. I would create a Dashboard using some of the many Zephyr related gadgets for displaying test execution details. then, if need be, you could iframe it onto a confluence.

I think so. I quite like separating them out. But I've seen both in action and having a lot within one giant schema can make searching easier, so.....no hard right or wrong that I am aware of.

Hi @Manas Shukla I can't seem to get this to work at all. I've tried various ics (icalendar) files, but I always get the below error. Any ideas why this might be occurring?

Hate to say it, but manually is the answer...currently. Here is a link to Use Assets Query Language (AQL) | Jira Service Management Cloud | Atlassian Support I'm uncertain of there being an AQL global search spot, like "Advanced issue search" for JQL. It would be handy though!!!

Hi @Brenda Stinnett So, we are talking cloud JSM/Assets I take it? When you say "we added our clients they are linked to AD", what client data do you mean and how is linked to AD?? Are we talking AD or Azure AD? I ask this, as currently I don't know of a way to sync from Azure AD to cloud Assets.....currently. I know it is…

You will see the fields @[deleted] and whatever value the automation has added, but you will not be able to edit the value. If they are still blank, i believe you are right, the fields not in the edit screen will not show.

Hi @[deleted] The fields are simply number fields. making fields "Cost of Delay" and "WSJF" read only is done in the Screen scheme by only adding "Cost of Delay" and "WSJF" to the view, but not edit screen. So you need two versions of the screen, one with "Cost of Delay" and "WSJF" for viewing and one without for editing.…

Hi @Isabelle Cuinet Thanks for the detail. So, I still say you could have a lot of the detail about the Initiatives in Confluence and then each project creates their Initiatives embeds the confluence content and configures relevant custom objects per project. OR If the initiatives would truly be carbon copies every time,…

Hi @심 여울 Welcome to the community! Hard to tell what it is you are trying to achieve with this rule, but here are a couple of thoughts. * you should have the condition before the action. Trigger>condition(s)>action otherwise the condition will achieve nothing, as the action will have already have been applied and the…

@Ricardo_Gomes Using the "Parent Link" field is the right way to link to issue types above Epic. The 2 you refer to represents the level above standard issue types (Stories, tasks etc.), as in: 2 levels above standard. Epic is always in the 1 level above standard and that can't be changed (though adding other issue types…

Hi @Isabelle Cuinet Welcome to the community! I'm struggling with what you mean by "the issues' statuses will stay the same and cannot be adapted depending on the project." can you please elaborate? Regarding the "Can you use existing issues as templates to create other issues" notion, yes you can, either via cloning or…

I don't think you can unless you are using Jira Cloud...it doesn't look like you have any multiple issue types per hierarchy level options like Cloud does. I would just use the existing one as your Brand, Product, and Release rather than having them above, as you now have this giant and somewhat confusing hierarchy that is…

Right, so you are not on Cloud then. Principle should still be the same, just the other way around. Epic's see level 6, they see 5, who see 4 etc. Question is, did you want your new ones to replace or perhaps be at the same levels as Theme, Initiative and Feature? Another question, seeing your on enterprise, does that mean…

Hi @Don Hames Welcome to the community. It would be great if you could share a screenshot of the Issue type hierarchy, so that we can see exactly what you have done. But Level 1, no matter what you call it, will always be where the Jira Epic lives (even if you have renamed it), all levels above Level 1 will make use of the…

Hi @Jamal.Hallajian This sounds like a nightmare scenario and one I can't help but question the value of. * I would not have a single Epic with anywhere near 1000 tasks. break the work down into smaller (confirmed dependent on each other) chunks. This way, if there is a slippage of time you can be certain all work…

I agree with @Florian Bonniec If each project had a space (rather than just a page at a certain level of the page tree in a space with all the other projects) then all blogs within would be about that project. Or as Florian suggests, if all projects in the one space, then by the diligent use of labels and settings within…

Hi @Jagmohan Upadhyay Welcome to the community. It will most likely be in the settings. Go to; Plans/Settings/Advanced Roadmaps permissions and check how each permission is configured. Sounds like you only qualify in the "Advanced roadmap viewer" permission, but require at least "Advanced roadmap user"

Hi @jeroen_wilmes You need to make use of the shared teams concept in Advanced Roadmaps/Jira premium. Once set-up, you can see all their work as one Team grouping Manage capacity in Advanced Roadmaps | Jira Software Cloud | Atlassian Support

HI @Hari Krishna D Not exactly. Yu could have both those date fields as the plans designated date fields, presumably desired is always before actual? (though the other way around would be the better problem to have) Then put desired in as the start date and Actual as the end date. that would show the deltas on the gantt…

Right! that makes sense. Good Luck! as I have no other suggestions....sorry!

Hi @Neil Taylor Welcome to the community! I'm not sure exactly what you are trying to achieve, but are you aware of / could you make use of.....the Issues fields condition options around the summary field?? There are a bunch of options, not just "contains", and you can make use of smart values in the Value section, plus a…

I understand what you are saying @Chris O Do the teams use the Time tracking functionality in Jira? As that seems like the place to start. If the Remaining Estimate field is used, then you can add it into the plan via the "estimate" field (as long as the Plans estimation type is not set to Story points) and set the view to…

Hi @Mario Amaya You can't have multiple levels of "standard" issue types in your hierarchy. All standard issue types (which includes both Stories and Tasks) are going to reside at the standard level. Similarly, all issue types that exist in your instance that are of the Sub-task level, will be in the sub-task level of your…

Hi @Chris O Isn't is as simple as clicking open the content of team 2 (for example), ensuring you have the Sprint and Hours fields displayed and review from there....or am I missing something? See my example below, ok I've got story points, but you get the idea...yeah? You could even filter by the sprint in question so…