Nic Brough -Adaptavist- Expert

Jira Cloud is a subscription service, there is nothing to download or install. If you want to run Jira on your own servers (whether your own, or Cloud servers), you'll need to be installing Jira Data Center.

No, you've missed one of the two main points: Issues do not move between boards. >But since the Sprint is over (Completed Sprint) the Issues have to be presented in the Sprint Report, and it should not matter if I move them after i Complete the Sprint itself? Of course it matters, if you're deselecting an issue from a…

Ok, thanks for testing/clarifying all of that. The only other thing I can think of is that the epic link field is not even valid for the issues you are trying to import. This will only happen if you've removed the field from the project somehow (as a locked field, you should not be able to do this on Cloud, although you…

There's a lot of complexity in your example that I am not sure is actually a problem or relevant, and it's not written in Confluence-speak, which is confusing to me (Confluence doesn't have "category" as you have used it in the question so I'm not even sure what you mean). So I'm going to take one bit of your example page…

I think you already understand the "side effects" - people either get to see things or they do not. I'm not sure what you want from "real world examples". You can imagine that I've worked with a lot of Confluence (and other information systems) and seen many different needs for sharing, but the solution has always been…

Welcome to the Community! I think there may be a basic misunderstanding of how Jira works here. You say "the issues in Sprint that are in the last right column are moved to Release Kanban Board" as the main symptom of the problem, but this is not actually an accurate description. Boards are not containers for issues, they…

> I do not want them to be the same Ok, then you are going to have to use "move" when you want to change the issue type, as the error message states.

I'm afraid they do not yet work on those screens.

If you're geting a private key mismatch, then either you have not applied the key and certificate correctly, or they do not match for some reason. You will probably have to ask the people who gave them to you.

Oh, ok, then I've mislead you. If things need separate versioning, then it should probably be "project by item that needs its own version scheme". But that doesn't stop you going on to what I'd do next - build boards by team. A team might be drawing work from one or many projects, and may well be single or multiple…

Welcome to the Community! Most of the test management apps for Jira I know of provide a range of gadgets and reports for this sort of thing. But you've not mentioned which one you are using (or how you've got everything set up for Jira to handle test plans, or even if it's a remote system), so there's not a lot we can do…

I don't know how else to say "the source and target types are not configured the same" - it means exactly what it says. To "fix" this, configure the two issue types to work the same way.

This definitely is a job for a post-function (or automation), but you'll need an app to do it. A post-function is more than capable of running on the "move issue to done" transition where you ask the user to choose a resolution, take a look at what they choose, and then setting a (presumably future) date on it. Also…

Start with a sample of the "done" issues in the project. Check their histories, and how their status got changed to "done"

So, to simplify a bit, use scenario 2 only (drop the Epic issue type line for now) and then remove the column "epic name" completely. Next, check what type of issue "task" is - a lot of people have that type as a sub-task type. If it is a sub-task type, remove that from the import as well. Now, when you try to import this…

It works ok for me in the issue view, but message fields are not intended for requests. Are you looking at the requests?

Er, yes. You say "All the work flow, field config screen and screen schemes are independent" - that's the whole point of the message. It's failing because the source issue type and the target issue type are not configured identically. It's telling you that you can't edit unless the field configuration and workflows are the…

Ok, so this is not going to do what you think it is. Rather than try to fix your scripts, I would like to check if you actually want to do this! Components are project items, they do not go across projects. The scripts you've got are broadly trying to duplicate, not share. Components in different projects are different and…

It's never going to. "Issue edit" is a permission, which varies by user, it is not an attribute of an individual issue. No-one is suggesting you try to edit each individual, what we're suggesting is that you need to understand your data. * If you have many projects in the data set, use that to narrow down which ones you…

I usually check projects first (as edit permissions are granted by project permissions) - if your search returns three projects, then check you have edit in those projects. If you do, then it's almost certainly what @Jack Brickey said - there's a workflow property for "do not allow edit of issues when they are…

Does your import contain only issue level issue types? (No Epics or sub-task types)

If forcing a re-index (which you can do for a single issue, without admin rights, by simply commenting or editing it - put an extra . in the description or something) does not work, then you will need to debug it yourself: * What dashboard gadget and what does its config say? * What is the filter the gadget is using to…

It depends on how you want to work together, and what part of the config matters most to your people and reporting. In this case, the things to consider are all about project configuration: * Projects have distinct components * Projects have distinct versions * Projects have permissions for users The two "distinct" ones…

Have you tried out the Jira macro in Confluence?

There are plans for other types of project to support forms, and extensions to Automation that will allow you to effectively read a form and pull data out into issues, but you are a bit stuck at the moment. However, there's a bit more of a fundamental problem here - when you move an issue out of a Service Management…

I can't help you unless you can tell me how the results you want to report on are being stored in Jira - what is the data and where is it kept? ("pushing results" tells me nothing more than something is adding data into Jira)

The comments are not placed in the field tabs, they are in their own section in the display, outside the field tabs. So there's nothing to remove from the tabs.

Have you tested each individual clause, and partial combinations? How many Epics do the following return?: * Project = XXX * Component = ABC or Team = 111 * Issuetype in (Epic)

Again, why are you going to Jira.com when you know it's not where you want to go? And bookmarks absolutely are "quick access records". That's one of the things that they are intended for - it's a definition of "marking something to come back to later"

My use is intermittent (I'm a searcher, a do-er and a talker, not much of a writer), but every time I need to write something, I want to stay in it and never have to think about Word or other document editors ever again.