Nic Brough -Adaptavist- Expert

There are a couple of options Raise a request at https://productsupport.adaptavist.com/servicedesk/customer/user/login?destination=portals Or I can take a look. I'm a customer success manager now, it's my job to help people out with our products (but I've done a lot of scripting in the past, and like getting my paws dirty…

What do you mean by "copy" a context? Do you mean you want to reconfigure the target field to have the same project/issue context that the source field has? That's probably not worth scripting, it's something you would do as a one-off, and your admin would want to be thinking about it - it's going to take you a lot longer…

Technically, all of those are of a "type" given by their name already! The code behind them defines them all explicitly. So "project" is a "project" type field, "created" is a "created" type field and so-on. You can compare them to custom field types in terms of how they behave though: Project, issue type, priority and…

I have seen this happen, when someone removed Jira Software from their Jira, then re-added it a few months later. There was a time where there was a bug in Jira Software that when it was added to Jira, it automatically added the Epic fields, but didn't check to see if they already existed properly, so it would duplicate…

Bamboo does not have a Cloud version, you can only run it on DC. You can run it on Cloud hardware though (AWS, GC, Azure, etc) The integration with other systems such as Jira works the same way for server and DC - you need to make Bamboo available over a network to the service you want to connect it to. On the Jira side,…

This error can be caused by several things, but there is one that jumps out at me from your screenshots. * This can happen when the server is out of disk space (either literal space or inodes - check both with "df -kh" and "df -kih) * The server has run out of memory while running the indexing * And the one I suspect it is…

All that happens is you won't be able to restore back to the ones you delete if there is a problem. I usually set up logrotate to clean out all but the last 10 or 20, or anything over a certain age. You don't need to worry about stopping Confluence or performance when you do the cleaning either, it has no effect on the…

What about scripts, listeners or jobs?

Are your issues resolved? That is, do they have a resolution set? Status is not relevant to that question, it's not the field that Jira uses to determine if an issue is resolved or not. (One of the jobs of a Jira admin is to make sure that a workflow sets and clears the resolution of an issue when it moves into or out of…

What does "unable to add" look like? What is stopping you during the "add field" process?

They removed the field from the edit screen, but left it on the view screen.

No, each status is a separate object, so the selection has to offer you all of them to select from.

Are there any conditions on the "submit" transition?

Welcome to the Atlassian Community! None is the really short answer. Add them, it will not have any effect on your current system. When people start to add your existing issues to themes and initiatives, it will start to matter - it will show in the Roadmaps, and you'll see it in the new issue types, but that's the point…

Atlassian stuff works on a flattened basis - group within group can be set up in Crowd, but the rest of the applications ignore it. So there's no reporting on it. You will have to look at the Crowd settings to work this out.

Welcome to the Atlassian Community! You will need to move these issues back into a status that the backlog recognises as "open". Search for them and then select "bulk move"

Welcome to the Atlassian Community! You will need to talk to the administrators of your systems. The community here has less access to your systems than you do, and cannot help beyond asking you to talk to your admins.

Welcome to the Atlassian Community! Could you explain the question more?

You acquisition is very good reason for "move" But it has consequences. Every issue type in a project has its own workflow. (May well be the same as all the others, but it might not) You need to look at what you are importing and decide how you want to handle it. Is it the same way you currently do it? If it is, how are…

Welcome to the Atlassian Community! You've hit an archaic bit of Jira history here. Jira 1 had a fixed workflow, and in Jira 2, it became the default. Atlassian have never removed it (I would like to think that is because it is a good example workflow, including stuff about getting resolution right and stopping people…

I'm going to repeat your "exactly (almost)", but take a step back and try to talk in more general terms than I have before. And probably bore you to death with a bit of history. I'll try to keep it short, but I'm afraid I am well known as a rambler, so it's probably still going to be a large pile of words to plough…

Thanks Kevin! I must admit I've never clicked through to see that. Atlassian have chosen status names that make sense to me without explanation. Great to know there's more detail directly online without having to go to documentation, everyone should do that more!

I'm not sure what "run a subtask" means. Nor "move", but I am sure that is due to me living in the Atlassian ecosystem for so long - in Jira-speak, "move" means "make a structural change to an issue, like changing the project it is in, or the issue type that all the config hangs off" As John said, I think we're missing a…

They created a project with a key of JS and then created epics in it. The key is the unique identifier of an issue.

That's a hard one, but a very quick starter would be to look at the project's "customer permissions". If you want to delve further into the automation, then yes, you will need to find the field. My usual story is "go to admin -> issues -> custom fields and find the one you're looking for", but that is rather slow when you…

You need to use the parenthesis I talked about earlier. That query is being read left-to-right, the "or" is not doing what you think it should.

Ah, yes. That's in the context of "the field is not there in the project" though. If you hide a field, it can't be changed by the users, but scripts and apps can still change it. If they do, the changes will not be recorded in the history because the field does not appear. I tend to remove system fields from create, edit…

When you look at an issue type screen scheme, it has links to go down into the screen scheme for that issue type. When you go into a screen scheme, it will show you what screens are in use for create, view and edit (and a default for when you don't change the others). You can click on those screens to go into them and edit…

I'm sorry, it's not about terminology. It is that putting estimates on non-sprint items is not going to work. The way Scrum works means that you estimate on sprint items, not fragments of them. If an item can not fit into a sprint, you split it up, lengthen your sprint, or convert it into an Epic/Feature that you can then…

Atlassian are not going to change the way resolution works any time soon. They may eventually throw it away, but they are never going to do direct edits.