That’s an interesting idea @pat. Basically, what you’re describing is a breadcrumb that reflects the user’s navigation history, instead of the navigation tree/hierarchy that it reflects now.
Something like that might be possible in theory. The first thing to figure out is how/where to store the additional “state” this would require. By “state” I mean temporary information about which pages the user was on recently, which would be different from moment to moment.
It also raises some questions. The potential combinations of user navigation flow are endless, so what would the specific rules look like for this?
If you went to a log record directly by typing in its URL, what would the breadcrumb show?
On the other hand, if this is the main problem you’re running into, maybe there’s another solution. Maybe the breadcrumb isn’t the best option to explore.
I believe there’s some special browser caching when you use the browser’s back button that means it didn’t reload the page from the server - at least for recently visited pages. The answer here is to refresh after going back.
You can avoid a few of the clicks by long pressing (click and hold) on the back button, then selecting the “Maintenance logs” page from the resulting history menu.
In this sort of scenario I usually open a new tab for each log I need to edit, then close it once I’ve finished editing/saving that log update. (Tree Style Tab or Sideberry makes this way easier to keep track of.)
Another strategy like that would be to enable a module that allows the edits to be done directly without navigating - e.g. Edit in-place field | Drupal.org or I think there was a some discussion in the past of a way to open the entity (log in this case) editor in a panel on the side.
This is kind of implied by Mike’s answer, but to expand on that; the reason the breadcrumbs don’t work that way right now is that they are based only on the data for the page you’re currently on - not how you got there. In this case, the maintenance log might apply to multiple pieces of equipment or might reference other assets so there are lots of ways one might have gotten to that log page. (Drupal can’t tell from the current page which of those you’d like to return to.)
One nifty option that Drupal provides is the ?destination query parameter. If you go to /log/1/edit?destination=asset/1, then after you submit the log 1 edit form, you will be redirected to asset/1.
We could potentially add that in more places, so that you return to the place you originated from when you clicked “Edit”.
The limitation is: ?destination only works when you load an edit form URL with it. The links on log lists go to the Log’s “View” page (not “Edit” form). If we added ?destination to those links, it wouldn’t work, because there is an additional user click required to get to the “Edit” form, and the ?destination is lost in that step.
One thing we could do is add an “Edit log” link to all log list items, which pointed directly at the /log/[id]/edit path with a ?destination parameter set pointing back to the log list page. This would take you directly to the log edit form, and back to the list after the form is submitted.
New features aside, @Symbioquine’s approach is what I would recommend right now too. Browser tabs are a very powerful navigation tool. I always open new tabs for individual records I want to edit, just out of habit at this point.
That could be a useful, but as @Symbioquine says, it may take too much valuable space.
I was thinking of the action drop-down menu too, but that’s also kind of unlogical navigation for editing just one log. Don’t think I would be using it.
But Ctrl-click and Ctrl-W works fine. I use it a lot too