Damage when bulk changing fixVersion in JIRA

Everyone: note that doing bulk changes in JIRA for the TRUNK project where you change the fixVersion is dangerous!

Specifically, this use case will not do what you want, and will destroy data:

  1. search in JIRA for tickets with fixVersion X
  2. do a bulk change, and set fixVersion to Y

Because it’s likely that some of the tickets you found in step 1 have multiple fixVersions, not just X. And step 2 overwrites all of them.

@burke check out the change yu made on 14-Sept here: https://issues.openmrs.org/browse/TRUNK-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel I’m afraid this happened to a bunch of tickets, and we’re going to have to fix this. (@michael, is there a magic automatic way to revert things like this?)

I am not aware of any easy way to even programmatically detect previous versions of values. It might be possible with some advanced queries at the database level, but those would surely not be supported by Atlassian and could cause issues given the complex schema of JIRA.

I would imagine that when performing a bulk change based on a fixVersion, the jira query should be such that it excludes anything with more than one fixVersion.

1 Like

Ugh.

I was playing with a JIRA API Groovy script for the purpose of finding tickets that had a specific label recently added… it looks like I now have another reason for it. :confounded:

1 Like

Just to be clear, what we need is a tool to move issues from one fixVersion to another.

I wonder if there’s a plugin for this.

Also, @michael, @burke, any idea how we can find all tickets that were modified within a couple minutes of Burke’s bulk update, so we can see what needs to be manually cleaned up?

I’m on it. I’ve already located 69 issues that were “Burked” and not yet addressed/fixed by @maany & @dkayiwa (Platform 2.0 issues with any history of a fixVersion nullified by me that hasn’t made it back into its fixVersions). I’m now working on automatically fixing them.

If there isn’t a plugin, assuming I successfully un-Burke the 69 issues, I should at least have a Groovy script we could use to change one fixVersion without changing the others.

1 Like

In case it’s useful, JQL documentation suggests something like the following is possible:

updatedDate < "2012/01/01 00:00" AND updatedDate > "2011/11/01 00:00"

Also FYI, “updatedDate” in JIRA is only the most recent date changed.

The damage should be repaired now. I processed all issues that met these criteria:

  • fixVersion = 2.0.0
  • No other fixVersions (Mayank & Daniel had manually restored fixVersions for most of the issues when reviewing them)
  • One or more fixVersions (other than 1.12.0) removed by me

Of 306 issues, there were only ~60 that met the above criteria. My script restored the fixVersions that were mistakenly removed by my bulk change.

Issues fixed:

TRUNK-2224, TRUNK-2894, TRUNK-2999, TRUNK-3064, TRUNK-3625, TRUNK-3654, TRUNK-3771, TRUNK-3888, TRUNK-3912, TRUNK-3937, TRUNK-3951, TRUNK-3963, TRUNK-4109, TRUNK-4208, TRUNK-4251, TRUNK-4260, TRUNK-4261, TRUNK-4267, TRUNK-4285, TRUNK-4297, TRUNK-4301, TRUNK-4315, TRUNK-4338, TRUNK-4350, TRUNK-4380, TRUNK-4385, TRUNK-4406, TRUNK-4411, TRUNK-4415, TRUNK-4416, TRUNK-4417, TRUNK-4418, TRUNK-4419, TRUNK-4438, TRUNK-4440, TRUNK-4445, TRUNK-4459, TRUNK-4482, TRUNK-4485, TRUNK-4492, TRUNK-4495, TRUNK-4509, TRUNK-4514, TRUNK-4520, TRUNK-4529, TRUNK-4531, TRUNK-4534, TRUNK-4545, TRUNK-4562, TRUNK-4563, TRUNK-4569, TRUNK-4573, TRUNK-4576, TRUNK-4578, TRUNK-4580, TRUNK-4605, TRUNK-4618, TRUNK-4635, TRUNK-4636, TRUNK-4646

It wouldn’t be hard to adapt the script to manually bulk-swap one fixVersion to another properly (without disturbing other fixVersions) in the future.

1 Like

I don’t think it will be possible to recover from that :confused:

I believe there’s no versioning for that field, the history/log/audit is a possibility, but not a very easy one.

Usually I find better to rename/delete versions instead of changing FixVersion field.

1 Like