Any way to search for broken JIRA saved filters -- and then do a mass fix?

[Philip Schlesinger]

Hi all,

So at times an administrator does something like renaming a JIRA custom field.  

Moments later he/she realizes that he/she has broken a whole bunch of saved filters – as those filters often are written with the hard-coded name of the JIRA custom field.  See my question here about how to do a workaround for that issue (the answer I got was effectively "sure if you want to refer to your custom fields by ID#, but then the queries will be unreadable").

That's not cool; we JIRA administrators want to have the flexibility of doing things like renaming a JIRA custom field.  Once we've done something that could break a bunch of JIRA saved filters, we JIRA administrators would then like a way to search for those broken JIRA saved filters – and then do a mass fix of them without having to edit each and every one.

It would be nice to do even as an hourly or more frequent automated task that scans for broken JQL and immediately emails the JIRA administrators a list of what's broken.

[Nic Brough -Adaptavist- · Accepted solution]

That would be a feature request over at https://jira.atlassian.com/browse/JRA

I think a lot of the problem has been discussed on your original question, with no particularly useful answer, which isn't really helpful.  But I'm not sure that there is an "easy" answer or workaround beyond "only rename fields in exceptional circumstances" or "educate the users that when your admins shuffle things, filters can break"  (In fact, the second approach is one (bad) way to inform users that their fields have been renamed.

There is a bit of a problem with your approach at scanning - it either requires a duplicated set of data to compare what fields have been changed since the last time it ran, or it needs to physically duplicate the filter validation that JIRA does, for every saved filter, which does not scale - you'd overload a big JIRA with that approach.

My instinct is to ask that the way filters are stored - instead of plain text, store them as ordered sets of validated clauses with the custom field ids.  That stops the problem you've run into, it can easily be made to display the field name, and the overhead of converting them between strings and a structure should be negligible.  But, that needs doing by Atlassian.

[MattS]

A plugin could search the stored jql strings for instancesof renamed fields. But you'd have to record the old name somewhere before changing the field name. And some names might be substrings of others. Nic is right