Let's say you have the following issue filter: http://localhost:8086/secure/IssueNavigator.jspa?mode=hide&requestId=10000.

Back in JIRA 3.6, the XML view for that filter was: http://localhost:8086/secure/IssueNavigator.jspa?view=rss&&query=broken&summary=true&description=true&pid=10000&tempMax=25&reset=true&decorator=none

And in fact you could remove parameters to simplify it down to: http://localhost:8086/secure/IssueNavigator.jspa?view=rss&pid=10000&decorator=none

(Aside: you need the "&decorator=none". Without it you get malformed XML.)

Similarly, you can simply add "?view=rss&decorator=none" on to the original filter: http://localhost:8086/secure/IssueNavigator.jspa?mode=hide&requestId=10000&view=rss&decorator=none.

These all return XML for just the correct issues for that issue filter.

In JIRA 3.7 we changed the URL for XML feeds, and introduced RSS feeds. The equivalent RSS feed URL in 3.7 is: http://localhost:8080/sr/jira.issueviews:searchrequest-rss/10000/SearchRequest-10000.xml. Quite different.

If instead you try using the 3.6 syntax, adding "?view=rss&decorator=none" on to the original issue filter URL, it returns an XML view, however it does not return the correct issues for that filter. Instead it returns all the issues that the user has access to.

Aside: in fact it has redirects to the following URL: http://localhost:8080/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?mode=hide&requestId=10000&&decorator=none

You get the same (incorrect) result with just adding "?view=rss". That is, you don't need the "&decorator=none".

Why is this perhaps important? Anton tells me that he believed that when we changed the URL for XML/RSS feeds back in 3.7, we tried to make sure that the old 3.6 links would still work, in case someone had saved them in their browser or in an RSS feed viewer. It appears that we have not done this correctly.

If you think it is important enough, we should fix this so that adding "&view=rss" to an issue filter returns the correct set of issues for that filter.

An important thing to note is that there does not appear to be a security/permissions problem here. Although the XML feed with the "?view=rss" returns an incorrect result, it still only returns all the issues that the user has access to. It does not return other issues that the user does not have permission to view.

And of course the workaround is to not append "?view=rss" onto the URL of a search filter.

The same problem exists in version 3.12.1, and hence presumably everything in between.