Closed tampakis closed 3 years ago
Checkout bib 491668. So I'm definitely going to remove the "order" key in the hash since it should only be added if there are actually orders. However, after I remove that, is returning an empty hash preferable over the previous behavior, which would include call numbers and notes about each holding despite not having any items?
It is a tough call @tampakis . The empty hash makes sense because, well, their are no actual items. However in practice it would be nice to have a client be able to expect something come back at /items for a given valid bib ID.
The request system will ask for /items when it wants to know if there are any actionable copies of record at a given location and decide what options should be presented to the user in that context. In this particular instance the annex holding should render an Annex request option with the other two locations being listed as open stack copies.
In practice only a small minority of the no-item records are going to be on order, the bulk of them will be RBSC and Annex records like 491668.
Some on-order bibs have holding records, but no item records like http://bibdata.princeton.edu/bibliographic/9160439/items. The way the get_items_for_bib method was implemented, items on order were never actually included.
get_items_for_bib
only gets called when there aren't any holding records, but because of line 140 getting called outside of the conditional, nothing actually gets returned for on-order records.I played around with fixing up the method and I think the desired behavior would be to only include a holding location in the bib/items view if it actually includes an item. If there aren't any items, then include a dummy holding location called "order" with the approved POs.
My first commit includes itemless holdings. My second one removes them: