Comment 5 for bug 1429317

I've been taking a fresh look at this issue, hoping to find an approach that's more acceptable to the community.

Looking at unapi.holdings_xml and evergreen.ranked_volumes, it appears that the main holdings display in the OPAC is currently sorted by the following criteria, in this order:

1. org unit, with search scope/pref lib coming first;
2. availability, via the evergreen.rank_cp function;
3. call number, using acn.label_sortkey.

I see two possible modifications for serials. First, we could detect whether a given copy is a serial unit; if so, then instead of using acn.label_sortkey, we could use either serial.unit.sort_key or a date-based value (probably derived from active_date), depending on the value of the existing serial.default_display_grouping org setting ("chron" or "enum").

Secondly, we could make availability irrelevant for ranking serial units, on the assumption that for most use cases it's preferable to see serial holdings by date/volume-and-issue-number, regardless of availability. The easiest way to do this would be for evergreen.rank_cp to always return the same value for serials. Again, this would require detecting whether an item is a serial or not.

(One way to detect serial units would be with something like 'SELECT tableoid::regclass FROM asset.copy WHERE id = x'. There may be better ways to handle that.)

Does this seem like a viable approach?

As for the compressed serial holdings view, I don't see a good way of integrating what it does into the main holdings display. One option would be to make the compressed view more prominent, and suppress serials in the main holdings display. That wouldn't work for Sitka, since we have serials where one library branch enters its holdings as regular copies, and others enter them as proper serial units; incomplete holdings info in the main display would be confusing. But maybe this would be a handy option for libraries that are more consistent about using the serials module?