Nic Brough -Adaptavist- Expert

Your screenshots are from the "import from an xml backup" process. You can't feed that a database backup, it's simply unreadable. Stop confluence, drop all the tables in the database it is using, restore the database dump into there, and restart Confluence. You'll want to kick off a full re-index immediately, to re-enable…

You can't. Cloud has only one set of priorities. The documentation you've been reading that refers to priority schemes is for Server, a different product.

>but even after adding the "group" level access condition, whole group can see all the transitions at any point. I don't think you've put the right condition on the transitions. >Are you suggesting I should include status conditions on each transition? It would be very complicated and tedious to set up this. Any other…

It depends on how you have been doing the upgrades. A standard upgrade process will create a new bitbucket installation directory and reuse the data (home) directory, so I would expect to see a batch of old install directories that you are no longer using. You can simply delete these entirely. If you've been doing it in…

There is no direct association stored, so the REST API has nothing to tell you here. Of course, you can work it out, but you'll need to track it down. Start with answering the question "what data do you enter into Jira to tell it that a sprint is associated with a team?"

Either your admin has chosen to botch in 2596 as the limit, or your search only fetches 2596 issues.

If you try to delete a status used by an active workflow, Jira will tell you that you can't (without accepting changes to the workflow) You should not delete the old one unless you have checked that you do not need it.

Space is probably not the issue here there are some basic checks that yell "disk space error" well before you run into a real problem with it. But if your filesystem is a shared one, it's going to be horribly slow (i.e. useless). CPU and by implication, memory, sounds fine from what you have said. Indexing stats are a…

There's nothing to do but wait at this point. 8.5 has many index improvments in it that save me having to write an essay on a lot of things you can do to improve performance. Last time I upgraded a large 7.13 system which was indexing at 2 hours, we went to 8.13 and the indexing, dropped to a shade under 35 minutes. So,…

It will, a little. It will also destroy your ability to search or sort on the field until you re-enable it and do a full re-index. Disabling bits of it is not the answer here. If you turn off bits of the indexing, you reduce or destroy the usefulness of your scripted fields. Before I write a long if/then essay, can you…

But the file might be present if someone has added it. The docs I've seen do mention that.

Still no reason to build it in. As I said, if you want one, add it (and reserve its use for the people who know how to use it)

Workflows are made up of "steps", each of which you will link with a "status", so Jira knows what to tell the users when an issue is at a specific step. The status are a shared list. So if you change a status in one workflow, it will affect all the others where the same status is used. To decouple this, instead of…

Sorry for the delay. A label is held in a similar way to multi-selects, so in your code, lista will be holding an array of label elements. So if you iterate over that, using .getName() on each element, you'll get one value string at a time.

opsbar-sequence changes the order transitions appear in. There's no code for arbitrarily hiding valid transitions. They're there for a reason. If you genuinely want to stop someone using a transition, put conditions on it to prevent them using it, then it won't appear on the list.

There isn't a way to do this. A dashboard of dashboards would be a load of boxes with many way-too-small-to-read images of each of the sub-dashboards, and would run slower than a three legged dog on tranquilisers (there's a reason you're limited to 25ish gadgets - each one imposes load and makes it slower to load. A…

That scheme might work for you, and you can do it with a custom field. But it doesn't change why the severity field was removed, and it's definitely no reason to add a system field for it (that most of us would then have to get rid of again)

Technically, you can turn it off while re-indexing. But that will break every scripted field you've got. The indexing throws away the index for the field and re-creates it. If the scripted field script is not run during index, it won't create the data for the field. You'll basically destroy all your scripted fields, and…

No, the complete opposite - it was part of the job to get and act (or not) the notifications. If he had had the option to opt out, he would have been shifting the responsibility and breaking the process. Anyway, the point here is that you are railing against the wrong thing. The tool is working fine, and can be set up to…

There are a number of things wrong with this script, but I cannot tell you which parts need fixing because I cannot work out what it is supposed to be trying to do. Could we take a step back and start with a description of what you are trying to achieve? What do your end-users get out of this?

"5 months old" suggests August, so you won't be able to go to 8.13. Your licence is valid only for versions released before its end date, so probably 8.12.0 or below (but not 8.12.1 or above). Check the exact date against the release dates on https://www.atlassian.com/software/jira/update. To go higher, you will need to…

I needed to get that out fast, to minimise the damage you're doing, rather than explain it. Jira cannot be used like this. A Jira server install needs to be run with one single database that no other Jira is trying to use. Two Jira server installations cannot and must not share a database. Somehow, you seem to have…

Argh, no! You need to shut down one of these Jira's instantly, and prepare to restore from the last good backup (you might be ok, but there's a good chance that you've corrupted your database so badly, you need to start over from before you did this)

>Why is being able to "opt out individually" a "bad bad idea"? Really incredibly simple one. I have seen someone arrested (and sacked for gross mis-conduct) because they ignored an email from Jira. You're right about "ne size fits all" - there isn't one. But you can, and should, get your admins one that is "one size is…

It does, indeed. Trello will remove the interactions because it no longer has an account to hang them on. Jira and the other more powerful trackers use the concept of a "dis-usered" account - it's still there so it can be tracked against, but it cannot be used and doesn't count towards the licencing. I know there's a…

It's not changed, because it's currently doing the right thing. I think it's best to picking apart one of the solutions >Unrealistic suggestions were made ("Just get your Jira Admins to change the notification settings on a system wide basis!") .... The first one is not an option because the jira admins have much more…

Not really, on that amount of information. What have you got, or are doing differently to the installation guides? What is causing the "not able to install"?

That does not tell us anything, other than confirming that you are on Cloud. We don't have any access to, or knowledge of, that system. We're mostly simply other people using Atlassian systems of our own.

Burn up doesn't start from the included estimates at the beginning of the sprint. It starts at 0 and simply adds what is marked done as you go.

At a guess, I would say the difference is in the sub-tasks. I can't tell from the screenshots, but could you confirm that the two issues you mention are the "cards that do display data"? And then that they are issue-level cards and the missing ones are all sub-tasks?