In agreement here, this needs fixing as it is far too easy for users to accidentally delete filters associated to boards.

Please fix this issue at your earliest convenience 

Are we allowed to ask what is taking so long to fix this?
Seems like a very simple fix to add to the startup procedure.
We have made scripts to address this but rather have this landmine resolved in the core product.

Disappointing to be prepping for 9 LTS upgrade to see this still lingering

I found this page that seems to work: https://confluence.atlassian.com/jirakb/jira-software-boards-not-visible-after-filter-deletion-779158656.html

The link posted in the previous comment and in the Current Status field doesn't appear to be visible. Even though I'm logged into my Atlassian account, I'm simply re-directed to: https://confluence.atlassian.com/alldoc/atlassian-documentation-32243719.html. Should it be visible?

Throwing my hat in the "Please fix this" ring. This just bit my team, and there was NO warning when we deleted the filter that a Board would be affected. This is such a pain. Also, TY to alex779065377 for the lifesaver!

I just ran into this issue. Since the affected board was being used as an issue source in a Jira Portfolio Plan, it has broken that too. The symptom is if you go to the Plan --> Configure --> Issue Sources, that page will sit on a progress bar and never load. You should consider not allowing the deletion of a filter that is being used on a board or anywhere else. Force the board to be deleted/updated first before allowing the filter deletion!

Thank you alex779065377 

Your workaround has worked for us on Jira v8.13.1

Thank you very much alex779065377 ! 
Very kind

and

the reason why Atlassian won't fix anything.

Which is not your fault, Alex !

I rewrote the script from a previous comment for Jira 8.5, this worked for me:

import com.atlassian.greenhopper.manager.rapidview.RapidViewManager
import com.atlassian.greenhopper.model.rapid.RapidView
import com.onresolve.scriptrunner.runner.customisers.PluginModuleCompilationCustomiser
import com.atlassian.jira.component.ComponentAccessor

long BOARD_ID = 0L //board that was bugged
long FILTER_Id = 0L //new filter for that board

def rapidViewManager = PluginModuleCompilationCustomiser.getGreenHopperBean(RapidViewManager)
def rapidView = rapidViewManager.get(BOARD_ID).get()

rapidViewManager.update(new RapidView.RapidViewBuilder(rapidView).savedFilterId(FILTER_Id).build()) 

+1

+1

+1 for April's comment, especially large organizations where we need to share responsibility at times and at all levels from Jira Admin to users.

Also to add, the linked JIRA's and comments seem all directed toward boards specifically - apologies if this is not in the scope of this JIRA, no mention of deleting a filter that is associated with

a) Another filter, eg:

Project in (x) AND NOT filter = 12345

b) A filter on an issue Dashboard.

In addition to JIRA, I work in a completely unrelated system which also has heavy dependencies. You can check dependencies at any time, so you can see a list of every asset that references it. When you attempt to delete it shows the dependencies and makes you delete the dependencies first before you can delete what you are trying to. Is this annoying? Sometimes. But does it help in many ways? Yes. Other than the obvious of not deleting super important things by accident. Imagine walking into an Organization and not knowing everything but needing to update a filter a former employee created? View Dependencies - see everywhere that filter is used and know the impact before you get, as Niel put it, "BOOM 70 people with pants on fire."

Compared to other products I use, in JIRA, we are just flying blind.

Hi Atlassian,

This issue has been open for some years now, and although there are many comments, I'm not sure most of them describe what we customers are looking for in away you can use in a product discussion.

Let's just try to fix that right now:

Problem 1: People can delete a filter associated with an Agile board, and this action causes breakage.

Problem 2: The very simple perm design for managing filters was created years ago, before you purchased Greenhopper, and has not been revisited since. Due to the lack of modern, compatible, app and enterprise-aware filter permissions management in Jira, your devs have very limited options for improving this experience with Agile boards.

Ideal solution:

