Orphaned plugin-related custom fields in the database - how to remove them?

Question

While looking for unused custom fields in the database I have found some really old customfields:

Test Sessions10008com.atlassian.bonfire.plugin:bonfire-multi-session-cftTesting Status10017com.atlassian.bonfire.plugin:bonfire-testing-status-cftBonfire Browser10011com.atlassian.bonfire.plugin:bonfire-textBonfire Operating System10012com.atlassian.bonfire.plugin:bonfire-textBonfire User Agent10010com.atlassian.bonfire.plugin:bonfire-textissueFunction10402com.onresolve.jira.groovy.groovyrunner:jqlFunctionsCustomFieldTypeBonfire jQuery Version10015com.atlassian.bonfire.plugin:bonfire-textBonfire URL10013com.atlassian.bonfire.plugin:bonfire-textBonfire Screen Resolution10014com.atlassian.bonfire.plugin:bonfire-textuuid10018com.atlassian.jconnect.jconnect-plugin:uuid

Those fields are not displayed on custom field list in Jira. When I try referencing the field by the ID jira shows:

There are no customfieldvalue entries for these fields in the database.

Plugins/Apps that probably introduced those fields (Bonfire, Script Runner, jconnect) are long gone from our instance. I suppose old versions of these plugins were unable to properly clean after themselves while uninstalling, and those old fields were carried over with all our subsequent jira upgrades.

Integrity Checker shows that everything is fine - obviously it can't detect those fields.

How can I clean those orhpaned unused customfields without breaking anything? Is there any tool for this? Or maybe some KB article on this?

Nic Brough -Adaptavist- · Answer

Yep, the cPrime Health Report is not coded to ignore them (I'd argue rightly so, as it's worth noting they are there).

As for DB Based Jira integrations, you probably shouldn't be doing that.  Reporting directly off a Jira database is a terrible thing to do.  One of the minor reasons is that it doesn't understand the logic for fields like these, so they don't know to ignore them.

Błażej O_ · Answer

Well, we do ignore those so far, but they pop-up from time to time in different scenarios and force us to keep track of them as an exception to the rule. Few cases are:

* cPrime health Report mention those as unused fields
* DB based Jira integrations show those fields in various reports

So far it's only annoyance and unnecessary maintenance cost but I generaly like to tie all loose ends to avoid the butterfly effect in the future, and these bugged entries definitely count as loose ends.

Nic Brough -Adaptavist- · Answer

It is safer to simply ignore them, although if you put scriptrunner back, you could write a script to safely remove most of them.

Why are you worried about getting rid of them?