First of all, I have to say that I have really enjoyed using the navigation buttons since they came out, they are huge time savers, however, I’ve noticed some erratic behavior there when the filtered list changes.
Suppose I use go to the invoices of a particular customer or use the search to filter the invoices tab
The first three invoices are #2842, 2781 & 2761
I go to view the first invoice (which also enables navigation)
Then I edit the invoice and change the customer to another account and get back to the same view screen. The invoice is not part of the list anymore, but I still expect two things:
- I get back to the view screen of the invoice I just edited to view my changes, in case I needed to do more changes, print or whatever.
- I return to my filtered list where I can pickup navigation where I left.
Luckily, Manager does both things as expected and does not refresh the filtered list until I navigate away from Invoice #2842.
The next part bugs me; when I click on next, the navigation moves from 1st entry in the old (#2842) list to the 2nd entry of the new list (#2761) and skips the 2nd entry in the old list (#2781) which is now the first entry.
The key to understanding this behavior lies in something you wrote:
In the sequence of events you illustrated, you have not navigated away from #2842. You are still viewing it. The navigation counter still shows you are on list element 1 / 25. If you use the Back button repeatedly to go all the way back to the filtered list, then you will have navigated away from #2842. Viewing another invoice will then reset the list (and counter).
But how about this:
- The user clicks navigation
- The index moves on the old list and gets the link.
- The list is then updated
- Search the new list to get the new position.
- Follow the link.
That wouldn’t skip any list entries.
You are too far down in the weeds for me.
I see how this might seem like a bit too much but please bear with me on this one.
I have a UAE client who needs to allocate VAT by region for filing purposes. The region information isn’t required on the invoice but it’s required eventually. I setup 7 tax codes, one for each region + an 8th code to serve as a blanket tax code.
The salespeople – who aren’t qualified to determine the place of supply – select the blanket code when in doubt just to release the invoice and then I change the tax code applied to the correct region.
I usually do that by going to tax summary, drilling down the umbrella code and scrolling through them 1 by 1.
When I though I had finished, I found out that half of items are still there. So I repeated it again and ended up with half of what was left the first time.
The current scrolling methods works really well when you don’t change the list but when you do, it becomes hacky.
It’s so inefficient to the point that skipping the view mode and editing directly from the table view and then going back to the table and manually selecting the next transaction is more or less the same amount of work.
Plus, the steps are given are just to show how it might be possible. I am sure @lubos has much better methods to solve this problem.