Re-imagine filter permissions within your current ecosystem, with an eye toward better compatibility and improved management options for larger organizations, such as group ownership and visibility of all filters to system admins. This would give a developer reading this issue options like "let's throw a warning and redirect the user to the related board, or offer to delete both objects," etc. It would also open the possibility of finally resolving many of your other open issues, which align with common enterprise pain points. While permissions aren't usually thought of as a sales point, enterprise customers are very interested in management and compliance-related features, and improvements here are likely to increase satisfaction and retention among your smaller clients as well. Obviously you have already seen the benefits and opportunities presented by improving project level permissions, so I think fixing filter management would be a very natural next step for you.

Limited solution:

Detect the filter's usage in Agile, and don't allow deletes in this case, period. This will force the user to remove the related board first, and allow you to close out this particular issue.

What if we want to remove all of those orphaned boards from the database? I mostly only care about this if they have some performance cost, since "view on board" times out sometimes and I'd like to address that.

Thanks David! Excellent point 

@April.
Please consider using table joins rather than sub-selects. Whilst it makes little difference with small data sets, it will stand you in good stead in the future (and is a good habit to get into)
i.e.

SELECT * FROM jiraschema.AO_60DB71_RAPIDVIEW LEFT JOIN jiraschema.searchrequest on jiraschema.AO_60DB71_RAPIDVIEW.SAVED_FILTER_ID = jiraschema.searchrequest.id where jiraschema.searchrequest.id is NULL;

That sounds pretty much like what we do, although I don't query the API for breakage.

I had our DBAs set up reporting services to email me if rows were returned for:

// boards with no filter
SELECT * FROM jiraschema.AO_60DB71_RAPIDVIEW WHERE SAVED_FILTER_ID NOT IN (SELECT id FROM jiraschema.searchrequest)

Then if any are found, you can apply a new filter via the ScriptRunner console. Found this code on Community:

// was posted for Jira 7; may need updates for Jira 8

import com.atlassian.greenhopper.manager.rapidview.RapidViewManager
import com.atlassian.greenhopper.model.rapid.RapidView
import com.onresolve.scriptrunner.runner.customisers.JiraAgileBean 

long BOARD_ID = # //board that was broken
long FILTER_Id = # //new filter for that board

@JiraAgileBean
RapidViewManager rapidViewManager 

RapidView rapidView = rapidViewManager.get(BOARD_ID).get()
rapidViewManager.update(new RapidView.RapidViewBuilder(rapidView).savedFilterId(FILTER_Id).build())

Works like a charm!

@Kevin Martin I'm reviewing them with the other Jira SysAdmin in a bit, but essentially all we're doing is using a Scriptrunner REST endpoint to return json of sql queries to our db. Much of the sql statements used in the groovy script target the Portfolio issue_source table (boards that are in issue_source but not rapidview, filters that are in issue_source but not searchrequest, projects that are in issue_source but not project). The relevant queries to this issue would be where the "saved_filter_id" in rapidview doesn't show up in searchrequest.

We're not doing anything to action the results for right now, but at least we have a list once we do.

Hey Tyler, I don't suppose you would be interested in sharing your scripts would you?

Hi Team, we have had a similar case. We don't want board links to get lost once the filter is deleted, please fix this.

We (as admins) have built scripts (a internal workaround) to identify boards in this state. It would be better for us to be able to handle board removal more elegantly when we clean out old filters. I'm in support of the previous comments.

I also agree with previous comments. At least please raise priority! Solution = no object that is referenced in Jira should be deletable.

I completely agree with Jeffrey here. Other configuration objects in Jira admin area cannot be deleted when e.g. projects use / reference them.

So in case an agile board, a dashboard gadget or even another filter uses a filter, that filter must not be deleted. i.e. the delete button must not be present.

7 years and Atlassian still needs to "gather impact"?  This is yet another example of Atlassian being satisfied with Jira being an "OK" product rather than a "Great" product.  And yes I hope that offends someone into addressing this request.  We have 336 boards with no filter because "if it can happen, it will".  It shouldn't even be possible to delete referenced objects.

Hello, in this case Jira should propose or delete the board before the filters or allow you to select another filter to associate with the board or automatically associate the board with a default filter

Thanks!

This could potentially have huge impact to an organization operation!

At least have a warning.

