Nic Brough -Adaptavist- Expert

I'm afraid not. Business boards don't have the powers of Software, and are unlikely to get them.

Please see the links to "configuring workflow schemes" given above

There is nothing else that would do this. We would need to see all the exact settings you have for permissions and conditions in your workflows, and if they're ok, there's no option but a support request with Atlassian.

Sub-tasks are linked to their Epics via their parent story. That's fine, but unfortunately, and annoyingly, Jira does not cascade this down to the sub-task when you're searching or reporting (same as versions and security level) On server, it's not too hard to patch over, there are apps that can expose the link from the…

If you had left the internal backups running, then there may be some xml files (zipped) in the <jira home>/exports directory. You can use those to restore your data (ideally into a supported database)

I suspect you're looking at the same sprint from both boards.

This is not strictly a Confluence error. My best guess is that your server is now using a version of Java that does not accept parameters that Confluence is trying to start with. Three simple commands to check this (I've assumed a Unix like system) * grep -H E "JAVA|JVM" <your confluence installation>/bin/* * java -version…

It has moved in the last 8 years... Can you confirm if you are on Server, or Cloud, and if Cloud, in a classic or Next-gen project?

No. There's a basic security point here - you should not be emailing people with information that they can not see. If someone can't see a Jira issue, then they should not get emails about it, that's a security breach, let alone a massive no-no under data protection. There are apps that let you bypass it, but you must…

You could read it from the database, but it's a long complicated job, and the data is in a format that you cannot just paste into a page, you'll need to deconstruct and reformat it completely. I'd recommend getting your local server working instead. That error probably just means broken permissions on the directories and…

Card colours are generated by filters that are set in the board settings. You'll need to use "configure board" and change the settings in the "card colour" tab.

Admin -> Custom fields -> Your custom message field -> Configure

To do point 1, you will need to write something that will * Work out a list of workflow schemes that are using the workflow * Work out a list of all the projects that have that scheme, and what issue types within those projects are associated with the workflow * Migrate the the issue types from the old workflow to your…

This means your Jira server cannot reach your mail server. Either you've given it the wrong server connection details, or the server is blocked by your network.

For the description you've given us, I would move it out of the current sprint and back into the backlog. It will change the scope, but you have a perfectly good explanation for why it's a change.

Look at the workflow for the issue, you will need to move it through the transitions that can take it back to "open". If you don't have a flow that allows that, then your administrators will need to change the workflow to add transitions that can be used to take it back.

Are the "done" status for the sub-tasks in the last column of the board?

No, you don't. That would break parts of Jira Software and some related apps.

No, I've never tried to do it that way because it's the wrong thing to do. The power and use of a labels field is that it can contain many labels. I would strongly recommend that you use a single-select field instead of trying to kludge the labels field. 

For sorting, click on the column headers in the issue navigator, use the drop-down in the project panels, or, if using a filter, add "order by <name of date field>" to the initial query Deleting tasks - don't. Do not allow this, or if you absolutely must, then only grant the permission to people who understand that…

I'm afraid all you can do is delete comments that are not critical to the issue. I don't believe the code in Jira is great for rendering large numbers of comments, as it does some repetitive stuff that could really be downloaded once and applied many times, but you'd lose some of the functionality in comments if you did…

There is only one other thing than conditions that could cause this, which is a very broken data set. Can you run the integrity checker for the workflow and status related inconsistencies? If this is the problem, it will list the issues you are not seeing the workflow on. If the problem is not this, then I'm afraid it has…

Ok, it now has a healthy pool, so we can rule that out, but now all I can suggest is that the database is being overwhelmed by something or the connection is failing over the network. Does the database server look healthy? No spikes in resource usage and no network slowdowns or outages?

I don't know, you have not told us how the smart commits have been configured. I'd want to start with where-ever they have been set up to see how they might not be appropriate any more.

There is only one sprint there, not two separate ones. If you rename something one board is looking at, it has to change in the other boards that are showing it, because there's only one thing there with one name.

You do not burn down on sub-tasks. Put the estimates on the stories - that what you are committing to do in a sprint and that's what butn down measures.

Do not share the home folder directly. The index and caching will fail if you put them on shared file systems. But, don't worry abou them - your "start, reindex, repoint" will create local versions. By all means, share the attachments and other folders with relatively static data. Or, go ahead and use rsync to replicate.…

Technically, you don't. There's no concept of "ticket category" in Jira Service Desk. I spoke about issue types as that's my best guess as to what you are thinging being translated into Jira - it's quite likely that your SR, Incidents, Changes and Problems are going to need different fields and processes, so it makes sense…

Jira issues all have a "type", which can be used as a structural thing - this means you can do things like have different fields and workflows (processes) for different types of issue. Jira service desk requests all map on to an issue, so for each customer request, there is a single issue behind it. Each type of request in…

So, I'm looking at a Cloud system with 18 transitions and a Server with 35. Both are showing fine, when the current user has "transition issue" permission. There's no "limit", there is something else wrong with it. So, let's look at the issues more closely now we've ruled out the obvious: * Is this happening for all issues…