I’ve been working on a few custom reports this summer, and I’ve noticed (besides the config/store/export/print/email report buttons not behaving as I want them to) that when a
user clicks on a external link to my BES report and is prompted to log in
OR the
user changes the filter
, that the form is submitted using the POST request. This is fine by itself, but since any dynamic content in custom reports have to be handled on the browser client side, custom reports rely heavily on GET requests (since the browser’s JavaScript cannot access POST request). As a result, whenever the user encounters one of the two scenarios above, the GET request variables previously available is erased when the POST request is submitted–essentially breaking my custom report and giving my customers a bad user experience.
In order to promote custom reports and provide a seamless user experience, I humbly submit a behavior change request for BES web reports, such that, when a user is redirected to log in or changes the filters, that the GET request (or the information about the question mark in the URL bar) is maintained. I think everyone will benefit from this change.
That’s a great suggestion. I’ve actually already changed the login behavior for our next major release (8.x) so that Web Reports issues a POST on login (with Username and Password) but then redirects to the original GET. Filtering is going to change a lot in 8.x also, and I’ll definitely keep this issue in mind.
Just a follow up, If you do preserve GET request information, be sure to save the bookmarks (aka info after the ‘#’ in URL).
ex: example.html?var=value#bookmark
I plan to transfer information this way (a la gmail / facebook) to reduce page refreshes while still allowing users to be able to bookmark, or copy/paste the link.
