Safe to delete custom field values directly from the database for issues out of context?

[Mathias HD]

Hi Community,

I've recently changed the context of a custom field from global to a specific project context in Jira. Now, I've identified that there are still many issues outside the new context that retain values for this custom field, which is leading to null value errors and other issues.

"java.lang.NullPointerException: null value in entry: customfield_11724=null"

My current plan is to manually delete these orphaned custom field directly from the database. However, I'm concerned about potential impacts on data integrity and whether this approach aligns with best practices.

Questions:

1. Is it wise to manually delete these custom field directly from the database?
2. Are there any potential risks or considerations I should be aware of before proceeding with this method?
3. Would using Jira's bulk edit feature be a safer alternative for cleaning up these orphaned values?
4. Can anyone share their experiences or best practices for handling this kind of data cleanup in Jira?

Any insights or recommendations would be greatly appreciated!

Thank you!

P.S. A background reindex did notthing so far.

[Nicolas Grossi]

@Mathias HD 

https://community.atlassian.com/t5/Jira-Service-Management/Re-Re-Safe-to-delete-custom-field-values-directly-from/qaq-p/2730346/comment-id/172916#M172916

Anything you do will increase DB records, at this point i will suggest you to contact support (support.atkassian.com) and ask them to provide a "safe" sql query to clean your DB. 

I do not know if they will provide this information to you but you can try, correct ?

Nicolas

[Nicolas Grossi]

@Mathias HD reading your reply.... First of all the NullPointerException is a bug and if you have an active license, if i were you i will report it through support.atlassian.com.

Regarding setting a custom field as global, for me, it is a bad practice. Why ? Because your instance might have a bunch of projects and i almost sure that you do not want that field to be displayed in all fo the projects. In addition, your instance might have 8 project today and 12 project tomorrow and the field will be displayed (by default( in the new 4 projects too.

Instead you might apply the custom field to a new project when it is necessary.

The context of the custom field will always tell you the projects and the issue types where that field apply.

If you want you can reach me at nicolas.grossi@gmail.com and if you want we can meet.

Nicolas

[Mathias HD]

Hi @Nicolas Grossi

yes I came that far, it seems Extensions for JSD can not handle the context switch.

I opened a Bug report already.

I'm aware of the context implications and performance that's why I tried to set the context in this case from global to project.

But now I have 129.000 issues outside of the new context holding this field and values still inside the database.

Do I clean those or just live with it?

[Nicolas Grossi]

@Mathias HD Answers bellow:

1 - No

2 - You should not proceed with that method.

3 - Yes.

4 You are in a good path (Not de DB one :))

Bulk edit is an option, be sure that the new context is correctly applied, once you are sure, reindex db before continue.

Nicolas

[Mathias HD]

Hi @Nicolas Grossi ,

thanks for your clear answers.

To be more precise here is what I did and what happened that lead me to this: 

I realized that a global field was being used across all projects unnecessarily and decided to switch the field from being global to being specific to just one project. After making this change, I did not perform a reindex of the database. Today, I received a call reporting that the Request view on the portal was not working. Upon investigating and fiddling with the system, I encountered a NullPointerException exactly where the reporter was pointing. The error specifically pointed to the field that I had recently switched from being global to project-specific.

To address the issue, I initiated a background reindex, as this typically resolves similar problems, but it did nothing after 6 hours running successfully. However, I soon realized that the issue might stem from the fact that every issue in our instance still has this field filled with default values in the database, despite removing the field's context from these issues. This persisted likely as a protective measure for data integrity, but for my purposes, I wanted to remove this data garbage.

I attempted to clean this up through the UI but was unsuccessful. No JQL query returned issues where this field was filled in the database but was no longer in the context, making it impossible to locate and update these issues via a bulk edit.

So how would I go about this if I want to clean up the data garbage without being able to access the 129,000 issues with this field filled not found by any JQL in a Bulk Edit?