+100

We had a PMO member trying to do clean up of their old filters and caused a couple of these this morning...

+1 seems dumb this is even a thing that can happen with no warning. At least add a warning if the filters are in use.

+1

Please fix. This happens quite often.

Hello,

Is there an enterprise solution to this issue that does not involve modifying the SQL database?  Thanks. 

This happens more frequently than you would think and breaks other systems that we use with Jira. Please fix this - this bug is unacceptable.

Thanks Carlos for pointing that ScriptRunner code

https://jira.atlassian.com/browse/JSWSERVER-6706?focusedCommentId=867896&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-867896

lexek-92 solution works perfectly!

I have ScriptRunner and was able to add a dummy filter to all my ghost boards so that I could finally delete them.

Btw, I use the "Integrity Check for Jira" addon to identify all the ghost boards.

I just find out this issue after a user complains about his own mistake. And find out my system contains 54 "orphan" boards where filter is no longer available to grant access to corresponding board.

Use of JS in banner to implement one or more work-arounds over Jira product makes me feel uncomfortable. I will try to find a way with Adaptavist script runner...

Hi Simon,

That won't fall under policy category for any restriction - check with Jira admin.

Thanks, I think (but could be wrong) that we have a policy of not allowing this sort of thing, but I'll ask.

Hi @simon,

have you tried below script injected in announcement banner?
<script>
(function($){
$( document ).ajaxStop(function() { if($("p[data-board-count]").length > 0)

});
})(AJS.$);
</script>

I cannot emphasise enough the pain of this problem. At the very least the warning should be greatly increased to explicitly state the board will be deleted. "unstable" does not mean deleted. Please, please, do something about it. Or perhaps just don't allow a query to be deleted if it belongs to a board. Anything is better than this situation.

deleted

Agree with @April's comment

Hi Atlassian,

This issue has been open for some years now, and although there are many comments, I'm not sure most of them describe what we customers are looking for in away you can use in a product discussion.

Let's just try to fix that right now:

Problem 1: People can delete a filter associated with an Agile board, and this action causes breakage.

Problem 2: The very simple perm design for managing filters was created years ago, before you purchased Greenhopper, and has not been revisited since. Due to the lack of modern, compatible, app and enterprise-aware filter permissions management in Jira, your devs have very limited options for improving this experience with Agile boards.

Ideal solution:

Re-imagine filter permissions within your current ecosystem, with an eye toward better compatibility and improved management options for larger organizations, such as group ownership and visibility of all filters to system admins. This would give a developer reading this issue options like "let's throw a warning and redirect the user to the related board, or offer to delete both objects," etc. It would also open the possibility of finally resolving many of your other open issues, which align with common enterprise pain points. While permissions aren't usually thought of as a sales point, enterprise customers are very interested in management and compliance-related features, and improvements here are likely to increase satisfaction and retention among your smaller clients as well. Obviously you have already seen the benefits and opportunities presented by improving project level permissions, so I think fixing filter management would be a very natural next step for you.

Limited solution:

Detect the filter's usage in Agile, and don't allow deletes in this case, period. This will force the user to remove the related board first, and allow you to close out this particular issue.

Hope this gives you something to talk about.

affects 7.3.4

Thanks David.

Yes I guessed that I had to click on the 'delete' option to see the popup but the button delete is not disable.

I even click on it to be sure and now I've lost my board ! Fortunatelly it was on a test server.

@emmanuel - I can't tell you what versions it's supposed to work on, but I can tell you that it does work on JIRA Server v7.3.

