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. 

lexek-92, thanks so much! Just used this successfully in v7.9.2 with ScriptRunner 5.4.12.

But still, why do we need ScriptRunner to take care of basic functions like this? For heaven's sake Atlassian, just stop letting people delete these filters!

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.