How to bulk delete screen schemes or issue type schemes?

Tej January 25, 2018

Hello,

For huge instance it very tough to manage or delete unused schemes in bulk

I see https://jira.atlassian.com/browse/JRASERVER-60618 as verified in Atlassian Backlog

Is any one ever deleted schemes in bulk,

Can anyone plz help me

Regards

Dave.

9 answers

1 accepted

Suggest an answer

Log in or Sign up to answer
10 votes
Answer accepted
Bill Neff January 30, 2018

This will remove all Issue Type Screen Schemes without any associated projects:

import com.atlassian.jira.component.ComponentAccessor

def schemeManager = ComponentAccessor.issueTypeScreenSchemeManager
def defaultScheme = schemeManager.defaultScheme;

def sb = new StringBuffer()

sb.append("Deleted issue type screen schemes with no associated projects:<br/><br/>\n")

schemeManager.issueTypeScreenSchemes.each {
try{
if(it == defaultScheme) {
//do not delete the default scheme
return;
}

if(it.projects.size() == 0) {
//remove any associations with screen schemes
schemeManager.removeIssueTypeSchemeEntities(it);

//remove the issue type screen scheme
schemeManager.removeIssueTypeScreenScheme(it);
sb.append("${it.name}<br/>\n")
}
}
catch(Exception e) {
//noop
sb.append("Error: " + e + "<br/>\n");
}
}

return sb.toString()

You will likely want to remove unused Screen Schemes after that, and then remove unused Screens.  

Jonnada Kiran March 8, 2018

Hi Bill. How to delete un used screens ? I mean screens not associated to any screen scheme or workflow ?

Tomas Gustavsson November 1, 2018

Hi Bill, Hope you can help?
Under screens, I have lot of old copies, is there a way to also bulk delete these?

Tomas Gustavsson November 2, 2018

Thanks for your answer, i did searched some more yesterday and found this information.
should have wrinten a comment here.

Thanks again 

Ahsan September 2, 2019

@Bill Neff 

Is there any script to delete unused Field Configuration Schemes, Field Configurations and Fields?

Also, Unused Issue Types Schemes and Issue Types.

Thanks in advance. 

10 votes
Bill Neff January 30, 2018

Here's the script to delete Screen Schemes not used by any Issue Type Screen Schemes, or only used by deleted Issue Type Screen Schemes

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.fields.screen.FieldScreenSchemeManager

def fssm = ComponentAccessor.getComponent(FieldScreenSchemeManager.class)
def itssm = ComponentAccessor.issueTypeScreenSchemeManager

def sb = new StringBuffer()

sb.append("Deleted screen schemes with no associated issue type screen schemes:<br/><br/>\n")

fssm.fieldScreenSchemes.each { fss ->
try {
def itssCollection = itssm.getIssueTypeScreenSchemes(fss);

// find field screen schemes that are still associated with deleted issues type screen schemes
def allDeleted = true;
itssCollection.each { itss ->
if(itss != null) {
allDeleted = false;
return;
}
}

//remove field screen schemes with no (valid) associated issue type screen schemes
if(itssCollection.size() == 0 || allDeleted == true) {
//remove association to any screens
fssm.removeFieldSchemeItems(fss);
//remove field screen scheme
fssm.removeFieldScreenScheme(fss);
sb.append("${fss.name}<br/>\n");
}

}
catch(Exception e) {
//noop
sb.append("Error: " + e + "<br/>\n");
}
}

return sb.toString()

 

Tej January 30, 2018

Thanks, alot Bill 

Really appreciate your super quick response 

Tej February 8, 2018

Hey Bill 

For bulk delete Issue type scheme we can't use id or project size right as default issue type scheme is not associated to any project!

Thanks

Dave.

Bill Neff February 8, 2018

As far as I'm aware, the Default Issue Type Screen Scheme is not really a default, it's just named as such.  You can rename it to whatever you want.  It doesn't get used  unless a project is specifically associated with it.  In our instance we have some projects associated with it, so my testing did not uncover what happens if it has no projects associated to it and you try to delete it.

Tej February 8, 2018

Yeah Issue type screen scheme is not default but we have default issue type scheme for issue types right for Global (all unconfigured projects)

Deafult Issue type scheme.png

 

 

Bill Neff February 25, 2019

To be safe, I updated my answer for deleting unused Issue Type Screen Schemes  so that it will skip deleting the Default Issue Type Scheme, regardless of whether it has any projects assigned to it or not presently.  

Like Nivruti Vora likes this
Moses Thomas
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 25, 2019

@Bill Neff  Thanks for the post, no i see u delete mappings great!

Ahsan August 29, 2019

@Bill Neff 

Thanks for your scripts.

I am also trying to understand them, so I can extend them further if needed.

Would you please explain what does this

 fss ->

and this

itss ->

