Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,264,552
Community Members
 
Community Events
164
Community Groups

How to migrate custom field values with groovy or not?

Hi!

Today I would like to share a possible way to migrate or merge a custom field during a periodical cleanup. 

Possible ways are built-in functionality of Scriptrunner or myGroovy, own code and own yet another alternative way for the complicated situation.

Also,you can follow with next typical steps of cleanup process:

  1. Detect the fields
  2. Create a ticket about merge plan 
  3. Detect the JQL, agile boards queries via database queries in tables searchrequest, add info into ticket
  4. Prepare the optimized the context in the comment of ticket
  5. Notify project stakeholders in the Jira ticket
  6. Get approvals 
  7. Inform via slack (email) the next merge the end users affected  for  that changes
  8. Execute the action.

This is my typical process for the cleanup activity.

As an example, let’s do the next real case with screenshots.

 

Goal:

Migrate from the Production environment field to Products field. Both fields are pickers. 

image.png

Where some of options are the same, if you see the small differences, you can change if both need to be merged.

image.png

Then under super user which has access to all related projects, create filters with related tickets.

image.png

Then I saved the filter with name test_

After visiting the Scriptrunner built-in scripts to copy custom fields values.

image.png

After verify via preview and run.

image.png

Hooray we merged. 

After using the new feature (https://jira.atlassian.com/browse/JRASERVER-41269) from 8.11.0, we can adjust the private filters via gui, if it’s needed. And public stuff as well via gui.

 

3 comments

Hi @Gonchik Tsymzhitov , thank you for this Article.
What will you do with "original" field? Will you immediatelly remove the field or will you just remove all the contexts or will you only remove it from all the screens?

Because from my experience it is sometimes impossible to fix everything and it is needed to make end users responsible that theirs objects (boards, filters, issues...) are ok. But when you send notification about change implemented on PRODuction environment, they often need to check data against original data... so I usually remove field in few phases

  1. I only remove it from the screens
  2. after month I remove contexts
  3. after month I remove the field

What is your way?:) 

Like Gonchik Tsymzhitov likes this

Hi @Martin Bayer _MoroSystems_ s_r_o__ , 

I missed that message, sorry for that. 

Well, my way is mostly the same: 

  1. Review context and dedicated if it's global
  2. remove it from the screens
  3. after month I remove contexts
  4. after month I remove the field

Sometimes I do project by project, then I can speed up that process :) 

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you