nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Export issue scheme information

rob_sked

We are looking at doing a well overdue upgrade of our v3 JIRA to v6, and I've been tasked with "merging" the issue type structure into a single schema.

I want to know if there was a way to export this information out of JIRA either through the admin backend, or directly from the SQL Database?

I'm essentially after a list of all issues types, the schema they belong to, and then which projects that is applied to.

Does anyone have any ideas?

Cheers,

Rob

Accepted answers

Nic Brough -Adaptavist-

I'd treat this merge as a separate task from the upgrade - you can do it before or after the upgrade with the same effect. (I'd be tempted to do it after, as JIRA 6 is a bit nippier than 3 so you won't be waiting around for it to do the updates for as long)

I'd also completely bin the idea of "a single scheme", unless you genuinely have an organisation that is using JIRA for the same reasons all the time. In most places that use JIRA, issue type schemes genuinely need to be very different. As a random example, your developers are happy with tasks, bugs, stories and epics at the top level. Your HR people don't even understand those, let alone have any use for them, they need newbie, leaver and question. Your operations people don't want stories or epics, they need to work with deployments and incidents.

On the flip side, yes you should simplify - your developers probably should be using one or two schemes across the board, not one for every project. Same for all the other users - if they're doing similar things, then yes one scheme for each purpose.

On the Admin GUI side, just look at the list of issue types. That shows you what schemes they are in, and then you can map that on to each project from the list of issue type schemes.

Or for the database, read issuetype, (oddly) fieldconfigscheme for the actual schemes, and then nodeassociation and project to see what schemes are with which projects

All comments

Nic Brough -Adaptavist-

Or for the database, read issuetype, (oddly) fieldconfigscheme for the actual schemes, and then nodeassociation and project to see what schemes are with which projects

rob_sked

Hi Nic,

Thanks for the reply. We're currently looking at a way to try and condense the number of schemes, as every time a project spins up, they create their own scheme and re-use the issue types.

Looking at the database just gives us an idea of how it all gels together.

Nic Brough -Adaptavist-

Yes, a lot of people are being quite annoyed by this direction to make every project have its own schemes. I suspect it's part of the move towards delegating more of the admin that Atlassian would probably like to do (i.e. letting the users look after their own projects). But it's a bit of a pain for admins - most of us want users to say "I want a dev project" or "I want an ops project" and get a standardised consistent and *shared* setup.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration