In a few versions earlier, “RF” used to force a refresh instantly. Now I have to wait wait several seconds (usually 3-5), or even have to press RF multiple times before my filtered list is refreshed.
Is RF to force a refresh still in use? or is it replaced by some kind of timer based refresh functionality?
This is quite easily reproducible and applies in most cases where one would want to make a RF
e.g.
Apply a filter (e.g. based on time e.g. due:now OR based on hashtag e.g. #active)
In another window add (or remove) an item that relates to the above filtered view. This change should result in either an addition or removal of an item from the filtered view in the other window
Now go to the filtered view window and press RF When I checked this morning, it took about 7 seconds before the view was refreshed. There was no progress indicator either that a pending operation was on-going.
Pls. note that a few versions back (could be several months ago), this was working just fine. A RF would behave as expected and instantly refresh the list.
I’m afraid rf never picked up changes from another tab, it refreshes view only according to the changes on the current page. Like, you filter a page by a tag, remove this tag for one of the filtered items, press rf to update page view to exclude item with removed tag.
I agree that what you’re describing is an expected behaviour, but it never worked this way. For external changes, we have up to 10 seconds delay for data update.
Hi Kir, Is it possible to modify the behaviour so that RF also does a data refresh? (i.e. pick up external changes).
Usually the user will not do a RF, but if and when he does, he should get the latest results.
RF, in my opinion, should be an “ajax refresh” alternative and a convenience to the user to avoid having to do a Page Refresh (F5), that also causes losing the context and feels slow.
I mean RF by its definition should be a full refresh from the database, and not just a local cached view refresh.