Aiden Marriott_za2e2r Specialist

@Tanya Morgan - Glad I could point you in the right direction :)

You would use Automation for Jira (now free with Jira cloud). The trigger would be on the component field being updated, you would conditionally check what component was set and then update a custom field with the relevant link. It Will take a little bit of time and research but should be achievable, you can also check…

Can you screenshot your hierarchy config?

Hi Nic, thanks for providing further info. It is frustrating for smaller partners like ourselves, and it seems counter-intuitive to not want to sell to as many people as possible. However, I can see the logic to it.

Your build process will be tagging Jira keys as and when things happen... so they would need to also tag the epic key when its deployed... i think. Probably need to check in with the developers.

Hi Kelly. Have you looked at Project Categories? This is an easy way to group projects together and you can filter based on them to get your combined view? Using Epics is another possibility as these are cross-project by default You may also want to consider looking at the marketplace for BigPicture or Advanced Roadmaps if…

Hi @Victor Hearn-Yeates - are you sure an Epic has been deployed? Presumably, this is linked to your build tools which update Jira? You normally would deploy individual stories or bug fixes rather than a whole epic no?

Rightly or wrongly, I think the answer is that they are not interested in you recommending it right now. I think Atlassian is focusing on getting the launch right within a small number of places and Atlassian partners.

If you have read that page I am confused as to what you are asking. Its a custom field that holds one or more Jira users. Assignee is a system field limited to one person. If you create a custom field rather than use the system field it won't be in any notification scheme by default.... not much else to it.

Hi @Abhiram Rao - have you created the hierarchy in the portfolio settings? Are both projects included in the source settings? Is the parent link available in the field config and screen?

Hi @Erica Nevius it should be easy enough. If you can identify the risks by filter you could set up a subscription to send you all new risks everday. It would be something like: issuetype=risk and createddate < -24h Save the filter and subscribe to it. Get it delivered every day. That would be one way. Another way would be…

Hi @Valentin Dragin This is a "next gen" only concept I think (although there are user-picker fields for classic projects). Details available here: https://support.atlassian.com/jira-software-cloud/docs/available-custom-fields-for-next-gen-projects/

Hi Ray. In Jira server you would need to use an additional marketplace add-on such as Automation for Jira, ScriptRunner, PowerScript etc. You don't get automatically calculated fields out of the box, unfortunately.

Jira server is bunled with a JRE - verify that there are not multiple versions of Java set up and which one Jira is actually using (System Info panel in admin settings). Check if your jira startup parameters include Djavax.net.ssl.trustStore which may point Java to an alternative keystore.

I don't think you are misunderstanding it, roadmaps is a neat new feature but its quite limited at the moment. There are things like "Advanced Roadmaps for Jira" which is bundled with premium cloud (I think) or BigPicture for Jira on the marketplace if need more functionality,

Hi Ray, This reads like a statement and not a question. What are you stuck with?

Hi @Richa Katiyar I think for the velocity and burndown charts Jira looks for the rightmost column (and status) in your scrum board to classify it as done (I'm not 100% sure that's right, but think so). So if that status has changed it may have caused the issue. If the estimation method has changed it could also effect…

You need to have separate screens set up for each issue type. Try looking at the "issue type screen scheme" in your settings. You will want to set a separate screen scheme (and screen(s) for each issue. The values may still be copied between issues depending on the field config... but you won't see them on screen. Hope…

After you create the new field you could export all your data, then bulk import the data back into Jira with value going to the new field. Then you would remove the old text field from the screen. Or you could use an automation rule to loop through all your issues and copy from one field to the other.

Hi Julia - apologies I missed that reference. I haven't seen anything in the standard API for this on the cloud. I have used Config manager in the past for this.. but its server only. I would recommend taking a look at the CLI app on the marketplace which may be able to help on cloud?

You can either use the JQL to filter on tickets you are interested in (e.g some like status is "waiting for support" and updateddate <= -d) or you can add a condition to your automation rule that checks the date.

If you want to see for the current: assignee = currentUser() should be included in your JQL search to achieve this. If you want all users - set up a dashboard gadget such as issue statistics or two dimensional report and group by assignee

There should be an option to "Share settings with an existing project" on creation in cloud which pretty much achieves this goal... the only problem is that having shared settings has other impacts - namely changing one changes all... this might be what you want, but if not its a problem.

Hi @Richa Katiyar - in what sense have they "turned zero"? You say the workflow was previously set to "any status" - I assume you mean all statuses have an all transisation? A common problem with this approach is that moving things to a "Done" status sets a resolution value and moving back to an open status doesn't remove…

That looks like a genuine bug @Fakhfouri Vahid - you would probably be better raising it directly with Atlassian support. Although some member of the community may surprise me yet!

Yes you can remove the sub-filter - if you are not using versions at all.

Hi Daniel. are you creating a "branch rule" from the trigger that then rules the JQL?

I assume this is ScriptRunner? Is it a "behaviour"?

If you output those two values to the log file what do they say? You may be comparing a string object with a date object which will never be equivalent This would only work if the date was exactly 24h ago.... you probably want two date objects and want to check if the date set is equal to or less than to +24 hours.

Having said that you could try playing around with this setting: