It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to bulk delete screen schemes or issue type schemes?

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, I think it can be done in Script Runner Console

Can anyone plz help me with the script

Regards

Dave.

5 answers

1 accepted

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.  

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

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

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

Thanks again 

@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. 

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()

 

Thanks, alot Bill 

Really appreciate your super quick response 

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.

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.

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

 

 

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.  

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

@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. :)

@Bill Neff 

Thanks for the script :)

@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

@Bill Neff 

Thank you very much :)

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()
1 vote

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

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.

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);

@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

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

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

 

@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

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

@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!

 

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

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. 

Thank you all for the information!

@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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Opsgenie

What’s New in Opsgenie October 2019

Hi there, we have a lot of exciting announcements this month, specifically around Dark Mode. You don’t want to miss out!    Dark Mode for Mobile App is here! A few weeks ago, we annou...

513 views 2 13
Read article

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