Nic Brough -Adaptavist- Expert

Have you tried a search for the issues? Issues don't go anywhere just because they are done at the end of a sprint and hence don't appear in the backlog or active board. They just don't need to be displayed there any more, they're still in the projects, just closed.

Next-gen (team-managed) projects do not have share-able workflows, so no, there's no way to do either of those yet.

Atlassian does not do general access by restriction, it does it permissively. That is you say "this person can", rather than "this person can not". To do this, the applications all have a simple rule - they have a list of user groups that say "a person in this group is a user of this application". By default, the…

Check if the option is in the "other things you can do" menu - the ... to the right of the options.

I do not think Bigpicture implements project level access, as the whole point of it is to go across projects! So, no, there's no way to disable it for a project. 

You do not add fields to boards, do you mean you have added a field to a project and/or issue type (or globally)? Only certain types of field can be used in the gadget you mention, so we need to know what type of field you have added. As for it not appearing in JQL, my guess would be that you deselected the default…

A multi-select list would be best for this, but it does mean that you would need an admin to maintain the list of available IDs.

Go to the issue search and run "assignee = currentuser()" - this will give you a list, but you can save the search and use it in dashboards and reports. The dashboards have lots of gadgets available and a lot of them ask for saved filters like that to work with. In fact, there's even a dashboard gadget you can add without…

>these 2 people will only comment on the tasks, browse project, and will only review tasks A Jira user (that you have to provide a licence for) is, by definition, anyone who can log into the system and use it. Exactly what they can or cannot do while logged in is not what determines if they are a user. If they can log in,…

I would guess that function was being provided by an app you had on your Server version. You will need to look for an equivalent for Cloud - the original vendor may have one, so start there, but if they don't, you'll need to look through the rest of the marketplace.

Customers do not see issue screens, they use the request screens defined by the portals in project settings -> request type -> <request>

>It has status done but not considered done until it's mapped to the last column on board. And it can't be mapped to the last column on the board "Ready for UAT", which is the status of its parent issue, because there's no such status name in the subtasks' workflow. That is completely wrong. I think you are confusing…

You cannot complete an issue if it has sub-tasks that are not done. An issue of any type can only be done if it is on the board and in the last column. >So, what's the use of having subtasks in the board filter if we are not going to put them in the last column? There isn't any use, because you are creating a paradox -…

The issues have to be in the very last column of the board (the name of the column does not matter). If the main issue is not in the last column, then no, it is not "done" and will go over into the next sprint, or to backlog. But you will be able to complete your sprint.

No, they're not "inherently in the last column", for several reasons, the two main ones being: * One of the reasons for using sub-tasks is having bits of a story that can be in different status (or even using different workflows to the parent). Simple example - Story = "write web-app", sub-task 1 "front end", sub-task 2,…

Your app would need to know the email to send from, and be able to generate email apparently from that address. That's not a Jira function or setting, Jira isn't creating the emails. If you set the sender in your app, Jira will know that the sender is the customer. I'm not sure what it does with reporter, as the reporter…

I would guess that your "local_db" database connection pool is set up to point to the wrong database. It's either going to one that isn't responding or its empty. Either way, it's not connecting to your Jira database.

I agree - most places have uses for both types of project and it's usually sub-optimal to have to have two different systems doing the same thing for the same people when one could be doing it. Having the 2 types of project force the use of two systems would be ridiculous, having them both available in one place definitely…

That's fine, it's good to talk with customers, but that suggests that you aren't really treating the issues as service requests any more, they've become issues that need managing in a more development style way. You can still create a board and rank the issues in there, just be aware that on Cloud, boards have to be…

You will need to get in touch with Atlassian support over at https://support.atlassian.com - make sure to select "billing, payments and pricing" in the first selection box, to get it routed to the right people. ---- google translate says: https://support.atlassian.com에서 Atlassian 지원팀에 연락해야합니다. 첫 번째 선택 상자에서 "청구, 결제 및 가격…

Yes, that's the whole point of the Epic status field - it applies to the Epic. It's not for other issue types. They display it in some places, but the value is taken from the Epic they are linked to. The field is locked to prevent you making the mistake of putting it on other issue types - if you could, you could put…

We need to be clear here - do you mean "delete issue" or "remove issue from the list"? If it is deleting an issue, then you should look at the project permission scheme - it has a line in it for "delete issue" and anyone matching that rule will be able to destroy all the issues in that project I recommend that you never…

You'd be far better off using the API to get a list of fields, it's far easier to work with the fields directly in a script than have to look them up every time you want to get one from a name. But to answer the question - you are connecting to the wrong database in prod, or it's of a type that is case-sensitive and the…

Quick filters are for drilling down into a board, they do not add to it. Your board filter will need to draw in the issues you want to see on the board. Now, the fact you've got sub-tasks excluded from the board does not mean you can't select for their parent issues, just that you won't see sub-tasks on it. But, there is…

That doesn't necessarily mean there are no conditions on it - you'll need to check that directly. Also, check that the user has "transition issues" permission in the permission scheme.

Confluence does this, but I've not seen Jira do it. Of course, it's not the wrong thing to do - Jira is the trademark and the correct name for it, JIRA is now incorrect, and you shouldn't be using it.

> When I make a subtask in a issue1 (project A ), I want to automatically copy(clone) the clone-subtask in clone-issue 1(project B). Ok, then your automation or script should be triggered by "issue create" > Of course the clone-subtask should have "clone-issue 1(project B)" as a parent. How are you identifying the new…

Behind the board, there is a workflow, which is made up of status (which sort the issues into the columns on your board), and transitions that allow you move an issue from one status to another. The message you're seeing is about the transitions - your drag is not really "moving columns", it's looking for a transition that…

Your Site admin should be able to shut it down, but it is a global thing, I suspect you've some of your people ask for it, so it got added, but that means everyone on the site gets to see it.

You've not said why you think you can't set it (can't find the option, can't see it where it should be, large penguin sitting on your keyboard...), so here's a brief overview to cover most of the reasons you might fail: To enable anonymous access, you need to enable it * Globally - Admin -> global permissions -> anonymous…