doing?

Unfortunately on google I couldn't find any hint about it.

Thanks in advance. :)

Ahsan August 29, 2019

@Bill Neff 

Thanks for the script :)

Bill Neff August 29, 2019

@Ahsan Re, what does `itss ->` do, that is part of the groovy syntax for declaring a groovy closure (http://www.groovy-lang.org/closures.html) which is an anonymous function that runs on each element when using `each` to iterate over a collection (http://docs.groovy-lang.org/next/html/documentation/working-with-collections.html#_iterating_on_a_list

Ahsan August 30, 2019

@Bill Neff 

Thank you very much :)

7 votes
Bill Neff February 25, 2019

To complete the trifecta, I've adapted the nice script written by @Paul Tiseo on the thread that is just about deleting unused Screens.  I modified it to delete any screen that is deletable, as determined by having no non-null screen scheme or workflow associations.  This helps to clean up in case they were any deletions that occurred without properly removing the associations.

 

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.fields.screen.FieldScreenFactory
import com.atlassian.jira.issue.fields.screen.FieldScreenManager
import com.atlassian.jira.issue.fields.screen.FieldScreenSchemeManager
import com.atlassian.jira.web.action.admin.issuefields.screens.ViewFieldScreens
import com.atlassian.jira.workflow.WorkflowManager

FieldScreenManager fieldScreenManager = ComponentAccessor.getFieldScreenManager()
FieldScreenFactory fieldScreenFactory = ComponentAccessor.getComponent(FieldScreenFactory.class)
FieldScreenSchemeManager fieldScreenSchemeManager = ComponentAccessor.getComponent(FieldScreenSchemeManager.class)
WorkflowManager workflowManager = ComponentAccessor.getWorkflowManager()
ViewFieldScreens viewFieldScreens = new ViewFieldScreens(fieldScreenManager, fieldScreenFactory, fieldScreenSchemeManager, workflowManager)

// use StringBuffer to spit out log to screen for ScriptRunner Console
def sb = new StringBuffer()

sb.append('Screens that were deleted:<br/>\n');

fieldScreenManager.getFieldScreens().each { fieldScreen ->

//find all screens with no (or only null/previously deleted) screen schemes or workflows
def allEmptyOrNull = true;

viewFieldScreens.getFieldScreenSchemes(fieldScreen).each { fieldScreenScheme ->
if(fieldScreenScheme != null) {
allEmptyOrNull = false;
return;
}
}

if(!allEmptyOrNull) {
return;
}

viewFieldScreens.getWorkflows(fieldScreen).each { workflow ->
if(workflow != null) {
allEmptyOrNull = false;
return;
}
}

if(allEmptyOrNull) {
sb.append("${fieldScreen.getName()}<br/>\n")
fieldScreenManager.removeFieldScreen(fieldScreen.getId())
}

}

return sb.toString()
R. YUE November 26, 2019

Thanks! It's really effective!

Jordan Loverock October 6, 2020

All 3 of your scripts worked perfectly in latest version of Jira Service Desk Server.

Thanks a bunch! Lots of really great concepts in there that can be applied elsewhere as well!

Venkateshwar Aynala November 9, 2021

@Bill Neff The above is really useful. However with the 3rd script for deleting unused screens we get an error for below line

ViewFieldScreens viewFieldScreens = new ViewFieldScreens(fieldScreenManager, fieldScreenFactory, fieldScreenSchemeManager, workflowManager)

The error generated is 

Could not find matching constructor for: com.atlassian.jira.web.action.admin.issuefields.screens.ViewFieldScreens(com.atlassian.jira.issue.fields.screen.DefaultFieldScreenManager, com.atlassian.jira.issue.fields.screen.DefaultFieldScreenFactory, com.atlassian.jira.issue.fields.screen.DefaultFieldScreenSchemeManager, com.atlassian.jira.workflow.OSWorkflowManager) at Script29.run(Script29.groovy:12) 

I have looked at the latest API(hopefully) and do not see any issue with that constructor usage. Please could you suggest.

Like deepali3031 likes this
Venkateshwar Aynala November 10, 2021

Thanks @Teja Namala I see that I am using the same script for cleaning up screens as given in Advanced cleanup link and thus still see same error. Probably with latest jira version there's a change in API which necessitates the way ViewFieldScreens class is initialized?

Andreas Schwib February 2, 2022

@Venkateshwar Aynala I had the same problem, the constructor has apparently changed (Jira 8.19 API).

I have adapted the script accordingly:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.fields.screen.FieldScreenFactory
import com.atlassian.jira.issue.fields.screen.FieldScreenManager
import com.atlassian.jira.issue.fields.screen.FieldScreenSchemeManager
import com.atlassian.jira.web.action.admin.issuefields.screens.ViewFieldScreens
import com.atlassian.jira.workflow.WorkflowManager
import com.atlassian.jira.bc.issue.fields.screen.FieldScreenService
import com.atlassian.jira.security.JiraAuthenticationContext
import com.atlassian.webresource.api.assembler.PageBuilderService