Note that the 'delete' option that's greyed out is not the first one when you're viewing the list of filters (and the cog on the right hand side gives you the 'edit' and 'delete' options', it's after you've clicked delete there and are given the warning (as posted in the screenshot at the top of this issue).

@Peter-Dave : Does not work for me. On My both version 5.2.11 and 6.4.11. The button delete is newer disabled.

Could you please tell us the version of JIRA that it is supposed to work ?

Thanks

@Peter - it could have been easily done with Scriptrunner, but we can't install SR on that instance (restricted). When I bind onchange() to issueType selection - it works only for 1st change.

@Piyush, while it may be possible to bind a function to the change event on the issue type in a banner script, I would recommend looking into scriptrunner for this sort of things. 

Hey Peter, that's awesome and working in JIRA SERVER 7.3 version !!

@Peter: I may need a help - my requirement is to have field text auto-populated based on issue type selected; it's working but if the issue-type is changed - the text doesn't get updated.

Thanks Peter.  Seems to work here nicely.

Peter, thanks for fix, i need to check this. that would be nice.

Not being one willing to wait for such things, I implemented a quick fix of my own...

Just add those lines in your announcement banner and the delete button will be disabled when a user attempts to delete a filter associated with a board.

<script>
  (function($){
    $( document ).ajaxStop(function() {
      if($("p[data-board-count]").length > 0) {
        $("#delete-filter-submit").prop("disabled", "true")
        var warning = $("p[data-board-count]").html()
        $("p[data-board-count]").html(warning.replace('will make the board unusable.','would make the board unusable. Deleting is disabled.'))
      }
    });
  })(AJS.$);
</script>

This only works for JIRA Server I believe. 

NB: The proposed workaround (https://confluence.atlassian.com/display/GHKB/Boards+Are+Not+Visible+After+the+Filter+is+Deleted) only applies to the on-premise install; not the Cloud version.

Is there any workaround available for the Cloud version?

Thanks in advance.

Is there already a estimation when this issue will be fixed?

Great! An inconsistency of one of the most used objects (rapid / agile board) is sleeping in the backlog. Do you guys just sense how many users curse on that behaviour? The warning is fine on one end but the major point is that the board is not editable / usable anymore.

Given that a board is holding more information than just a filter ID it is unacceptable that you won't fix this bug as soon as possible. As an administrator I need to restart my instance to make a board available again.

Please implement this in the JIRA Cloud version. A project lead deleted one of his filters that he forgot was linked to a board. So we had to recreate the filter and board and re-setup the Quick Filters, Card Colors, Card Layout, Estimation, and Issue Detail. This would have been avoided if he could have received a Warning message before deleting the filter.

piyush_annadate - the warning is part of JIRA Software from 7.1.1 Server, it's not a plugin as such.
Kind regards,
Martin
JIRA Software

@mjopson I didn't found that plugin in JIRA 7.1.4

Is there a way to add 'confirmation to delete' screen using some scripts?

It would be great if this type of warning could also be issued when attempting to delete a filter that is being used in a gadget in a Dashboard.
I did a little test using a filter in the Issue Statistics gadget in a Dashboard. When I selected "Delete" for the filter it automatically deleted the filter, there was no warning message.

The warning is fantastic! Thanks very much.

I wish though that the filter ownership could be assigned to a group or project role. It is so annoying when a manager who owns many filters leaves, and I must pester long list of humans to find new owners.

It would be so lovely to just give ownership of the darn things to, say, the 'product team,' and then forget about it.

Perfect, thanks!

colinw - occurence factor is a custom field used for assessing relative impact of bugs, it is just one factor used in the bugfix triage process.

There is now a warning, it shipped to Server customers in JIRA Software 7.1.1.
An example of a warning:

Kind regards,
Martin
JIRA Software

Is this correct - is there now a warning? If so, from which version? Thanks.

mjopson Martin Jopson [Atlassian] added a comment - 05/Apr/2016 12:41 AM
Thanks for commenting, watching and voting on this issue, we are aware that the impact of this issue is significant to many of you.
As an initial step we have previously updated the dialog when deleting a filter to warn/notify of the impact to any boards using the filter.
I am reclassifying this issue to Bug so that it can be tracked and addressed as such, however we cannot provide any guidance at this time as to when it will be fixed. Please follow this issue for further updates.
Kind regards,
Martin
JIRA Software

This absolutely sucks, at least warn us, or don't even allow the filter to be deleted if it's associated with a board - what is this "occurrence nonsense comment"

Occurrence Factor: 25% - affects a minority of users or feature is not regularly used

For those on Jira Cloud who experience this before it gets fixed.

1. Support can retrieve your old filter contents if you don't know it
2. They then ask you to create a new filter using these contents
3. Then reply to them and they will hook it back up to the board.

This bug is currently the highest voted open bug against the JSW project, by a large margin, and third highest voted all time. Please fix the damn bug. Thank you.

project=JSW AND type=Bug AND status not in (Resolved, Closed) ORDER BY Votes

josh82, if you encountered this problem on your Cloud site, please create a Support Request with the Cloud Team at support.atlassian.com and we'll help out.
Cheers!

Mate, this is crazy - Using Jira cloud, we can't run the "Workaround" provided here
https://confluence.atlassian.com/jirakb/boards-are-not-visible-after-the-filter-is-deleted-779158656.html

it should just NOT be possible to break a Board by deleting a personal filter

I see the Occurrence Factor got updated to:

25% - affects a minority of users or feature is not regularly used

I find it hard to believe this cannot be pretty easily fixed. Somebody (a Product Manager) just needs to bump it up in priority.

Thanks for commenting, watching and voting on this issue, we are aware that the impact of this issue is significant to many of you.

As an initial step we have previously updated the dialog when deleting a filter to warn/notify of the impact to any boards using the filter.

I am reclassifying this issue to Bug so that it can be tracked and addressed as such, however we cannot provide any guidance at this time as to when it will be fixed. Please follow this issue for further updates.

Kind regards,
Martin
JIRA Software

This makes good sense John. I defer to your superior design.

I think the approach of board filters actually being a user's personal filter is fundamentally broken.

The correct solution is not to have special code that detects and/or prevents the deletion of a personal filter if it happens to be used by a board.

Instead, board filters should be entirely separate from personal filters. When you create a board, it's filter could be a copy of a personal filter, but after creation the two filters would be independent. JIRA would then need to determine some permission rules about who can modify board filters.

I have used JIRA for years and never run into this issue until today. A long time employee was cleaning up their filters having long ago forgotten one controlled the Jira board.

BOOM

70 people with pants on fire.

Please fix this.

A filter tied to a Jira board should not be able to be deleted. It should throw an error demand the filter be disassociated from any Agile boards.

This can also be fixed with simple ScriptRunner script (was written for JIRA 6.4, agile 6.7 and might not work for newer versions) without accessing database directly.
Make sure that it works for you in yours development environment before running it in production.

import com.atlassian.greenhopper.manager.rapidview.RapidViewManager
import com.atlassian.greenhopper.model.rapid.RapidView
import com.onresolve.scriptrunner.runner.customisers.JiraAgileBean

long BOARD_ID = 0L //board that was bugged
long FILTER_Id = 0L //new filter for that board

@JiraAgileBean
RapidViewManager rapidViewManager

RapidView rapidView = rapidViewManager.get(BOARD_ID).get()
rapidViewManager.update(new RapidView.RapidViewBuilder(rapidView).savedFilterId(FILTER_Id).build())

agree with matt.doar.
Please also bear in mind that jira-administrators are not necessarily database administrators.
This makes the workarounds less usable and more expensive for us (just to repeat myself as for each SQL workaround given here)

A dashboard's gadget does not disappear just because I delete a filter that was used by the gadget. So this is a design bug I think.

It's far too easy to delete a filter and completely break a board in a way that requires a restart. The design could have been to show the board to jira-administrators and board administrators and allow them to pick a new filter. Displaying a warning message when deleting a filter is a nice safety belt but it still doesn't help people to recover from the mistake.

jose.martinspinheiro - could you please create a support ticket at https://support.atlassian.com
That way we can provide you with support specific to your circumstances and with higher security.

Kind regards,
Martin
JIRA Software

We probably have an issue related to this one here, but not because the filter was deleted, but probably because the owner of the main filter was no longer having the permission to administer the projects in the board. This is a bug, isn't it?

Thanks for your comments on this issue. To clarify, as noted previously this is not desirable behaviour, and we will be addressing it with a first step shortly.
This will be to add a warning message advising if a board or boards are using the filter that is about to be deleted.

Kind regards,
Martin
JIRA Software