Mykenna Cepek Expert

Instead of using: .plus(20) on the datetime field, use this instead: .plusMinutes(20) From the docs here:

I noticed that the "Working with Major Incidents" hyperlink above went to Jira Server documentation. Yet this thread is tagged with "Cloud". There doesn't seem to be an exact match in the JSM Cloud documentation. Here is the Cloud version of Escalate an incident documentation.

I'm not aware of any way to do that, sorry.

There is an alternate; see my answer here.

Sort of. Enable "Open issues in sidebar" as shown below: This will use up the right edge of your screen, and allow you to edit fields without taking over your whole window with a modal pop-up. This works for all fields (which are configured to be visible for that project), regardless of whether they are custom fields or…

Very interesting question! There might be some options to get partway to your goal, using automation. There is a built-in trigger for "Sprint completed", and perhaps you could then do something with all the leftover issues. I explored it a little bit yesterday, but wasn't able to find a solution that seemed worth posting.…

Filters are owned by a person. They can also be shared or private. As an administrator, it takes extra effort to do the kind of "filter maintenance" you are suggesting. But the good news is that it can be done. Each board will be dependent on a filter. That filter could be owned by anyone. Note also that a project might…

Perhaps you're seeing the different types of settings between Next-Gen projects and Classic projects? More on the various permission controls here: https://support.atlassian.com/jira-cloud-administration/docs/manage-project-permissions/

Would be helpful if you could share a link to the documentation you mentioned. I could be wrong, but I'm pretty sure Confluence doesn't support "tabs on pages" without using an add-on app. Knowing which app you might be using would help a lot.

Short answer: mostly yes. You'll need to spend some quality time setting up (and maintaining) permission schemes and/or project roles to support this. Permission schemes and roles control who can see what, and also what actions they are allowed to perform. More here:…

You can use Jira Automation to do this. https://support.atlassian.com/jira-software-cloud/docs/automate-your-jira-cloud-processes-and-workflows/ When you use the "Edit issues" action with the "Labels" field, it gives you an option to "add/remove" values. You'd use the "Add" part to copy a value from one of those custom…

So in your question, I hear that you are using Jira to support team development using Sprints (aka Scrum), and that you want to break down your work using the hierarchy of Jira issues (e.g. a Story with multiple Subtasks). I also read that your Stories (for some work like developing a "Login Screen") tend to last longer…

I see that Ravi's info helped you get this solved, which is great. Note that the Audit Log was trying to tell you that your conditional wasn't working like you expected. If you see the message "did not match the condition" when you expect that it should match, then questioning the syntax or configuration of the condition…

Hi Dennis. Sorry to disappoint, but the short answer for you is this: you'll need to pay for a Jira add-on to do this. The basic set of JQL and Automation features in Jira (even for the Premium plan you have) do not support the aggregation of data from Stories to Epics in arbitrary ways. As you've discovered, there is some…

Have you looked at the Audit Log after running the rule for the first time? If it didn't work, there should (might?) be a warning, error, or clue in the Audit Log as to why.

Note also that the Opsgenie smartphone app makes it easy to see if you are on-call, and to check who is on-call:

This is great to know. It looks like the "parent" accessor in JQL in a Next-gen project will find: * the parent Epic of a Story (if one exists), or * the parent Story of a Sub-task (if one exists). This "expected behavior" has been missing from Classic projects forever. I suspect that this is likely within JQL only (so…

It looks like you're on the Standard (paid) plan, so you could try reaching out to Atlassian Support. You're trying to do something reasonable. Give them something they can reproduce (your query which returns nothing). They might offer a solution, or validate that this is not yet supported for Next-Gen. Sharing what you…

Several concerns for you to ponder and maybe address, based on what I see here... * As written, this rule will trigger for a "Due date" field change for any issue in any project. That's probably excessive, especially when I see the first conditional focusing in on just one project. Just want to ensure you understand that…

Wow. I wouldn't have believed it. But I just discovered that a plain JQL-based issue search (completely outside of automation) will fail on this: 2021-03-02 > duedate but will succeed on this: duedate < 2021-03-02 So just reverse the operands in your comparison (and invert the compare operator), and see if that works.

Responding to: I've already tried that and it didn't help, I received the same error message: I suspect you still have quotes around the smart value. Don't use this: '{{triggerIssue.duedate}}' Use this: {{triggerIssue.duedate}} Putting quotes around it will first substitute the smart value result (a date) and then the JQL…

I also just want to remind you that what you're trying to do is quite complicated. Unless you're willing to spend a lot of time figuring this out, you might want to re-evaluate the cost/benefit for this. As I mentioned earlier, it should be easier -- but currently it's not. Many known issues in automation will be in your…

Simply change your JQL from this: {{triggerIssue.fields.duedate}} To this: {{triggerIssue.duedate}} to eliminate that message. You don't need to use the .fields accessor in the smart value.

Quick question: I'm curious why you didn't use a custom field that can be either "R&D" or "non-R&D". That would allow each issue to self-identify, and be so much easier to manage than links. It also makes query efforts like this much easier. Is there some additional benefit you have by using linking for this?

A ha. I see now that you are using a Next-Gen project (not a Classic project) in Jira Cloud. I've tagged your question to help people realize that. I haven't used Automation with Next-Gen projects yet. So I'm going to step out here, sorry. I plan to learn more (and will watch this thread), but I don't have the time for…

Looking at the screenshot of your rule in the original post, it seems you're close, and that maybe a different concern is causing the inconsistency you see. Have you tried simply putting a "Refresh issue data" action before this conditional: It occurs to me that caching might be foiling your logic, and the refresh might…

Hi Dmitry. You have some really good questions here. _ _ _ _ _ _ _ The first thread you mentioned is a few years old. I contributed to it today, both updating it with new information (that might help you), and also to provide some additional warnings about the approach outlined there. _ _ _ _ _ _ _ The {{triggerIssue}}…

Here is a warning that folks often overlook when using this kind of approach. If the due date for an issue is cleared, the algorithm should ensure that all other relevant issues with due dates are scanned, to ensure that the desired date is reflected in the target issue. Consider the case where an issue had its due date…

There is a new way to do this, since mid-2020, as announced here: https://community.atlassian.com/t5/Automation-articles/New-automation-smart-values-in-Jira-Cloud/ba-p/1402775 Essentially you can write: {{issue.subtasks.Due date.max}} as a smart value, simply setting the Due Date for a Story or Task to that. Unfortunately…

While I appreciate the intention of this article, I think it can lead people who are new to Jira Automation to get frustrated with variables. The example in the article shows a looping component, but it doesn't actually loop -- the JQL returns only one issue. The example then shows how a variable set in the loop will…