FieldScreenManager fieldScreenManager = ComponentAccessor.getFieldScreenManager()
FieldScreenFactory fieldScreenFactory = ComponentAccessor.getComponent(FieldScreenFactory.class)
FieldScreenSchemeManager fieldScreenSchemeManager = ComponentAccessor.getComponent(FieldScreenSchemeManager.class)
WorkflowManager workflowManager = ComponentAccessor.getWorkflowManager()
FieldScreenService fieldScreenService = ComponentAccessor.getComponent(FieldScreenService.class)
JiraAuthenticationContext jiraAuthenticationContext = ComponentAccessor.getComponent(JiraAuthenticationContext.class)
PageBuilderService pageBuilderService = ComponentAccessor.getComponent(PageBuilderService.class)

ViewFieldScreens viewFieldScreens = new ViewFieldScreens(fieldScreenManager, fieldScreenFactory, fieldScreenSchemeManager, fieldScreenService, workflowManager, jiraAuthenticationContext, pageBuilderService)

// use StringBuffer to spit out log to screen for ScriptRunner Console
def sb = new StringBuffer()

sb.append('Screens that were deleted:<br/>\n');

fieldScreenManager.getFieldScreens().each { fieldScreen ->

//find all screens with no (or only null/previously deleted) screen schemes or workflows
def allEmptyOrNull = true;

viewFieldScreens.getFieldScreenSchemes(fieldScreen).each { fieldScreenScheme ->
if(fieldScreenScheme != null) {
allEmptyOrNull = false;
return;
}
}

if(!allEmptyOrNull) {
return;
}

viewFieldScreens.getWorkflows(fieldScreen).each { workflow ->
if(workflow != null) {
allEmptyOrNull = false;
return;
}
}

if(allEmptyOrNull) {
sb.append("${fieldScreen.getName()}<br/>\n")
fieldScreenManager.removeFieldScreen(fieldScreen.getId())
log.info "remove screen"
}

}

return sb.toString()

 

Like Venkateshwar Aynala likes this
Venkateshwar Aynala February 2, 2022

Excellent @Andreas Schwib . Works like a charm :). Thank you.

Martin Bak April 12, 2022

@Andreas Schwib does this work on cloud as well? Can I use ScriptRunner  to run this script? Thanks in advance for answer,

Like # people like this
2 votes
Rodrigo December 13, 2018

Hi @Tej

 

I managed to delete the workflows and schemes one-by-one, but gave up when it came to deleting screens.

I just shared this article on bulk deleting them with JMeter:

https://community.atlassian.com/t5/Jira-articles/Bulk-deleting-unused-screens-in-Jira-with-JMeter/ba-p/961695

 

It doesn't require additional apps/plugins and is quite safe, since it's just automatically firing HTTP requests that could be made by an actual (admin) user.

 

Cheers

djohnsoncainc January 15, 2019

Hi @Bill Neff - I ran the bulk delete issue type screen schemes on  a test instance. this appeared to work fine / same as if I manually deleted. 

However, then when I ran the bulk delete screen schemes script, even though the issue type screen schemes some of these screen schemes were originally connected to were now gone and no relationship was displayed in the ui, the "delete" link did not appear in the UI. I then modified the delete script just to audit the relationship between the issue type screen schemes and screen schemes and based on this, it appears that an issue type screen scheme is still connected to these screen schemes even though none is visible in UI.

Any thoughts/suggestions? Anyone else have this issue?

Thank you!
Donna J.

Adam Martin February 23, 2019

It sounds like I hit the same issue you are describing.  One of those cases where the API didn't take care of everything properly.  The Groovy script should be doing a removeSchemeAssociation before doing the removeIssueTypeScreenScheme.

I was able to fix in the DB by running this.

SELECT to ID the orphaned relationships.

select * from issuetypescreenschemeentity where scheme not in (select id from issuetypescreenscheme);

DELETE the orphaned relationships.

delete from issuetypescreenschemeentity where scheme not in (select id from issuetypescreenscheme);
Moses Thomas
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 25, 2019

@Adam Martin  Thank  You! for your  input  I was able to  solve it like this also.

Script need to  be modified to  deal  with  this case, remove all mapping  before .  I will  work on it.

 

Best  regards

Like Adam Martin likes this
Bill Neff February 25, 2019

I modified my answer above for deleting unused IssueTypeScreenSchemes so that it removes the association to all ScreenSchemes prior to deletion.  This should prevent the issue where you see an apparently unused Screen Scheme that has empty bullet points for which IssueTypeScreenSchemes it uses.

