-
Bug
-
Resolution: Fixed
-
Highest (View bug fix roadmap)
-
6.0.7, 6.6.80, 7.0.0, 6.7.12, 7.1.9, 8.20.10, 9.4.6
-
6
-
84
-
Severity 2 - Major
-
357
-
-
Summary:
Deletion of a filter that is associated with a Rapidboard causes the Rapidboard to disappear from the Agile menu as well as the Manage boards.
Steps to Reproduce:
- Create a rapid board
- Delete the filter associated with the board from JIRA
- The board disappears from the Agile Menu and Manage Boards page.
Expected Results:
- The board should be still be present in Manage boards and when GH detects that it is not having the associated filter, it should request the owner of the board to re-associate it with a filter or with project(s)
Actual Results:
- The board disappears from the Agile Menu and Manage Boards page.
Regression:
NA
Notes:
At the same time the board related data is still available in the database.
Workaround
- causes
-
-
- Closed
-
-
JSWSERVER-10613 As an Admin I want the Sprint Marker Migration to check for orphaned boards
- Closed
- duplicates
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
- Closed
-
- Gathering Interest
- is related to
-
- Closed
-
- Closed
-
- Closed
- relates to
-
-
- Gathering Impact
-
-
- Closed
-
- Closed
-
- Gathering Interest
-
SW-121 Loading...
-
-
-
-
- was cloned as
-
-
- Closed
-
- is cloned by
-
- Mentioned in
- mentioned in
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSWSERVER-6706] Deletion of the Filter Associated with a Board Removes the Board
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.
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!
Sarah Hill
added a comment - This happens more frequently than you would think and breaks other systems that we use with Jira. Please fix this - this bug is unacceptable.
Sarah Hill
added a comment - This happens more frequently than you would think and breaks other systems that we use with Jira. Please fix this - this bug is unacceptable.
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.
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.
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.
Raj Adluru
added a comment - 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.
Thorsten Habich
added a comment - 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
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.
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.
- Support can retrieve your old filter contents if you don't know it
- They then ask you to create a new filter using these contents
- 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
Neal Johnson
added a comment - 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.
Neal Johnson
added a comment - 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.
Neal Johnson
added a comment - 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())
Dieter Greiner
added a comment - 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)
Dieter Greiner
added a comment - 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
I think it is not necessary to inform the user while deleting the filter BUT it would be very helpful to simple display a more detailed message what's wrong with the board which lost the associated filter (currently the board seams to be deleted) - for people not knowing about this bug/"missing feature" it is not clear what's going on and could be a painful job to figure it out.
So I would prefer a solution which simple shows a message "Your board is using a filter that does no longer exists" and make the board still manageable to change the filter settings even if the current used filter was deleted (for whatever reason).
king regards
Andreas Morgner (Scandio)
added a comment - - edited I think it is not necessary to inform the user while deleting the filter BUT it would be very helpful to simple display a more detailed message what's wrong with the board which lost the associated filter (currently the board seams to be deleted) - for people not knowing about this bug/"missing feature" it is not clear what's going on and could be a painful job to figure it out.
So I would prefer a solution which simple shows a message "Your board is using a filter that does no longer exists" and make the board still manageable to change the filter settings even if the current used filter was deleted (for whatever reason).
king regards There is no way you can deem this "Working as Designed". THIS IS A BUG and should be resolved!
If you are permitted to perform an action that will cause breakage in another feature of the application without any warning, then it should be deemed a Bug and code changes implemented to either add a warning message or completely disallow the action that causes breakage.
Just my $0.02
Terry Beavers
added a comment - - edited There is no way you can deem this "Working as Designed". THIS IS A BUG and should be resolved!
If you are permitted to perform an action that will cause breakage in another feature of the application without any warning, then it should be deemed a Bug and code changes implemented to either add a warning message or completely disallow the action that causes breakage.
Just my $0.02
Well, I can see how they see this as not a bug but I find it crazy that they haven't put up at least a warning pop up when deleting a filter . Surely that can't be that hard to do?
This is a bug. I do not agree with Martin's assertion that this is expected, but not desirable behavior. As a jira administrator, it leaves me feeling uncomfortable knowing there are orphaned database records and a missing board after someone deletes a filter associated with said board. If there is no way from the gui to remedy the situation, this is a bug. This also creates work for our users when they have to recreate their board. Atlassian, reclassify this issue and provide us with a plan to fix.
Agreed. This is a bad bug. I experienced it back in March. Spend the rest of the day cleaning up the mess it caused.
Christina
added a comment - Hi,
We run into the same bug too and want this issue to be fixed. 
Chi Sang Tuong
added a comment - Hi,
This is a major Bug in my humble opinion.
People are losing a lot of work.
In the documentation of Jira there should be at least a huge warning. How is it possible for any body to imagine that deleting a filter will lose their boards. Usually objects affected return that the filter is not active anymore, so we can then modify them. Here, it's not even possible !!!
Chi Sang Tuong
added a comment - Hi,
This is a major Bug in my humble opinion.
People are losing a lot of work.
In the documentation of Jira there should be at least a huge warning. How is it possible for any body to imagine that deleting a filter will lose their boards. Usually objects affected return that the filter is not active anymore, so we can then modify them. Here, it's not even possible !!! Andreas Morgner (Scandio)
added a comment - Hi all 
Just as an info - we run into this bug also:
- JIRA Agile v6.7.11 running on
- JIRA v6.4.1
Andreas Morgner (Scandio)
added a comment - Hi all
Just as an info - we run into this bug also:
JIRA Agile v6.7.11 running on
JIRA v6.4.1
Atlassian, if this fix is too large to handle, then a small fix of simply issuing a warning when deleting a filter that is used by an agile board will be waaayyy better than nothing.
Thanks
At the very least, JIRA could throw an exception to prevent what essentially amounts to database inconsistencies. The user would be mildly confused if no pretty warning is shown, but at least the data is intact and doesn't need support to recover the board.
I'm guessing that might be no more than two hours work for a JIRA developer..... of course a foreign key constraint would have prevented it happening but I guess JIRA doesn't use those 
Hi dhergert, the reclassification is based upon this being expected but not desirable behaviour.
Improvements for this issue would likely be a story to improve information or warning when deleting a filter that is used by a board and/or having a way to list boards which do not have a filter with a way to action the assignment of a filter.
Kind regards,
Martin
JIRA Agile
I'm confused with the recent reclassification. This is definitely not a suggestion for a feature, it is not a desired effect for your board to disappear when it's associated filter is deleted. Any insight? Thanks!
Matthias Braeuer
added a comment - What would be the approach to fix this for a JIRA OnDemand instance?
Matthias Braeuer
added a comment - What would be the approach to fix this for a JIRA OnDemand instance? This really is a nasty bug that needs to be fixed. Good JIRA Administrators who are trying to keep their instances tidy by deleting Filters that appear unused are unknowingly destroying agile boards.
Here is a SQL query (MS SQL style) you can run to see what boards are associated with what filters, and any of the rows with a NULL filter are orphaned boards.
SELECT rv.ID ,rv.NAME ,rv.OWNER_USER_NAME ,rv.SAVED_FILTER_ID ,sr.filtername FROM AO_60DB71_RAPIDVIEW rv LEFT OUTER JOIN searchrequest sr ON rv.SAVED_FILTER_ID = sr.ID
I tried using the Greenhopper REST API to fix it by setting the board's filter to a new ID (specifics below), however it gives the same error as when you try and view a borked board (The requested board cannot be viewed...).
| URL | http://jira.url/rest/greenhopper/1.0/rapidviewconfig/filter |
|---|---|
| Method | PUT |
| Content Type | application/json |
| Body | {"id":"95","savedFilterId":"11700"} |
So you need to follow the workaround instructions on Boards Are Not Visible After the Filter is Deleted to re-associate your board with a new filter. Remember stopping/starting JIRA is required (I confirmed that through testing).
We haven't had the pleasure of encoutering this issue yet but it's hard to believe this hasn't been addressed yet.
It is simply unacceptable that this is possible and surely it can't be that hard to implement just a simple warning somewhere at the very least.
Matthew Halladay
added a comment - We also just hit this today cleaning up filters. No warning and the filter does not show a subscription. Took time to recreate the agile board, columns, estimation, etc. Please add a subscription to the filter in the filter view when it is used by a board.
+1 Thanks.
Matthew Halladay
added a comment - We also just hit this today cleaning up filters. No warning and the filter does not show a subscription. Took time to recreate the agile board, columns, estimation, etc. Please add a subscription to the filter in the filter view when it is used by a board.
+1 Thanks. 
Nate Levin
added a comment - Please address this issue. Or at least have a pop up to show what depends on a filter before you delete it.
Nate Levin
added a comment - Please address this issue. Or at least have a pop up to show what depends on a filter before you delete it. We just hit this as well as we were doing some house cleaning on our filters. Lost an important agile board. 
+1 for addressing.
We've hit this, I second the comment that when deleting a Filter, there should be a warning saying there are Boards associated with this filter (like it does with Subscriptions).
This symptom and a workaround has been documented elsewhere.
https://confluence.atlassian.com/display/AGILEKB/JIRA+Agile+board+is+missing+after+deleting+its+filter
https://confluence.atlassian.com/display/AGILEKB/Boards+Are+Not+Visible+After+the+Filter+is+Deleted
https://confluence.atlassian.com/display/GHKB/Boards+Are+Not+Visible+After+the+Filter+is+Deleted
Carol Mirakove
added a comment - +1 for addressing this issue. We face this issue last week and and only one thing what we can do was to find a board in DB and update filter ID to existing one. After restart of JIRA "lost" board appears in Manage Board.
Table AO_60DB71_RAPIDVIEW and SAVED_FILTER_ID param for filter.
jhult : Please raise a support request at our support site https://support.atlassian.com
I just ran into this in our OnDemand instance.
I am a system administrator and I can not even see the board or do anything with it. I have no access to the back-end database to do anything with the filter set for this board.
I had a long-running issue with this, as described in https://support.atlassian.com/browse/JST-60148
NOD
added a comment - It would be good to get Jira to warn that a board is associated even if deleting it from within Jira doesn't get blocked. Same as it does with subscriptions.
Also if a filter is deleted and the board retained with missing saved filter name, it would be good if it still showed the last known filter definition. We've run into cases where admins of boards change, filters get deleted, and new admin mightn't remember how the filter was defined.
NOD
added a comment - It would be good to get Jira to warn that a board is associated even if deleting it from within Jira doesn't get blocked. Same as it does with subscriptions.
Also if a filter is deleted and the board retained with missing saved filter name, it would be good if it still showed the last known filter definition. We've run into cases where admins of boards change, filters get deleted, and new admin mightn't remember how the filter was defined. In relation to GHS-7063:
It's ok, that the filter must be blocked by JIRA, but why is the board completely removed instead of just showing that there is no valid filter for it? This is a check which Greenhopper could perform, could it?
Best regards
Dennis
Dean Mehmet
added a comment - I had a similar problem when I deleted a duplicate user. I didn't realise that this user just happened to own the board's filters - once the user was deleted the boards were no longer available (although i could see issues were still associated with sprints). In the end I got Atlassian Support to recreate the filters and boards for another user. Support suggested disabling users instead of deleting in future.
Dean Mehmet
added a comment - I had a similar problem when I deleted a duplicate user. I didn't realise that this user just happened to own the board's filters - once the user was deleted the boards were no longer available (although i could see issues were still associated with sprints). In the end I got Atlassian Support to recreate the filters and boards for another user. Support suggested disabling users instead of deleting in future. 
Fabian Meier
added a comment - Alright, if nothing is lost and we just loose the ability to open the old board but can restore it by creating a new board, I agree to the classification.
Fabian Meier
added a comment - Alright, if nothing is lost and we just loose the ability to open the old board but can restore it by creating a new board, I agree to the classification. Please note that the deletion of a board never deletes any sprint. A board finds sprints by selecting the matching issues then examining the Sprint field. You can create a new board with the same filter and the sprints will be found by that board.
Thanks,
Shaun
This is not a major bug but a critical one because the boards completely disappear and with them the running sprints. The workaround suggests patching the live production system with a SQL query while it is running - no no no
Fabian Meier
added a comment - - edited This is not a major bug but a critical one because the boards completely disappear and with them the running sprints. The workaround suggests patching the live production system with a SQL query while it is running - no no no
This could potentially have huge impact to an organization operation!
At least have a warning.
+100