Nic Brough -Adaptavist- Expert

Ok, so nothing to do with REST. I would do this with a post-function. You should NEVER try to make changes to anything in a validator - a validator is part-way through a process and should only ever say "yes, this is ok", or "no, your data does not fit, so we will not be proceeding with the transition". If you were to put…

Possible, yes, but you're going to need to do a lot of coding to do it. Jira's move functionality does a lot of work. You don't just move an issue, you have to check the entire configuration of the current issue type against that of the target project and type, then handle any incompatibilities. Generally, in Jira, you…

Ah, that was my exception. In this case, you don't actually care who the assignee is. As soon as they stop working together, the problem can happen again.

Have a look at "issue security schemes" - these allow you to select a "level" for an issue, and only the people named in that level can see it.

Yes, plenty of times. You have to check each patch you want to apply will not break your version of Confluence (it's very rare that they will), and update Confluence to patch that up.

What do you mean "it stacks here"? What errors are you getting at this point? If it's running, then you will have a log file in <jira home>/logs to read as well.

You will need to restructure pages so that the pages you want to share are no longer beneath restricted pages. The reason it is not possible is because you absolutely do not want a complete free-for-all on visibility. If a page is restricted, it is restricted for a reason, and you always want to inherit that in pages below…

Actually, that won't work. Developer licences for apps only work when there is a developer licence running the platform. I'm afraid you will need to talk to Atlassian to get any way around this. I can't think of one other than going back up to a tier that has dev licences.

A lot of Jira users create issues as place-holders for time logs. Some do them in overhead projects, others keep them in the team's project. Some use single issues for everyone's time (I do not recommend that), some split them right the way down to individual entries. So, for example, we have project called "holiday". We…

I've seen systems with thousands of versions of pages and even tens of thousands (the page worked fine, but the rogue script that was updating it was not so good) You should not be worried about running out of versions.

Oh, and you'll need another copy of the database

You would need to take a copy of the existing installation over to where you want to upgrade, remembering to change the file that points to the home directory, pointing it to the copy. You can then upgrade either of them (although if you want to run both at the same time, you'll also need to change the running port for one…

Ok, I suspect you have messed up permissions. You should not add jira into the root group (although you can, it's recommended not to). What you should do now is * Stop Jira * Correct the ownership of the files and directories in the installation and home directories, making them all owned by jira and with complete access…

No. Estimates do not go on sub-tasks and even if you decided to do them (and code for rolling up as Jira won't do it), they will not count in burn-down. Burn down measures how you are doing compared to what you committed to. You commit to delivering stories, not sub-tasks.

No, customers do not count towards your licences at all.

You'll need to be in the groups you want to share this with.

That means Jira isn't even starting. So you'll need to read the Tomcat log to find out why it's not starting Jira. /jira/logs/catalina.out is the next one to read, it should tell you why it can't start Jira

You have set some fields as mandatory. You'll need to add them to the create screen, or make them optional.

You would need to use non-dynamic JQL. So each swimlane would be a story, but you'd have to say * Row 1: Production issues * Row 2: Story = ABC-1 * Row 3: Story = ABC-2 * and so-on

You're in the right place, but we can't answer your question. You have chosen to use Cloud, where you buy a service from Atlassian. There are some plans to give Enterprise Cloud customers a slightly more fixed platform, but at the moment, and for most of us, you get whatever they are prepared to support, installed when…

I don't know how to say this differently. Portfolio for Jira is installed by Atlassian and is maintained at "the latest available version Atlassian wants to support" on Cloud Therefore, it will be ugraded when they have a new version ready to be installed on Cloud.

Are you a member of the group you are trying to add?

Start with <Jira home>/logs/atlassian-jira.log - this is the application log and will usually tell you what is going wrong during start up.

You already have the latest version. Again, Portfolio for Jira is installed by Atlassian and is maintained at "the latest available version Atlassian wants to support" on Cloud

You can't mix types of swimlane like that I'm afraid. It's a single setting.

Log in as an administrator and go to admin -> issues -> custom fields, you should find an "add" option there.

So that tells me that although Tomcat is running, Jira is not. At least not on that port. You'll need to check which port it is supposed to be running on and then, if it is 8080, read the logs to see why it has not started up.

You do not. Multiple assignees do not work in real life, so Jira does not implement it. You will need to add a custom field if you want to name a subordinate user as someone else who is not the single owner.

That tells us that there is something blocking access to your system on that port. It's almost certainly a firewall.

Sorry, get what working?