Nic Brough -Adaptavist- Expert

Bother, that usually fixes it. Next culprit though - do any of the issues have sub-tasks that are not landing in the last column of the board?

This almost always means there's something structural wrong. I would read the log for anything that jumps out as a potential cause (but they are wordy and hard to read, so if you don't spot the cause straight away, don't worry, you have a lot of company - I still miss 75% of the underlying errors on the first pass after 15…

Ok, so you effectively have four fields called "Priority". At first glance, I was just going to write a longer version of: Try: (temporarily) rename all the custom fields to something distinctive like Priority-1, Priority-2 and Priority-3, then check what your field configurations, screens and error messages say. I suspect…

My best guess is that the description is on the "create" screen, but not the "edit" screen. If a field is not on "edit", then it can't be edited directly (you'll still be able to change it during transisions)

The project will revert to a plain Jira Core project. You'll have all the issues and be able to work with them, but all the request layer will disappear.

I don't think you understand what a backlog is for.

No, Jira is an issue tracker, not a source-control system. It tracks all the changes to issues, but the focus is on issues, not change, so there's no tagging of a "version" of an issue.

Do you have a custom field called "Priority"?

It's not quite shouted from the rooftops, but it supports any distribution of Linux that can run the required version of Java. For what it's worth, Atlassian test extensively on Ubuntu, but also CentOS (the non-commercial version of RHEL which is functionally so close to RHEL, you can almost consider them the same OS)

I'd look at the cascading select list, it can break your main list into logical groups (example might be "country -> region", so you'd list USA/States, UK/countries, regions or even counties, and so-on)

Sorry, this was poorly phrased. It was not intended as an attack. I was just pointing out that something is broken in your process.

As it was in 2013, there's nowhere to store when a custom field is created, let alone any code to store the data. Although there is now an audit log which does capture some admin actions. I can't remember if field adds are logged, but have a look for admin -> audit.

Could you give us the actual error you see when you try to delete? "predetermined site" is not a message I've seen from Atlassian site maintenance.

No, you're given plenty of time to get a backup, and lots of warnings before deletion.

Unless you can analyse what you updated for each issue and return it back to the way it was before, yes.

Sub-tasks are very much a part of their parent. You can see them on boards, as part of the parent. You won't see them in the backlog (because backlogs are for planning at a story level). But they won't appear on a board "as stories" because they're not stories, they're fragments of stories.

Importing workflows will change ids because the import is not a copy, it's a rebuild (it can't be a copy because the underlying data in the two systems may clash) There's nothing you can do abou this, orther than stop using the transition ids directly.

How much heap have you given Jira? Are you running two of them (One Jira and one Jira ServiceDesk, or have you installed Jira and added Service Desk as an application) How many projects do you have? When are you planning to move to a supported database?

Whatever the word is, point 1 and 3 still stand (point 2 almost certainly does) I would point your management here, you've got three long-standing, deeply experienced community leaders saying this is a bad thing to do. Any partner or consultant will tell you (and your management) the same. As the admin, you need to…

Please, I can't work with only half the answers

How are you encrypting the values?

You have a broken process. Moving issues between projects is for when a genuine mistake was made, or housekeeping. Also, move is not edit or update, it's not intended for updating an issue beyond the absolute minimum needed to make the data valid for the new configuration. Why are you moving the issues between projects?

It is still supported, and it is still free. You should probably ignore people who don't know what they're talking about and look for yourself.

I would tell your managers to stop wasting their time and yours. * You do not really want to render your Jira unsupported * Your issues are not all tasks * People who have used Jira before will have to learn that you've done something to change language to something less informative. Don't make extra work for them as well…

Git doesn't have "fork at", you get the same effect with just "git clone"

I understand that you want to separate or split the names of something, but Are you trying to split the names of components or versions? Why? You have not told us what you want to do with the split bits of the names. I can write you a couple of lines that will give you strings like "internet" "1.1.0", but what do you want…

It is what it says, you'll need to take your 6.14 backup, restore it to an empty 6.14 temporary server system, upgrade it to 7.4, then export it to xml, then you'll be able to import that into a Cloud system. It sounds like you've made a start on this, but you should not be messing with xml files, you should be looking at…

You cannot change the url yourself directly (you could buy the new one, export everything from the old, and import it into the new one, but that is a faff) You can raise a support request with Atlassian though (https://support.atlassian.com/contact ) and they will arrange to change it without export/import. You can only do…

You'll need to ask the space or system admins for CSIRO what has changed. We're not your admins, we're a community of people with an interest in Atlassian. Most of us don't know what you mean by CSIRO

Business projects are Core functions, and that doesn't add any custom fields.