Thanks for taking the time to raise this issue.

Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts. In part, that means concentrating on those issues that resonate the most with our users.

I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue.

Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me.

Kind Regards,
Kerrod Williams
JIRA Product Management
kerrod.williams at atlassian dot com

I agree this could be useful, although I understand the complexity in the back end. Here's how I would use it - I have different issue types that I want different columns to show; let's take Activity and Story as examples. When I have my users look for Activities, I have them click on a saved filter to get the correct columns to show (because I've edited the filter's column order), and then filter down from there based on component, assignee, etc. Stories have different columns, but I have customers follow the same process. These searches are usually just for the short term, so saving as another filter creates the problem mentioned by Brent. Does anyone have any other work arounds?

Saving the filter is a decent work around but it can result in the user having numerous filters when this is done often. For ourselves we have a saved "template" filter used to generate an export we do with every release to get a snapshot of the unresolved issue for that release. This has defined columns that we want in the report so we save the column order with the template filter. Now our users need to save their changes to the filter (just pretty much changing the project and affects version) and end up with a lot of saved filters. If they delete the filter the link in the export no longer works to recall how the export was generated.

After a bit of investigation, I have found the cause of this issue.

When you make changes to the saved filter, the modified flag on the SearchRequest object is set to true. When re-rendering the export links in the IssueNavigator, it sees that the SearchRequest has been modified, and so it constructs a link that contains all the parameters of the filter explicitly sans the filter id. If the filter had not been modified, the link would simply contain the filter id, as the parameters can be looked up from storage.

The problem here is that, without the filter id (or the original SearchRequest object), the code determining which column layout to use does not have enough information to realise that there is a custom column layout for it.

Thankfully, there's a really simple workaround - if you re-save the filter before exporting, the correct column layout will be used.

Given that this issue is non-trivial to fix and there is a simple workaround available, we are unsure as to when this will be fixed. When we have the time, we will update the Fix For version of this issue to inform you that it has been scheduled.

Thanks again for reporting!
Michael

Michael,

This should be very similar to the other issue you have fixed.

The fix for this issue has not been able to make it into JIRA v3.12. We are hoping to incorporate it into v3.12.1. As of writing however, there are 163 items scheduled as Fix For v3.12.1. We will not be able to include all of them.

Yep. If the filter is in modified state, JIRA will believe it is not saved and use user's column order. I see what you mean though.