Nic Brough -Adaptavist- Expert

Thank you for this, not only does it resonate with me, I've sent this url to a few people today and they've said that while it's bad to hear people are feeling this way, it's actually good to know people working in totally different circumstances and fields are with you. We're not alone.

Great. If you go via Adaptavist, it will probably get automatically thrown over to Brew when it is first read and if it doesn't, then I'll probably see it and throw it over at that point. It would probably be quicker to go directly to Brew though - https://brewdigital.uk/ - feel free to name-drop me or at least mention…

This is going to scream of advertising and yes it is. I usually avoid doing adverts for Adaptavist, but when I do, I apologise for it. One of the members of the Adaptavist family is a web-design company, and obviously works with Atlassian stuff, backed up by knowing that if they need help that goes down into the…

It's ok to do either, but I would recommend upgrade first, as later versions of Jira are easier to convert from Server to DC. (You can pretty much just apply a DC licence to your Server, and you have a DC install with only one node in the cluster)

The status colours are determined by the status category the status is in. The colours of the categories are hard coded, and there are only three categories - To do, in progress, and done (although you can leave a status without a category, but that is the same colour as to do.

You will need to give them access to your Jira via an account, and make sure that account has access to the board and issues.

It is, you are in the right place. I'm sorry, I've not seen any doc that explains the search algorithms.

>i know that's wrong but i was bringing it up as an inefficient way to handle dependency. There is no more efficient way to handle dependency >a dependency can have dependency and so forth. so where do you start? With the first one that doesn't have any >if you want the story to be independent then you have to have no…

Yes. As we've said above.

No, that's wrong. When you identify a dependency, you rank it higher than the things that it is blocking. You don't plan the whole project, you're just putting an order on two items.

You can add an issue type of "test" if you want, but it will still behave like any other issue type. Most people who do test tracking in Jira do indeed get an app to help them with it - they add functions appropriate for handling tests.

It is in the issue history, a tab in the view of an issue.

You say: "its not only the size of the story that dictate taking more than 1 sprint. its also the other dependencies such as another story" These are separate stories - if you have dependent tasks, then they should be in other stories and ranked higher than the original story. They should then be brought into a sprint and…

Try issuetype in (story, bug) and not ( issuetype = bug and my-custom-field = Xyz)

You can do this with web-fragments. See https://developer.atlassian.com/server/jira/platform/web-fragments-4227124/

You should NOT be doing this at all. Please do not **** up your Jira by using SQL to do anything with it. It's not just the sequence table now as well, you really need to not touch the database.

What do you mean by "templates"?

You can't do this at all. Sub-tasks are part of their parent, and hence not even considered to be part of a sprint. They go with their stories into a sprint, all together because they are a part of their parent. The concept of having sub-tasks in different sprints is simply wrong. The parent goes into a sprint and, because…

8.5 is, as it will keep getting security patches and updates until October 2021 because it is a "long term support" release. 8.5.8 has some security issues, you should upgrade to 8.5.9 - see https://confluence.atlassian.com/jirasoftware/issues-resolved-in-8-5-9-1027114896.html for the fixes

No, you can't do this. Physically doing it is a pain, as you'd have to extract the installation of one of them from its bundled Tomcat and rebuild it in the target one. Then you would need to rewrite it to cope with all the clashes of libraries ad shared usage of Tomcat functions. Even when Atlassian did have a…

I am not sure what you mean by "create a list for each user that these tickets will appear" If you mean you want a person to get a list of the issues in which they are named in this field, a filter of "Escalated to = <user>" or even "Escalated to = currentUser()" will do that.

There is a lot here to talk about, but I think there is a big question to ask, to try to avoid huge if/then essays. How do you want to work? Are your teams aiming to be "agile" or "waterfall"? Or something in-between? Or something else?

Thank you Andy, that's where I think I was heading, but I it would have taken some more steps for me to get there. So I'm glad you've jumped ahead to give us a better and faster answer.

No, you're not missing anything, other than what is going on in our heads which we have not explained out loud! This report is not in %, it's coded to show actual numbers, not proportions, on both Server and Cloud. So it's not quite what you asked for. I think @Larry Loughan and I are trying to get you as close as we can…

I did not see any pedantic points in your question, and it seemed like a perfectly good question, especially as I have never seen anything in Atlassian docs that attempts to explain any of the default status names. I know I did not quite answer the question directly, with a list of explanations, but I wanted to point out…

I think it depends on the relationship with the customer. If you have set the customer expectation is that responses will be dealt with quickly, then, yes, consider assigning it to another agent so that the issue doesn't languish and the customer doesn't get let down. In fact, the ideal thing to do is to adjust the issue…

Ok, but how have you included that in your workflow, and what do you mean by "send issue to the queue"?

Most of the status names are self-described to be fair. * Waiting for customer * Waiting for support * In progress * Cancelled * Resolved * Closed * Pending There's not a lot more to say about most of them, I'd say 5/7 are completely clear, and would only question Pending and the difference between Resolved and Closed. But…

Ok, that tells me your systems are picking a really bad font for the code macro. This sort of display happens when * Someone has set up css in Confluence that selects a bad font when renedering text in the way the code macro tries to * You have a theme that has css that selects a bad font for the code macro * Your machine…

Yes, you'll need to give them accounts in your Jira, then create boards for them.