Nic Brough -Adaptavist- Expert

I suspect that you're not using the data the filter is filtering for, so the filter has nothing to do. I would, however, check the documentation for the app you have added to provide these gadgets, that might tell you more.

That's correct, Epics are slightly different to other issue types, and the rule "scheme cannot have no issue types" does not count Epics (or sub-tasks, last time I looked), because such a scheme would mean you can't create issues in the project!

It is possible to rename Epic to something-else, and then create a new Epic issue type that looks the same. This breaks everything because the new Epic type is just an issue type, it does not have any of the functionality that the something-else still has. The Epic name field is hard coded to only appear on the one "true"…

With Scriptrunner (of course, as I'm an Adaptavist), there are a number of ways you can do this. You've not specified what the trigger is or how you know which issue to transition in A (I'd guess it should happen on a transition and the issue in B is linked to the issue in A with a "blocked" type link) Have a look…

This looks like you have no permission to transition the issue, or the workflow does not have transitions out of the current status. And you do not have admin rights for the issue.

Welcome to the Community! Issues do not "move between boards". A board is a view of a selection of issues, not a container for issues (projects are issue containers) To get an issue on a board, the board has to select for it. Look at the configuration of your board - there is a filter for it that tells the board what to…

It uses the date upon which the issue was resolved - when the resolution field changed from <empty> to <not empty> The gadget is not configurable, but you should look to your workflow to decide when an issue gets resolved (the obvious place is "on a transition from an open status to an ended one, such as your "finalized")

Excellent! Always worth asking here too. What is the error message you are seeing?

Welcome to the Community! You will need to ask your system owners or admins for access to that. We, the community, are not your admins, and have less access to your system than you do! (The admins might be active here, but they probably aren't looking for access requests!) 

Welcome to the community! This sounds like a bug report that should go to Atlassian over at https:support.atlassian.com/contact They will want to see the error that you have not given here as well as a description of your environment(version of confluence or that it is cloud, to start with)

It's at the Venetian this year

I know, it's a bit confusing, because there's an overlap in terminology. The hierarchy in Jira Software is Epic -> Issue -> Sub-task. All three of these layers are Jira issues in the sense of "a line in a database", but they behave differently in places. * An Issue does the basics - it is an item that represents something…

Please could you read my previous answer? We can't help you until you answer the questions in it.

This actually looks like you are not creating an Epic. In your "Show fields", note the option for the "Epic Link". This field cannot be filled for Epics, but can be shown in the field list. But if you were creating an Epic, then you should see "Epic Name" next to it, and when you are in the create window, you would see a…

Oh, and I should echo what @Dirk Ronsmans said - don't try to do it yourself yet, give it a couple of weeks, and keep an eye out for changes being deployed to your Cloud system.

Mapping the columns is the one I get wrong most often! I keep spending ages looking at the queries and "done" settings and completely forget to check mapping.

No, you can't "move issues to another board". Boards are not containers of issues, they select a set of them to work with (that applies to the backlog too - the backlog is another view of the issues the board is selecting for. To get issues into the Scrum backlog, make sure they are selected for by your board filter, check…

Indeed, I've seen it done and it's as clunky as heck. They ended up with one issue per knowledge base article with a load of unnecessary crud scattered around them because Jira doesn't support "issues as static docs"

Actually, to expand on what @John Funk said, yes, a "message field (for edit)" will work. This is because Jira doesn't really have several types of screens structurally, it's got on for "view" and one for "edit", and those tell the fields how to behave. If you look at the code, you'll find almost all of the fields have…

Edit the workflow and check out what post-functions and validators there are on that transition. One of them is broken, and you'll need to debug that.

This is very confused to me, why are you using swimlanes for what look like status? However, I can partly answer. Boards are not containers for issues or status. They are a visualisation of a set of selected issues, with columns representing groups of status (often only one status), which you map into the columns in the…

Welcome to the Community! It's quite a clumsy error message, but what it's telling you is that you have at least one issue-type scheme using the issue type which has no other issue types in it. You can't delete an issue type that would leave an issue-type-scheme empty. Go back to Admin -> Issue types and look at your issue…

It's the same as above, you will need to allow people to see both the dashboard and the projects and issues it is reporting on.

Welcome to the Community! This suggests that a post-function on the ready -> to-do transition has failed to do something and hence rolled the transition back. This can also happen if you had a validator or post-function on the transition that was provided by an app that you have disabled or removed.

My guess is that one of your inexperienced admins has put the resolution field on the edit screen. You need to get rid of that as soon as possible. The resolution field should never be put on a create or edit screen, only transition screens.

You do not. Sub-tasks are not sprint items, they don't go into sprints themselves. They can be thought of as being in a sprint only when the issue that they are a part of is in the sprint. What you are doing is not good practice and it certainly is not Scrum or Agile. It sounds like you should be raising bugs as sprint…

Welcome to the Community! Go look at the project's "permissions" - one of them is "who can delete issues in this project" and the best setting for it is "no-one". But I'd also let in admins who fully understand the consequences of issue delete (can take weeks to restore them in full, we always recommend you just close…

Welcome to the Community! You can run version reports, but a simple search for "affects version = xyz" will find all the issues with a version. Or, if you mean you want to see the version on an issue, you can look at the issue, the field (if filled) will be displayed there.

Yes, "browse" means "can read the issues in the project" in general. You have to have that, otherwise, you can't limit people to their own set of projects. That's what it is good for - controlling access to projects. >I don't want them to see other issues within this project, just the issue one is supposed to work on. You…

I suspect that you are going to find other customisations you have made that are going to be bigger blockers to moving to Cloud! But yes, I'm afraid there's nothing else you can do. I'd always recommend housekeeping and standardising your Jira and processes in general, but you really do need to do it before you migrate to…