Dick Community Champion

Hi Kalos, Thank you for accepting my answer / way of thinking. Be sure to turn the automation off when you're done creating the tasks under your epic, as you're running the automation for each issue created (also when it isn't attached to your epic). Your last question is answered in script two. Happy automating! Dick

you might want to set view permissions to the board in the board configuration menu to include the people in the project.

Hi Doug, Being an admin to a board is not the same as having the role administrator in a project.

Hi Stefan, Labels are in itself an array of values

to be neat: you would require the reciprocals as well (might be able to build them into one and two). Third one: if an epic looses the field account the attached issues should be loosing the field content as well. Fourth one: If an issue is taken from an epic it should loose the corresponding value for Account. Life is…

Hi Kalos, You would end up with two automations: First one: The start of your automation should follow your problem description: when: Field Account changes on an issue And the issue is an Epic Branch for all issues in Epic Then edit issue field Account = value copy from epic Second one: If the epic is already there and an…

You would have a workflow similar to this: * Open* Transition with condition set to hide transition from the user (meaning it can only be triggered from a workflow function) * Approved* Standard transition without a screen * In Progress* Standard transition with maybe a screen to register work hours etc. * Done

Hi Bhavik, Glad to see your actual question behind the original post :). My first impression of your original post was: this person mixes issue types and statuses. The act of running one of the scripts I suggested would be your triage action (no need to have a special issuetype for that). You can select the persons allowed…

You might want to check the scheduled jobs: cogwheel - system - scheduler details - jobs

Though technically, this is exactly what Bhavik asked, this promotes the solution of having two fields describing the same, with all the extra work attached.

Moreover, it would save you the hassle from having to bulk copy the issue type of issues already done and dusted, not to mention going without the extra custom field. 

Rule details * Name : Set to Bug When: Manual Trigger If issuetype in ("IT Help","Change", "Service Request") Then: edit Issue * issuetype = "Bug" You would have similar automations for Change, Service Request etc.

Hi there, It's far more preferable to change the issuetype, rather than using a second field for the same thing. You can change the issuetype with an automation with manual trigger, that will show up in the more menu when editing an issue. It would be like your dropdown triage menu, only it would trigger a very simple…

You can keep the number of issues that the managers see/ need to discuss small because you can filter on the special issue type.

Yes, without that access, they cannot see the issues in those projects. So that's needed to "tag" them with a Manager Info issue

Modification and movement permission of issues (like sub-tasks) are given in the project's permission scheme listed there (click it to get the overview). cog-wheel - system - issues - left menu: permission schemes - Your Project's Permission Scheme There, you might want to remove some roles from: Edit / create / delete /…

You can have a new issuetype that is only used in a single project M (where only the members of a special group have rights to see/edit). A good example would be the issuetype: Manager Info You can link these Manager Info tickets to tickets of other projects X, ie. use the epic link field of the Manager Info ticket to link…

There is an option to allow just one active sprint in a project: under Administration - Applications - Jira Software configuration you find the option to turn parallel sprints on/off

Sprints can only be closed by navigating first to the board on which they have been created. After taking out the issues and putting them in the backlog, you can choose complete sprint. Then, on the sprint reports page, you can find the delete sprint under the three-dot-menu

Ah, I see the issue reference worked :)

Looking at the above log, it's the commenting of the issue (last step) where the codes throws an error. When commenting, one typically requires an output that resembles more of an html text. You might want to show the newly calculated (and re-fetched!!) content of the field you just edited successfully:…

The re-fetch that @Bill Sheboy suggested is essential here. One of your fields is not carrying the value.

In your own examples, a full reference to the issue yields a correct value. Removing said reference doesn't work. I really think the reference to the issue is important here.

I suspect the variable you refer to gets the correct type ONLY if it's related to a full object (which the issue is). I'm calculating the Weighted Shortest Job First (WSJF) using dropdowns and a calculation similar to the one I gave above. Try it??

This is a repeat question. You might want to endorse the issues mentioned in this preceding question: https://community.atlassian.com/t5/Jira-questions/Roadmaps-for-server-version/qaq-p/988498 

Hi Kevin, Please share a screenshot of the board configuration page, tab columns. It will give us the opportunity to see whether you're having a scrum or kanban board, and also if your status flow matches Jira's

Hi Ethan, I have a similar calculation using custom fields. My calculation has the issue reference in it: {{#=}} {{issue.customfield_12800}} + {{issue.customfield_12805}} {{/}} I suspect that if you only use {{customfield_xyz}} the value gets interpreted as a string.

In the Permission Scheme, you find the project roles that are associated with Edit all Worklogs You need to have one of the project roles listed there.

For all others, I googled the translation of the above: I am trying to complete hours for a person on my team who is on vacation and forgot them and I get the following error: There is no "Log work for others" permission on the target project and no "Manage work logs" permission on a team with the work log owner as a…

Ah ,so you were secretly doing scrum on a Kanban board. :D The two really differ in their approach. And although Jira can let you mix and match these two, Atlassian really has put some thought into them.