Nic Brough -Adaptavist- Expert

Can you tell us if you are using one Cloud Jira (Both apps installed on one Jira) or two (One with Software, the other with Service Desk)?

Sub-tasks are part of an issue, you don't plan for them in a sprint. A sprint contains the list of items you are telling your product owner that you are going to do during the sprint - stories, issues and so-on. Sub-tasks are part of those items, not deliverables themselves. By planning item X into a sprint, you are saying…

Yup, 1259 votes is no interest, compared with a lot of other more useful stuff. Plus, the complexity of nested sub-tasks is hideous, both on the back end, and for your users.

Log in as an administrator and go to Admin -> Issues -> Priority. I would recommend renaming the existing values, not adding new ones and removing the old (add and remove will delete the current data from the issues. Renaming will preserve it) Note that priority is a global field - if you do this, you will be changing the…

The message you are getting here is telling you that your Cloud system has been disabled. It's nothing to do with the "project being blocked" - the whole system is inaccessible. You will need to pay for the service, then it will come back. Note that you only have a few weeks to pay before the system is deleted.

This is a seven-year-old question and things have changed. On this subject though, it has not really, when Jira spots a reference to an existing issue, it makes it a link.

Give it more memory and a faster processor. Cutting parts out of the package process means you won't get a valid working package - they're all needed.

What error message are you getting?

No, they're not. The customer and agent portals are the same thing. I suspect you are mixing up "screens" with "portals". The portal is the view a customer or agent sees when they are creating or looking at requests. Behind a request, there is an underlying Jira issue, which the customer does not see. The agent works with…

I am afraid the question is unclear. There is nothing I could describe as an "issue schema", and there is no such thing as a "subtask field", so the initial question needs to be explained to me. When you click on "create subtask", you should get the "create sub task" screen, which is for creating a subtask - it will be…

No, the UI remains consistent across projects.

There's no way to pull historical data out of the history for display on Cloud.

I would use "workflow properties" - you can override permissions by adding a flag to a status. One option is "comments permission = no", so when an issue is in a particular status, you can stop commenting. Another example is to prevent issue edit - if you use the Jira default built-in workflow, you will find you can't edit…

I can see that, but it's not what I would guess at for the meaning of "validate" here. Hence the request for more information, I don't think there's enough for us to judge much. (But your answer is a really good way to get the other information we might need out)

Absolutely. Your application will need code to show and read the highlight, and, when clicked, send the data to Jira over REST (after some form of authentication) I am aware that is a very general answer, but I do not have much more to work with past "process pokes Jira"

No, columns do not have any permission controls. Visibility is at a board level, you can either see a board or not. However, you could work with the underlying issues - if you set up an issue security scheme that hides issues when they are in the status in that column, the column could appear to be empty.

This is one of my big arguments against weakly typed languages - the laziness and guesswork leads us to silly errors like this (this is NOT the fault of the coder, it's the coding language failing the human). We gain ease of coding and prototyping, but lose way more time to worrying about conversions. Here, groovy is…

It doesn't happen, that's how Atlassian designed it.

You don't need to re-index Cloud, Atlassian does it for you when your system gets into a state where it might be needed

Embolding the words does not explain them. "manage input and output paths" is too vague to work with, as is "governance in workflows". Rather than use buzzword-like phrases, could you explain what you are trying to achieve? Think of it from the end-user point of view maybe? Explain what your Jira users should see and do.

If you use "applications links" between the two separate Jira installs, then you can use "link to another Jira system" - not as good as "link to issue in this jira", but better than "link to a url"

You will need to do some log analysis - look at how the logs behaved before your change and afterwards. The new stuff appearing in the log should point you towards what is now being logged that was not before.

You don't need to re-index Cloud, Atlassian does it for you when your system gets into a state where it might be needed.

I think we'll need to see screenshots that show an issue to be in the last column on the board, and yet appearing in the backlog

If you think you want to move a sub-task outside its parent so you can put it into a different sprint, then it isn't really a sub-task of the parent and should be converted to a story (with a link back to the previous parent probably)

That's because the DONE column is now the last on the board.

We would strongly recommend that the very next project you do is to migrate from the h2 database to one of the proper databases on the "supported platform" page for your version of Confluence. H2 databases don't scale well, and are only suitable for systems that you don't mind losing (dev/test/play) - the database can fail…

A virtual option would be great, but the real-life summit is a much richer and useful experience. Pre-arranged or even ad-hoc online get-togethers worked really well, but I missed the "going to find someone you want to talk to for some reason" part badly. Worse was the "not finding old friends" but that's something that…

Assuming by "locked", you are referring to the red "locked" you see on the list of custom fields, (if not, then please explain what you mean by "locked"?) Fields are locked to prevent incorrect configurations being applied to them. You can only unlock them by database fiddles on Server/DC installations. I think we need to…

Assuming by "locked", you are referring to the red "locked" you see on the list of custom fields, (if not, then please explain what you mean by "locked"?) Fields are locked to prevent incorrect configurations being applied to them. You can only unlock them by database fiddles on Server/DC installations. I think we need to…