Clicking on a link to go to another page of results resets all filters

[David Platten]

Clicking on a link to go to another page of results resets all filters in both the ctfiltered.html and dxfiltered.html pages.

[David Platten]

I suspect this has something to do with me changing the method for the form submission from "GET" to "POST". Changing filter values in the form and then clicking on "submit" works fine (the form uses "POST", and the filter values are present in "request.POST"). However, if you then click on a link to go to page 2 of the results all of the filters are reset and you are shown page 2 of all of the data, rather than page 2 of your filtered data ("request.GET" is pretty much empty).

Not sure how to sort this out at the moment. One idea that springs to mind is to expand the userProfile data to store the current filters. This would then be persistent and could be read, used and changed as appropriate.

http://djp-openremdemo.rhcloud.com/openrem/ exhibits the problem http://demo.openrem.org/openrem/ does not.

[Ed McDonagh]

Why was it changed from a GET to a POST? GET has the parameters in the URL, which is as far as I know how the filtering thing works. POST sends the data in the HTTP message body. I'm surprised the filtering works at all... but it does!

[David Platten]

If the request method was POST then all GET data is forgotten, causing a problem (refs #193). I have solved this by setting request.GET equal to request.POST for all POST requests. This preserves the request data whichever request type was made. This fixes issue #193.

→ <<cset 3f06535ae364>>

[David Platten]

If the request method was POST then all GET data is forgotten, causing a problem (refs #193). I have solved this by setting request.GET equal to request.POST for all POST requests. This preserves the request data whichever request type was made. This fixes issue #193.

→ <<cset 3f06535ae364>>

[David Platten]

@edmcdonagh , I changed the filter form method from "GET" to "POST" because "GET" was causing problems with the chart options. It all seems to work OK now.

[Ed McDonagh]

Glad you have it sorted. I'm worried about the form beginning and ending though - in the template you have a form starting in one div and ending in another. In reality the browser decides that isn't what you wanted and ends the form for you after the filtering section, and ignores the form closure tag in the second section. And has a submit input that is outside a form...

[David Platten]

Moved the opening and closing form HTML tags so that they correctly contain all the form items and divs. Also auto-indented both files using two whitespaces for everything. The form tag adjustment relates to a comment made ref #193.

→ <<cset 6aa60bd5dbf5>>

[Ed McDonagh]

@dplatten is this still fixed after we went back to POST for the export issues in #204?

[David Platten]

Hi @edmcdonagh. I've just checked - this is still fixed.