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.
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 ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Bill, Hope you can help?
Under screens, I have lot of old copies, is there a way to also bulk delete these?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Jonnada Kiran, @Tomas Gustavsson : your question has been asked and answered in another thread: https://community.atlassian.com/t5/Jira-questions/How-do-I-delete-unused-screens-in-JIRA-Server-via-API/qaq-p/808733
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your answer, i did searched some more yesterday and found this information.
should have wrinten a comment here.
Thanks again
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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()
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yeah Issue type screen scheme is not default but we have default issue type scheme for issue types right for Global (all unconfigured projects)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Neff Thanks for the post, no i see u delete mappings great!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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. :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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()
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks! It's really effective!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Venkateshwar Aynala You can find some cleanup scrips here Advanced cleanup | Atlassian Support | Atlassian Documentation
FYI: Clean up your Jira instance | Atlassian Support | Atlassian Documentation
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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()
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Andreas Schwib does this work on cloud as well? Can I use ScriptRunner to run this script? Thanks in advance for answer,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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);
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Neff please ignore my previous comment, it looks good the second script did the Job :D wooo!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Neff Good, i am impressed. Thank You for quick response.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello all, I found interesting app for cleaning up. Instance Auditor. Give it a try.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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>"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.