Nic Brough -Adaptavist- Expert

Assuming you are using Jira at the story level, then your boards should be representing teams, with a single project underlying each one. You can therefore set permissions on the projects that say "only members of this team can edit the issues"

Ok, that's the "use a condition" answer. I've given it the wrong way around for you - you actually just want a condition on the "all" transition that says "developers only", which should be easy if your developers are all in a group or role in the project. Be aware that this will stop everyone except developers using it in…

I tend to reach for Sonar when this comes up, but I'd take a look at all the options - most of them, to be fair, are separate tools that integrate with Bitbucket to feed data back into it, rather than apps in Bitbucket itself. Have a look at https://marketplace.atlassian.com/search?query=coverage

No. The upgrade process wants the current home directory untouched, because it's going to be using it and upgrading the data in it. The Atlassian recommended upgrade path is now "Run the installer, tell it to upgrade, point it at the current installation and wait". This will clobber some of your settings though, so you'll…

You don't need to think about that on Cloud. Cloud is upgraded and plugins need to follow it. You may find a plugin stops working for a while because something structural has changed and the vendor has ignored the upcoming changes information they've been given and not upgraded it. But this is unlikely as the APIs vendors…

Burn down is done on the last column on the board. Status-category and resolution do not matter. Make sure the status you want to burn-down on are in the last column. Ideally, those status should also be green (the green status category), and in most cases, I would recommend setting the resolution as you go into one of…

JQL is for finding issues, not reporting on them. Reporting is the job of the report that reads and displays the issues. So, your query can be written in natural language as "Project = ABC and there has been time logged between these two dates". The time spent on an issue is all of the logged work. That's it, it doesn't do…

No, you don't put your scrum estimates on sub-tasks. They will be ignored by some places and then double-counted in others if you do sum them up (whether manually or automatically)

I can't find any. I'd still be questioning why you're trying to add so many fields in one portal.

We're not support, we don't have any access to the user systems. But even if we did, there is no "convert account", it is nothing to do with the account, it's the way authentication is done in the applications. And that is not going back to the old way it used to do it.

You can use Workflow Properties on each status (step) in the workflow to override the project permissions. Look for the jira.permission property.

Yes, you can. My Adaptavist Atlassian account can get into many separate Confluence Cloud systems. From a translator: はい、できます。 私のAdaptavist Atlassianアカウントは、多くの個別のConfluence Cloudシステムにアクセスできます。

You can't do this as described - a transition is an action, not a piece of data. Issues do not "have a transition", they undergo them when a person asks for them. Transitions are enabled via the workflow and may have conditions. This means that not only is it hard to extract a transition, it can change dependent on the…

Is what through a notification scheme? The notifications?

Ok, that may be down to the type of project, as the project type determines the first board created. What type of project are you looking at?

Do not put sprint estimates on sub-tasks. Scrum burn down is done on what you committed to do for your Product Owner at the beginning of the sprint. You don't commit to sub-tasks, you commit to items at the story level. Sub-tasks are a way for developers to break up a story for several reasons, but you don't commit to…

No, the notifications are done by project, not issue type.

You don't. The links shown in the navigator are all the valid links, there are no functions to arbitrarily hide them.

There's a delete option next to the files in the attachment area. You may need to talk to your administrators about getting the permission to delete attachments though.

It is quite likely that you have broken your installation now, when you tried replacing bits of it. I am not sure that any upgrade is going to work properly if you've now got a mix of old and new. I would be looking at going back to the backup you took before upgrading. Files that are "in use" mean exactly that, the files…

Have a look through https://confluence.atlassian.com/jirakb/understand-the-lexorank-managment-page-in-jira-server-779159218.html - there are a number of "repair the rank" actions in there you should try

For most people, you'll need to explain what the plist is. I have a feeling you might be better off asking this on a site that's about deploying things this way, rather than an Atlassian forum.

Core doesn't have kanban boards, it does project boards, where the columns are determined by the workflow.

Why have you configured your startup process to look in the wrong place for the user and startup.sh scripts?

This is not something support will do for you (and we're not support anyway, we're a community of end users who have less access to your system than you do) You'll need to find a way to read it and export it yourself. A big question here is "why?" though - what are you trying to achieve with this?

If you don't want them to have access to Jira, then you will need to do something outside Jira, apps and plugins aren't going to help you because they're in Jira. Create your form in whatever the most appropriate technology is for the system that they will be using, then code it to poke data into Jira as a service-account…

Start at https://developer.atlassian.com/cloud/confluence/macros/

You would need to make sure A and B have differences in their workflows or fields, then remove the "move" permission" from the users in that project.

You'll get this error when the Fisheye/Crucible server does not have access to the file, or the repository settings have been changed and the FeCru server has not been re-indexed.

Your network cannot resolve the address. You'll need to get your DNS fixed.