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; } } }

Update on jira DB

Walid Djama

Hello,
We want to set up a jira archive instance. and switch issues from the archive to live and from live to archive.
For this we have designed a solution that requires an update in the database, specifically we want to update the ISSUENUM column (Not pkey, Not ID) in the JIRAISSUE table. we know that the updates in the database are outcast.
we did some tests, everything went well.
we wanted to ask if there is any risk in the long term ?
thank's
Best regards

Accepted answers

All comments

Nic Brough -Adaptavist-

Yes, corruption of your database is a significant risk, although the worst it will do is break the project where you do this.

I assume this is a one-off change to get you started though? Not something you do when Jira is running?

Walid Djama

What do you mean by break the project ?

Nic Brough -Adaptavist-

The project will stop allowing issue creation, you might not be able to search it, and you'll get errors displaying project reports and boards.

Nic Brough -Adaptavist-

What other SQL are you running as part of this update? I ask because you might do this safely, but your question doesn't mention the other things you must do if you're going to mess with the numbers, so I'm a bit paranoid (having had to rescue so many systems where someone touched the database)

Claudio Ombrella

I wonder what is the sense of archiving projects in your instance. What you are trying to do has more than technical implications:

Pay a second license of Jira.
Pay for plugins
Maintain 2 servers
Risk of messing up the data structure in the DB.

I don't know how many issues you have in your Jira system, but in my company our Jira instance has 2.1 million issues and when we archive we do it only by applying a permission schema as full read only.

I would love to get the rational here to be able to better help.

Andy Heinzer

I would tend to agree with @Nic Brough -Adaptavist- on this one as well. Making direct changes to SQL for Jira's database is fraught with complications that can easily cause Jira to break and not behave as expected.

If you are wanting to have two or more Jira instances and then control what issues are synced between the two instances, there already exists a number of different plugins to Jira that could help with that use case scenario. One of these is the Issue SYNC - Synchronization for Jira. That particular plugin will let you choose which issues/projects to sync between Jira instances. So perhaps that might be useful here as an alternative to manipulating SQL directly to achieve your end goal.

Walid Djama_r952cf

Hi,
Sorry for the long time.

just to know, i developed a plugin to restore the original keys of the issues by using the method "setNumber" which is in the library "com.atlassian.jira.issue.MutableIssue".

In the first time i saved the original keys into a custom field before importing issues in archive server.

there is some screenshot:

I remain available for more information.

Regards.

TIS Admin_paif4e

Hi Walid Djama,

I'm really interesting in your solution. Could you share more details with me ?

My use case: migrating projects from multiple Jira Cloud instances to a central Jira Cloud instance. I have to keep the history, so simple export/import doesn't work. Unfortunately, there were few next-gen projects, so according to Atlassian articles, I had to create new classic projects first, move the issues from next-gen to classic, otherwise no chance to make a backup and continue the migration. Obviously, it changed the ISSUENUM during the move process. Fortunately, I have a mapping of old ISSUENUM to new ISSUENUM, and I have a local Jira SERVER where I restored the Cloud backup and can manipulate the ISSUENUM before uploading to the destination Jira cloud.

Why restoring the ISSUENUM is so critical? Jira is not the only tool in the development process. e.g. Bitbucket is tightly integrated. The commits, pull requests, etc is using the issue key reference. In my particular case, wrong commits are displayed in the Issue Detail screen (it's based on the old issue keys), the issue keys in the pull requests (old) lost the reference too, so it's a showstopper for us.

Really appreciate your updates!

Nic Brough -Adaptavist-

Walid was doing bad things to a Server instance. You don't have access to do these bad things to Cloud systems.

TIS Admin_paif4e

Nic, with my full respect, please focus on the use case and respect others. Try to provide better option and move the ball forward instead of repeating this mantra. Believe me, I have been looking this issue from hundreds of views, I read the full story, having constant discussion with support and this is the final option to do. I believe Walid had a very good reason too to invest many time into his code as well.

The vendor doesn't have support for my use case. I cannot migrate projects between their cloud instances as-is, especially when I ate their candy and used the next-gen project.

If you read my post again then you will recognize I have a local Jira server where I have full control. This local Jira server is part of the Jira cloud migration process, especially when you need to migrate projects from multiple clouds to one.