Nic Brough -Adaptavist- Expert

You can simply convert your statement to JQL: label = <whatever label you are looking for> and status = closed

The usual cause of this is that your server has run out of disk space. You'll need to check that, make or add some space and then restart Confluence.

Right, so you are running one already. You should not be trying to start another one as well, just use the running one. For a completely clean start, shut the running one down, check it has stopped with ps again, and then start it.

Depends on how your scripts do it. If they simply make calls to the Java api that is there for deleting issues, then you do not need to worry about re-indexing, the delete function updates the index.

You will need to sign up as an Enterprise customer if you want the ability to pin your data to a location. There is no intention to change anything in https://www.atlassian.com/trust/privacy/gdpr at present.

No, they're not there just so there are workflows available when you haven't created your own. They are there because they provide data that Jira needs, and making them non-deletable stops end-users from deleting or breaking that data.

No, the frameworks are totally different. You can probably reuse the code that does the logic in your apps, but the Cloud version of the app will need to be written from scratch.

Ok, and what is your preferred route? I would guess "Jenkins does some stuff, which it somehow knows has an association with one or many Jira issues, so at the end of the process, it updates the issues with something". Is that the right idea?

You can't do this with a simple script, it's a very very complicated thing that you simply should not do. Two ways you could do it: 1) Write a vast suite of scripts that cover every aspect of changing a key (Jira has no code in it that will do any of this for you, barring a record of old and new key so it can still find an…

I can't really tell you a lot, you have not told us what you are trying to achieve, or if you have a preference for a particular route (for example, do you want Jenkins to poke something into Jira? Or Jira to pull something from Jenkins and update or report or log or, or, or, or...) Broadly though, if I could work out…

The simple answer is "the latest". Cloud is updated irregularly and very frequently - I've seen the version change twice inside a week. The version you are on is also of no practical use to you. You don't need to know it for anything. That's one of the things about using Software Services instead of your own server…

Right, so that app displays things in a different way to core Confluence. That's fine, but all I can tell you about it is that you need to change your data so that it is valid for Confluence. There's no magic "fix data that is wrong" here, you're going to need to look at each image and link that is not working and change…

No. Boards are not containers for issues, they are a view. There's no way to arbitrarily say "because an issue is selected by board X, it should not show on Y even when Y explicitly selects for it". To have a board not display issues that are on other boards, you will need to set up the board filters so that they are…

Start at https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/

If it's not listed, then there is not a version available for your system.

It does - look at the IDs in the projectcategory table, you'll see them in the project table. This sort of complexity is one of the reasons we all tell you not to bother looking at the database. It's the worst possible way to report on a Jira system.

When Jira cannot work out a simple list of status that a board might need to see in its columns, it defaults to just adding all the available ones. This can happen when you've got complex filters that select for many workflows. This is what you are seeing - your board filter does not define a project, so Jira has no choice…

You have not said what "add on app" you are using, and how you import images is entirely up to whatever method you have chosen to do the importing with. I can't help you with stuff you haven't told us about.

You can't remove those two, they are flagged as "system" workflows. They're there to prevent you deleting core system data that Jira functions now rely on having.

Yes, there is a risk assessment template in Confluence, to help you create documentation on risks. That does not answer my question. What are you asking us to help you with here? If you want our help with something, you need to tell us what it is you are looking for. What would help you move further on with your task that…

You can't - the csv import bypasses a lot of the front-end rules.

No. You have no access to the database in Cloud. You will have to throw away your database reporting and build your reporting properly (database access to Jira is the worst possible way to try to report on it, and in 16 years, I've yet to find a place doing it that didn't have dozens of reports that were simply wrong)

Set up a connection between Jira and Jenkins and configure it to do what you want it to. We can't tell you more than that, you've not given us any idea of what you are trying to achieve or what you have got set up.

There is nothing to "work around". You need to give your product owners the permissions they need to do their jobs.

Again, start by using the developer tools in your browser to see what is slow when rendering the pages. Look at what exactly is "slow"

* No, and you can't do it even with Scriptrunner - the framework that Server has for apps is not there in Cloud and the Cloud framework for apps does not support the way Behaviours works. * No, a field should only appear in one place, to avoid confusing your people * Only components can work that way currently.

Yes, email works in a similar way on Cloud, see https://support.atlassian.com/jira-cloud-administration/docs/create-issues-and-comments-from-email/ You will need to rewrite your plugins for Cloud, or find alternatives. Cloud does not allow the installation of Server/DC plugins and has a totally different framework for apps.

There is no way to know if increasing memory will help from the information you have given us here. You have not said what is slow in the process of using a Jira page, and memory is a factor in only part of it. If the slowness is not in the part the memory is involved in, then throwing more memory at it will do precisely…

You will need to check the permission scheme to see what roles or groups have the prioritisation permissions, then add your product owners to the most appropriate role for them. See https://confluence.atlassian.com/jirakb/configuring-permissions-for-ranking-and-scheduling-in-jira-agile-779158923.html

There is nothing to "enable", the REST API is a core component and Jira does not work unless it is available You just need to find or write code that talks to it.