Redmine

+1

This is the one that bit me but I often see cases where Redmine gives the 'wrong' results because I am moving between active tabs. This is such a fundamental breach of basic web application principles that I am quite dissapointed - surely we need to get Web 1.0 right before worrying about Web 2.0 bling?

For the issue you're reporting, I totally agree it's not OK. But it may be a more general issue about "filters kept in session". I can provide a patch for these specific links, but now it depends on where we want to place the cursor... You talk about other places where you saw this problem, can you list them here ?

Anyway, about what you present as a "Side issue", it's a rails problem (if any) : flash messages are kept in session and deleted when the next page is displayed. If you open many tabs some flash messages are not displayed where you expect but I don't think it's a big deal...

The same root cause (lack of context in the URL) also makes using the back button near impossible. Do an issue query, then scan forward several pages by hitting the 'Next' link. Then click on a link to an issue. Then hit the back button. The user will return to the first page of the issue query. The user now has to renavigate to page #x - hopefully they remember what page they were on!

Another example of extremely annoying non-Tab-safe behavior is when you open multiple queries in seperate tabs. Go back to the first tab (first opened query) and hit the next button. You will now see page 2 of the last opened query (not the first opened query).

Oh, another problem with the back button is that when you click a link to an issue, and then hit the back button, your query (if non-saved) will be cleared out and you'll have to re-create the query again.

related to #3494

Not sure, but this might help:

http://www.contentwithstyle.co.uk/content/fixing-the-back-button-and-enabling-bookmarking-for-ajax-apps

This also?:
http://code.google.com/p/reallysimplehistory/

I like modifying the URL with a '#' mark to designate the page number a little better, mainly due to it's adherence to KISS. However, it still doesn't solve all problems.

Related to #5138.

related to #657

In #7594, I've created a patch to temporarily solve this problem until a real solution exists. It disables Ajax updates and uses direct linking for pagination.

While the patch helps, I think the bigger issue is the fact that filters are kept in the session.

Very true.

Solving this would make it very easy to collaborate with others as well.

For instance, if I want to provide someone with a link to a list of issues, I currently have to save the query as public and send it to them.

I should be able to just send them the url.

+1

I thought that was where we were heading with a RESTful API?

I'm going to change the issue filter requests to regular GET requests (non-AJAX) so that the URL actually reflects the filters being applied. All these filters parameters need to be added to pagination and export links too, so that 2 tabs with different filters can be used at the same time. This will solve the problem initially described here.

Pagination links should be turned into regular GET requests as well, as there's a lot of issues reported about the behaviour of the browser back button (and I don't really want to add javascripts hacks to fix the browser history).

I think that storing the last query in session is still needed so we get it back when clicking the 'Issues' tab after navigating away from the issues.

Agree with all points, will be good to keep filters when using f5 to refresh the query page.

Hope this won't have too much impact on performance ; the list is updated immediatly after using the Apply button as for now.

The impact is not so big, same difference as today between clicking the 'Apply' link and the 'Issue' tab.

Yes. I liked the "Loading..." message too.

Doesn't a proper technique to keep using Ajax and having an up-to-date url already exist ?

Just ran some UX "tests", you're definitely right, this should be changed to GET request.

Should it be closed?

Question regarding this comment in http://www.redmine.org/issues/1965#note-18 by JPL:

I think that storing the last query in session is still needed so we get it back when clicking the 'Issues' tab after navigating away from the issues.

Personally I dont find that a feature. It seems that when I click the Issues tab what I get is different each time, depending on my history, and rarely seems to match what I want. If I am clicking on the tab rather than one of my saved queries within the interface, or one of my many bookmarks, then my intention will usually be "All Issues" so that I can construct a new custom query that I have not saved previously.

I am not being snarky here - I am sure that the current behaviour was implemented based on user requests and is probably used and loved by many, just saying, for me it has no value and perhaps this is the right moment to ask the question of others - is this behaviour worth preserving?

PS This issue got no attention for so long I had all but given up hope. I am really glad and grateful to see all the effort that is going into these changes - the refactorings are quite tedious and tricky and do not get a lot of recognition due to the concealed nature of the problem. Many thanks!

Addendum - perhaps storing the last query in session was intended as a substitute for a working 'Back' button and if we fix Back behaviour it wont be needed any more?

I agree. But as you said, some people may be used to this behaviour and I don't want to simply remove it.
Should we consider to add a user preference, like "Remember the issue filters during my session" or something?

I'm used to this behavior and this may be particularly useful when switching from Issues tab to Gantt tab and vice versa.
Maybe is there some specific query settings which should be stored in session and some others no (just a thought).

A user preference is always the nicest way to treat interface changes/adaptations. That doesn't leave high-hysteresis users in the cold water, while it's possible to implement changes that seem to make more sense for others. Go for it!

Etienne Massip wrote:

Is it done for revisions list too ? If not, I think that it would be usefull ?

Looks like it was already tab safe, although I thought I've seen some place it was not ?!

Sorry for noise...

So that issue can get closed, until other reports?

I think that if the behavior has to change, it ought to be something that would address #7360 (Issue Custom Query: Default Query). Each project should have a default Issue query, and would be nice if it were overridable per-user (one user prefers the "Only my issues" query while the project manager prefers the "Priority 1 bugs" query).