I also modified the script answer for deleting unused Screen Schemes to delete ones that are not referenced by any IssueTypeScreenSchemes, or are only referenced by those that have been deleted.

Between those two changes, it should cleanly delete unused Issue Type Screen Schemes and unused Screen Schemes.

Like Adam Martin likes this
Moses Thomas
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 25, 2019

@Bill Neff   please ignore  my previous comment, it  looks good  the second  script did the Job  :D  wooo!

 

Bill Neff February 25, 2019

@Moses Thomas  - if you have already run the first script to remove unused issue type screen schemes before I updated it to remove the associations to screen schemes, then running it again with the fixed script won't remove them.

Try running the second script I posted to remove unused screen schemes, as it does check to see if it is only associated with deleted issue type screen schemes and will remove itself if it is: 

Like Moses Thomas likes this
Moses Thomas
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 25, 2019

@Bill Neff  Good, i am impressed. Thank You for quick response.

Moses Thomas
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 26, 2019

@Bill Neff    The not deleted mapping was a result  of running  the script before  the  removal  of mapping,  after removing mapping from data base  perform test again in  right order it works fine  thanks!

 

1 vote
Martin Bak May 17, 2022

Hello all, I found interesting app for cleaning up. Instance Auditor. Give it a try.

 

Find new apps - Jira (atlassian.net)

0 votes
Volodymyr April 6, 2022

If you're looking for a script that can delete unused/inactive Issue Type Schemes:

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.fields.config.FieldConfigScheme;
import com.atlassian.jira.issue.fields.config.manager.IssueTypeSchemeManager;

def issueTypeSchemeManager = ComponentAccessor.getIssueTypeSchemeManager();
def fieldConfigSchemes = issueTypeSchemeManager.getAllSchemes();

def sb = new StringBuffer();
sb.append("Deleted inactive issue type schemes:\n")

fieldConfigSchemes.each {
try{
if (!it.getName().equals("Default Issue Type Scheme") && it.getAssociatedProjectObjects().size() == 0) {
issueTypeSchemeManager.deleteScheme(it);
sb.append("${it.name}\n")
}
} catch(Exception e) {
//noop
sb.append("Error: " + e + "\n");
}
}

return "<pre>" + sb.toString() + "<pre>"

This is a previous coworker's code, not mine. I just changed a couple of lines to match the scripts above - I can't code.

0 votes
Mahidhar kodam July 12, 2020

@Bill Neff  

Hi im a new member here.

 i made a mistake and unassociated all previous projects assigned to an issue type , while i selected only my project to associate. Now i want to undo the changes, how can i undo ?

Where can i see the history of that issue type scheme and previous project that were associated to that scheme, please advise 

Thanks,

Mahidhar.

0 votes
Batuhan Celiker March 25, 2020

Hello, i made mistake and deleted all Issue Screen Schemes including the default Scheme.

I get this Error:

Can anyone help?

A quick answer would be very nice

2020-03-25 17:47:00,813 ajp-nio-8009-exec-59 ERROR [o.a.c.c.C.[.[localhost].[/etc_bt_jira].[action]] Servlet.service() for servlet [action] in context with path [/etc_bt_jira] threw exception [com.atlassian.cache.CacheException: java.lang.NullPointerException: Null keys are not supported] with root cause
java.lang.NullPointerException: Null keys are not supported
at com.atlassian.cache.memory.DelegatingCache.rejectNullKey(DelegatingCache.java:442)
at com.atlassian.cache.memory.DelegatingCache.get(DelegatingCache.java:143)
at com.atlassian.jira.issue.fields.screen.DefaultFieldScreenSchemeManager.getFieldScreenScheme(DefaultFieldScreenSchemeManager.java:69)
at com.atlassian.jira.issue.fields.screen.issuetype.IssueTypeScreenSchemeEntityImpl.getFieldScreenScheme(IssueTypeScreenSchemeEntityImpl.java:81)

0 votes
Capi [resolution]
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
March 25, 2019

Hi @Tej ,

It's a bit late but if I may, I'd suggest a more proactive approach that checks whether the deletion of a project would create orphan schemes and then removes those. You can see the details here:

https://community.atlassian.com/t5/Jira-Software-articles/How-to-prevent-the-propagation-of-unused-project-schemes/ba-p/1018765

Tej June 19, 2019

Thanks for suggesting it

Yeah we did the same way, 1st targeted unused projects and deleted them then later lot of screens and schemes got orphaned. 

djohnsoncainc June 20, 2019

Thank you all for the information!

Capi [resolution]
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
June 24, 2019

@Tej what I meant is that you should put a process in place that automates the deletion of schemes and other project attributes provided that the deletion of a project makes them orphan. Again, check the link above to see more about how to do this with Profields. 

For full disclosure, I work at DEISER, Profields' manufacturer.

TAGS
AUG Leaders

Atlassian Community Events