Nic Brough -Adaptavist- Expert

Welcome to the Atlassian Community! That's what a cascading select list does by default (the selection in the first half of the field determines the options available in the second). So I am unsure what you are trying to achieve here. Could you explain more about what you're trying to do? Also, you've said this is a…

Ok, thanks for clarifying all of that! so I need to talk to the Cloud SR developers about their wording - they should not be using "Condition" here, because it has a different meaning in Jira-speak, and it confused me when reading the question (A Jira "condition" is something that stops you using a transition, not part of…

Welcome to the Atlassian Community! Most of the exam process is indeed automated, so I understand why you'd expect an instant response. There are some checks that need to be done by humans on some of them, so there's no immediate email sent out with your results. In the ones I have done, I got emails afterwards ranging…

Sub-tasks are fragments of an existing story, and hence have to be created from within the story. It would be a poor UX to have it on the create option. The process would have to be * Create issue * Select a sub-task issue type * New field appears asking for the containing issue * User would need to know the issue key that…

Welcome to the Atlassian Community! The easiest way to work this out is to use the fragment finder in SR. See https://docs.adaptavist.com/sr4js/latest/features/fragments for how to find and use it Improving the language and layout of fragments, including making the fragment finder easier to find and use is something we…

No, there's no way to do this

No it wasn't. See my answer from 2019 - it still applies.

Welcome to the Atlassian Community! You will never have the options you describe. Sub-tasks are not sprint items, they are a part of their containing story, and it is nonsense to have them in a different sprint to their parent. And the whole point of Scrum is that you do not "assign a story to multiple sprints". If a story…

But ignoring the permissions is what you are asking for. "that they want to be free to assign themselves to, but I can only grant them that permission if I also grant them permission to assign the team members" is exactly the point. If you could assign yourself, then you're ignoring the permission to assign issues.

Hi Sandip, Server/DC does not really have a "mange projects" like Cloud does. The screenshot you show is probably the closest you will get on older versions of Server/DC. Your version is 4-8 years out of date, not supported in any way, and may have some security issues that you really need to fix. I strongly recommend that…

I am not sure what you thinking a "fix" might be. Permissions need to be granular and clear, and the "can assign" and "can be assigned" are very clear. There are security and compliance issues you could easily run into if you were to implement "ignore the permissions and let me assign stuff to myself when I have no right…

Welcome to the Atlassian Community @Paul Warkentin You need to have installed an app to be able to do this. Bryan is using the JSU app, and I think it's on Server/DC, so it might not be valid for you, because I don't know if you are on DC or Cloud, or if you have something like JSU or Scriptrunner, or another automation…

You can't stop the transition during a post-function, as post-functions are executed at the end of the transition process and are part of it.

Hi Ana, There's a couple of questions here. Are you sure you mean a post-function and not a condition? If so, then I assume your "condition" is a decision point for the following code that will update something. Like "If request-type = 4, then change field X to Y, else copy summary to field Z" I am not sure what you mean…

Hi Angie, No, there's no downside other than losing the visibility in the summary that the issue is a clone. I usually leave it in, but have no problem if people choose remove the prefix, as most reports and apps do not really look at the summary to report on cloning, they tend to look at the "is a clone of" link instead,…

Welcome to the Atlassian Community! No, this has not changed and it is not going to. Sub-tasks are not sprint items, so you do not burn down on them.

We, the community, can not do this, we are not Atlassian. You need to do what Brant said, and if you can't do it for some reason, contact Atlassian support on the link he gave you.

Is it the same type of issue you are trying to create, in the same project?

Your account will not be seen as inactive if you are logging into it regularly. I suspect your Confluence is emailing you about a different account to the Atlassian account you use to get into Trello.

No, because the change of issue type is structural, it would damage or destroy the issue if done during a workflow action. "Move" is something that should only ever be done by hand (albeit bulk-move is fine), because it usually affects the structure of the issue. The only time you could do it automatically and safely is if…

You will probably want to read the server logs - it's likely that the message here is only giving you part of the story. However, it is telling you some of it. The LDAP server is not responding to your calls to it. As the first test passed, it is unlikely to be a network connection - the first test is a simple "can I find…

Welcome to the Atlassian Community! The first thing to do is get your server administrators to read the log files. The first one to look at is <confluence home directory>/logs/atlassian-confluence.log. The best thing to do is have them tailing the log in one window, while trying to log in in another window, that way…

Sort of. "Clone" has a specific meaning in Jira-speak. You're spot on with your "duplicate" definition, and the main usage for "duplicate" is when someone raises an issue that is describing the same thing someone else has already raised an issue. For example, when system X goes down, Alice, Bob, and Charlie all raise an…

Ohh, I got Robert when I read your comment. It reminded me of a peace lily one of my flatmates got, which she called LyndaLa.

So you're doing the right thing in splitting the story when you realised you've made mistakes during the estimation and refinement. Things are supposed to be dynamic, but splitting an issue up is not wrong. You've not said what you think the problem is here.

Hi Moein, Are you logged in as a system admin?

Go to Admin -> issues -> issue types, find the extra EPIC issue type you have added and simply delete it (or rename it to something sensible that tells the user it's at the same level as story)

It's the same answer.

You should be able to construct a URL to the version's configuration page - using https://aclsandbox.atlassian.net/projects/ANHBUPNIC/versions/10117/tab/release-report-all-issues as the basics, I think you can use {{issue.fixVersion.id }} to replace the id I've got in there (10117. And, obviously, change the base URL too)…

You have never been able to nest Epics within other Epics, you must have had a layer above Epics if your Epics were child issues There are a couple of ways you might have been making it look like you were nesting epics: * Your admins used very similar names for the issue types in different layers, like "Epic" and "epic" *…