Comment 3 for bug 1996818

I've reviewed this patch and have a couple reservations:

[1] There are issues if you start a search-to-hold, then open individual titles in separate tabs. Consider:

a. Select a patron and click the place hold button.
b. Catalog component comes up indicating that you're intending to place a hold.
c. Do a search.
d. Open one of the results in another tab, then realize that it's not the title you're looking for, then close it.
e. As a consequence, the session cookie gets deleted but the catalog service in the original table is still in search-for-hold mode - and you can in fact place a hold.
f. But if you instead open a second title from the result set in a new tab, that new tab is not in search-to-hold mode because the cookie is gone.

That's inconsistent and hard to explain to a staff user, but arguably is still an improvement over the current state of affairs. Doing more work to coordinate between tabs might smooth this out, but need not hold up some version of this patch.

However:

[2] I'm not sure I agree that placing a hold should end the search-to-hold session, as it prevents somebody from readily placing multiple holds for a patron in a single session. Consequently, at the moment I'd be more in favor of a version of the patch that omits the change to hold.component.ts.