Dick Community Champion

Hi Andrei, Once you step into the branch "for parent" and checking for a story, the "issue at hand" is the story. Any additional conditions (there is an AND statement next) for (a bunch of?) subtasks would yield you NO issues that are valid to do the edit on. What you should do is replace the jql issue match statement with…

the internal directory entries are saved in your database. You can create/update credentials there.

Hi @Annie Kearns In addition to the filter settings mentioned above, a user not seeing tickets can be a result of two things: * The user has no allotted permissions to see any tickets in the project (has no role associated with browse ticket permission). Check project settings - users and roles. * The user has no…

Hi Stefan, Typical startup of javascripts is when the DOM is loaded. You can achieve this using something similar to: stuff mentioned at stackoverflow.

Not sure if this applies to your case, Andrew, but in datacenter Roadmaps containing Kanban projects mess with having storypoint-based capacity planning. Hope this helps, Dick

We should include the check if parent link is not empty in the JQL to know for sure that the automation is capable of branching for the parent. Now we don't have that check and we are misled by the intermediate loggings of stuff that has nothing to do with the branched issue.

Hi Omkar, If you post a picture of the automation, we're helping out people with questions similar to yours. Two flies in one stroke, so to say. :)

Hi, I think you have a typo in the second lookupIssues block: triggerissues.issuelink.key There is only one triggerissue.

You can only have one set of lookupIssues at a time, so make sure the .size parameter is stored before you go for the next lookupIssues query.

Hi Omkar, In your case I would build an automation with a trigger on the change of content of the Risk field on issuetype stories. You can follow that up by saving the parent key and subsequently using lookupIssues with a JQL query that tests for the two conditions, being parent key and Risk = Green. Rinse repeat for…

Nothing would stand in your way though to create a custom field that accepts multiple persons (type = multiperson picker). If filled-in, those can adorn your ticket in the supplied picture. :)

Hi Bill, So it would be something similar to: lookupissues = JQL query A create variable SizeA = LookupIssues.size Lookupissues = JQL query B create variable SizeB = LookupIssues.size followed by: edit issue customfield {{#=}} {{SizeA.divide(SizeB).multiply(100)}}

Hi Dorix, The viewability of a board is set in the general section of the board configuration. Just add-in the development project users by giving them view access.

The search for issues page should look like this:

Quickfilters have their jql stored in the Board - Config location. Just copy this jql and use it in the search for issues page accessed from the blue menu: issues use the advanced jql representation and paste your quickfilter jql there. Press SEARCH button, your issues will be displayed, then press SAVE Now your filter…

Hi Selva, Under the view settings (on the plan page) you can select the way of sorting the issues. It is often on the "ranked" setting, which can give unexpected results.

it should (works for Roadmap / Plans)

Hi Woytek, I think you managed to nearly get the necessary steps together: * first make another custom field A. * Use Issue from the blue bar to search the desired issues (the ones you need to change, but have the resolution set). * Go to Bulk operation on the selection:* Fill field A with an arbitrary value, this is your…

No, prevent any automation to close epics. In the default version of Jira, epics stay open, even if all tasks are done.

Hi HarshWardhan, Use a simple automation for this: trigger = create issue when issuetype = story edit issue field1 = "default value 1" field2 = "default value 2" easy as pie, Happy automating.

Hi Chaitawat, Order your items by starting date instead of sprint

Hi Sushmita, t's more the other way around. Epics do not get closed by themselves and one would need an automation to close them. So best check the automations that can run for you project and disable those. Cheers, Dick

Hi Jonas, Your lookup receives over 100 initial values that only then are reduced by the assignee conditional. Find the exact issues using a jql expression, in automation, then use the send email option with the required information. Regards, Dick

and don't forget to make it hours by {{issue.timetracking.timeSpentSeconds.divide(3600).round}}

More on math expressions by Atlassian: Here

Hi, You need to tell Jira that it's a math expression by using {{#=}} math expression {{/}}

It's the automation that would gather two arrays of issues that are described in your formula, then using the .size operator you can construct the equation and store the outcome in a similar manner to this: edit issue customfield {{#=}} {{lookupissuesA.size.divide(lookupIsssuesB.size).multiply(100)}}

The expression would fill the custom field using automation. It would kick-off your calculation and saving the result, keeping it up-to-date for you to enjoy... more documentation on math expressions available in automation

Hi Frank, Issuetypes can be "held" tight by archived projects, similar to workflow statuses. You should de-archive the culprit, then assign a different issuetype scheme (or modify the heavily used scheme), and then re-archive it. Suggestion for workflows: Make a workflow that only holds status "Done" and change the…

Hi Arina, You can use an automation to do the math for you. the lookup issues can be referenced using .size as is given in the Atlassian documentation