Nic Brough -Adaptavist- Expert

Advanced Roadmaps don't really work with team-managed projects yet, I would stick to company-managed ones for now.

You do not. Your system was shut down and the data removed soon after your subscription ended. It will have been backed up, but I don't know how long an ended system is retained for in the backup cycles. You could raise a support request with Atlassian, but you may have to subscribe to a new system to provide a place for…

There's a simple "cheat" for this - the sprint field (it's not quite a field, but close enough for most purposes) is a multiple-select field. If an issue has been in any *active* sprint, the sprint field for the issue contains a record of that. So, while it sounds like a search for this could be quite hard, you can answer…

So grumpy-me wants to point out that "project group" is meaningless. You just mean "project". It's pedantic, and it's "jira speak", but it is important to be clear on what we're talking about, otherwise we'll go in the wrong direction. A project in Jira is a container for a pile of issues, it's not a field. To change an…

A post-function is a set of actions taken when an issue has a transition confirms. It has nothing to do with the view of an issue, and it's too late in the process of transitioning to ask the human for anything. It's absolutely not "adding a panel to a post-function". But "adding a display dependent on data that a…

How are you doing this "assign to project group"? And where?

No, that's the opposite of what I said. What I said was that you can use a property on a transition. More specifically, you can use a transition property on a transition. You were trying to use a step/status property on a transition. That will have no effect because a step/status property is not a transition property.

I don't think it's quite right either. A self-organised team, from the outside, no, doesn't technically need an assignee on an issue. You could argue "the whole team is responsible", and that's fine for well-functioning self-organised teams. Internally, though, if a team is not working perfectly, how do you stop "I thought…

The only "back out solution" I can see is even more complex - you'd need to write "this failed" on to the issue somewhere, then write a listener to catch every change and look for the flag after the fact, then work out how to transition back to the previous state and overwrite all the other changes made during the…

Ok, so my quick typing of "infowiki" into a global search engine turned up a small non-Confluence-based wiki, and I had no way to know if that was the one you are talking about. Thank you for clarifying - I think your last comment tells me that "We use Confluence and we call it InfoWiki in our organisation" (Same way that…

Because that bypasses some of the checks that your new filter isn't junk. The syntax check is basic and only checks syntax. Running the filter allows you to check that it actually does what you are expecting and that it doesn't break horribly despite the syntax being ok. You'd be horrified how many people used to post "my…

>on-premises non-clustered server, what's the recommended specs of the server hardware? You've answered your own question here - a non-clustered server is simply a server. So you can use the recommendation for a server product straight off Atlassian's sizing pages. It gets better - they also recommend that when you are…

The default link definitions are intended to be used in sentences, and should not need any explanation (to an English speaker anyway). Try adding issues to them: ABC-123 relates to DEF-456 ABC-123 is blocked by DEF-456 DEF-456 blocks ABC-123 and so-on You can define your own link types, and if you do, my advice would be to…

Depends on the app you use to implement them! With Advanced Roadmaps, they are Concepts more than issue types.

I do not know. You have not told us what "infowiki" is. A web search leads me to what looks like a tiny wiki, written in php, but not announcing what the underlying software is. If it is a wiki, then yes, it does a lot of stuff the same as Confluence, as they're both wikis, but without knowing what software it is, or how…

Plain Jira's hierarchy is Issue (Story) -> Sub-task If you add Software, it gives you Epic -> Issue (Story) -> Sub-task Advanced Roadmaps (nee Portfolio) adds themes and initiatives above that. Jira Align gives you a hierarchy right the way up through SAFe (and other agile at scale frameworks). Then there are non-Atlassian…

See https://confluence.atlassian.com/bitbucketserver0511/install-or-upgrade-bitbucket-server/supported-platforms - it covers that (and a load of other follow up questions you may have)

I'm afraid we are stuck here. Without knowing what a "Fusion account" has to do with Jira, there's nothing we can do for you. Best I can do is suggest you ask your Fusion admins and co-workers what Fusion's relationship with Jira is.

Ok, yes, you can block work logging on completed issues, and you've got the right property. But it is a step (status) property and not a transition one. Add it to the status that you want to stop people logging against, and it will do what you want. I am sorry you see this as nit picking, but as with all terminology, there…

Could you explain what you mean by "infowiki" here? What has it got to do with Confluence?

The obvious route is "space export, space import" If you can gather your stuff together into one space, that means you can do it in one hit. In that space, go to space-admin -> content -> export and select "xml export". That gives you a file that you can give to a Confluence admin (not a space admin or ordinary user) on…

One thing I have not said yet that I really should do - I really do not feel this is in the slightest bit intuitive in Jira. Nowhere do I see it explained in the UI that "unmapped status do things you don't expect" and the docs are very light on it, you have to read way too much to find it. If you do find it, you'll see…

I think it's better to "stop people breaking stuff for the vast majority of usage" and accept that "a tiny handful of users have a minor inconvenience of having to look in two fields on the rare time it matters" is a better compromise. "Single point of responsibility for an issue" is actually something that crops up more…

>Every single one of the tickets we add to the backlog are expected to be scheduled into a sprint. They're all sprintable, they are simply "pre-sprint". No cat here. Just two separate processes (stages) of work that are needed on the same set of items (tickets), performed by different people. Two stages, one set of items.…

Because, as I said earlier, it does not exist in Cloud. 

Ok, that makes sense. You said: "... it automatically (after some time) changed to > first follow up sent > closed. Now after an issue gets a status resolved it doesn't change. " That suggests to me that you had a service that ran regularly, checked for issues that had been in a "first follow up sent" status for a while…

Go to Admin -> Product access. This will show you the groups that grant access to the various applications, so you know what groups to add/remove people from. For example, one of my sites has the default, and the groups * jira-servicedesk-users * jira-software-users * confluence-users Do what they suggest - a person in…

That's the one tiny edge-case where it has a valid use case. But the nature of pair programming makes it pretty much useless - it doesn't matter which one of the pair it is assigned to, and if you really desperately need to record both, add a select list for "other person" I don't think anyone would want to open up…

You will need to visit the associated Jira and reset password from there (have a look in the "hamburger" menu at the very top left - that's usually a list of other systems you might use alongside Confluence

The iterative object here should be an issue in its own right, so l.getKey() would be a starting point. You can probably see how to get the rest of the issue information.