Issue types, custom fields, screens belonging to add-ons

Walter Haas January 10, 2017

Is there a way to identitfy which issue types, custom fields or screens belong to which add-on?  The add-on name is not always defined in the title or description. Also when uninstalling trial versions these artefacts seem to be not automatically removed, so you end up with a pretty big amount of not needed lets say custom fields.

1 answer

1 accepted

0 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 10, 2017

Screens and issue types don't really belong to add-ons, they're created by them sometimes, but that's the end of the association really.  Once created, they're global JIRA artefacts, and removing the add-on simply leaves that issue type or screen behind.  The behaviour and functionalities may change, but the artefacts don't.

  An obvious example: You have JIRA Core and the standard issue types.  You add JIRA Software, you get Epics added, with a pile of new functions.  If you remove Software, it leaves your Epics alone, but the extra functions stop working.

Fields are the one I think is at the core of your question.  If an add-on adds a field type, you can then add fields of that type (some add-ons will add them for you, which is annoying unless they're very standardised fields with specific functions).  When you remove the add-ons, the fields look like they vanish.  But they leave all their data in place, just in case you re-enable or need to preserve data.  (Some bad add-ons try to remove their data, avoid them as it causes problems with removals, upgrades and audits).

The annoying thing is that it's very hard to identify the field types that such add-ons create and maintain.  There's two ways I've found - one is parsing the raw data (either of a backup xml, or better, reading the customfield table directly in the database), because the field types have the internal names of the add-ons in the field definitions on them, and the other is to read the field types out of the custom field list in the admin UI.  In both cases you then have to do the annoying thing of subtracting all the fields that are of an off-the-shelf type.

Walter Haas January 11, 2017

Hi Nic, I think the tip to look at the customfield table directly in the database answered my question regarding fields. And Issue type wise, whenever I am able to identify unecessary issue types. In many cases via Internet search to find the add-on it belongs to, I delete it manually. But in anyway it would be great to have some cleaning up functionality for uninstalled add-ons. Thank you for the help.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 11, 2017

I agree, it would be great if there were a simple report that listed all the fields you have and what add-on is providing them (in human, not just a class name you have to guess/remember/google)

Suggest an answer

Log in or Sign up to answer