Nic Brough -Adaptavist- Expert

Not quite, the process of creating the issue can be done by your process. (And if you don't put the reference field on the Jira "edit" screen, then your humans won't be able to change it and you could define what ever scheme you want). The problem is that whatever the process is generating and putting into Jira, you're…

You will also find that people think someone else was doing it, so you'll get issues dropped through processes. It's not a good idea, I've never seen it work in real life.

You can use relative numbers - "due = > -7d" for example, would find you everything with a due date from 7 days before the query was run. Run today, everything past Monday 7th. Run tomorrow, everything past Tuesday 8th, and so-on.

No, you don't downgrade it (you can't) I'm not sure why there's a 7.6 in the answer here. For your case, I would use 7.3.1 -> 7.13.latest -> 8.5.latest -> 8.12.latest

You will find the non-base-url proxy has the wrong url, so it will fail. All links given out by Jira will be for the base-url and you'll have problems authenticating the other one, gadgets and reports may fail, people will be directed to the base url unexpectedly, and so-on. I would remove your second proxy, it's not going…

A migration is about moving from one database to another. Either from one machine to another or from one type of database to another. Going from Confluence 6.x to 7.x is absolutely not a migration, it is an upgrade.

Yes, the docs Mikael Sandberg gave in his answer contain examples and tutorials

No, I understood the question - you wanted to add closed items to a board, which is explicitly not what they are for.

No, you'd have to change your process such that you stop thinking done things are done and have no idea of what needs doing. If I were you, I would stop the already broken process of switching between Scrum and Kanban. Decide on a single way to work and stick with it.

The answer is already given above - it's total nonsense to see done issues in a backlog. The definition of a backlog is "stuff that needs attention", which explicitly means "not seeing stuff that does not need attention"

Jira priorities are text, not numbers. If you want to change the available options, talk to your admins, they can add, remove and rename them.

Stop reading the database. It's slow, clunky, painful, subject to change and really really really the single worst way to look at Jira data. As for your joins - no, you're missing another 30-40 you need to read a simple issue, and when an issue has a complex config, you're missing a huge pile more. Please, stop.

You'll need to read the log to find out what is wrong.

No, you did not. This error message tells you that it cannot find a class you specified in your command. The documentation does not specify an extraneous class, it has a pipe to a file. You seem to have dropped the "and pipe output to" in favour of specifying a class that does not exist.

Why are you not running the command as given in the docs?

To do that, you should have a person decide that an issue is cancelled and move it into the cancelled status, which you have mapped into a "done" column on the board. This will feed up into Jira Align automatically, there's no automation needed, you just need to get the process mapped and executed properly.

Do you mean driver path or connection string? What documentation are you reading that tells you to do this?

This is not something you should be automating like this. "Cancelling" an issue is something a human should always be checking and doing if it is appropriate, not just doing it because something else is done. Especially when it's done at scale - the only time you don't need a human to check it is when you're cancelling the…

This will usually be down to network errors between you and the Cloud server your site is on. We can't tell you why this happens without more information. Could you explain what the errors are when you try to download jira software? Again, we're a bit stuck without an actual error message, or the details behind it.

You will need to write an app that provides a new type of field, not one that overrides anything - start at https://developer.atlassian.com/server/jira/platform/getting-started/

Issues are the heart of Jira and everything in the software is about tracking them. There simply isn't an app that is completely independent of issues for Jira. The closest I can get is "Advanced Roadmaps" which at least allows for lots of "we don't yet know how big X is" when you use it to plan things.

So, I'm afraid I don't have much of any direct use here, but I did want to say that what you're asking for should be achievable if you are happy to delve into some coding, and I think you'll find it is not as complex as you might imagine. That's based on some old experience (8 years ago) where I was asked to knock up…

The fields available and their mandatory/optional status is tied to the issue type. So the simple answer here is "yes" - the choice of issue type can control all the field behaviours (with the exception of summary - that has to be entered on every issue)

No, 8.2.0 will only get fixes in 8.2.1, 8.2.2, 8.2.3 and so-on. Once 8.3 is released, those point releases will stop, if you want a fix for something broken in 8.2.x, you'll need to go to 8.3.x or higher. On a long term support version such as 8.5.0, you'll find the point releases continue until the end of the life of that…

Latest becomes unsupported more quickly that the LTS versions, and will not get upgrades or patches. Imagine that, to pick a random version, you are on Jira 8.2.x. If you find a bug or a security problem, the fix will be to upgrade to 8.3 or above. On a long-term-support version, patches and upgrades will continue to be…

This still has the context problem described above, and adds the problem that your rank is obsolete (and hence often wrong) as soon as you've downloaded it.

Do you have a resolution of "unresolved" on the list of possible resolutions when you go to admin -> issues -> resolutions?

What apps have you installed that might be doing this?

No, they're more like "rough order of magnitude" estimates than actual sizing. I take an XL t-shirt most of the time, but while looking at me and thinking "maybe L, probably XL" and that being good enough for getting a t-shirt, it's not as accurate as the 41.5" estimate that a tailor would gather for a fitted suit.

You'll need to provide a standard connection string for the database driver.