Serials in holdings view should be able to sort in ascending and descending order as well as by call number

[Liam Whalen]

Evergreen 2.6
OpenSRF 2.4
Postgresql 9.1
Ubuntu 14.04

Currently, when looking at a serial record in the search results or the record details page, serials are sorted by their call number.

When looking at a serial record, the holdings details should be allowed to appear in either ascending or descending order in either chronological or enumerative order. This should happen in both the meta-record/search results view and the record details screen.

I purpose a new setting opac.holding_sort_type, which will allow the TPAC to know how to sort the serial information.
This setting will have three possible values (asc, desc, or call). asc sorts from oldest to newest, desc sorts from newest to oldest, and call sorts by call number.

This work is already done within Sitka's EG instance. I am going to port it over to master. It adds a new SQL function that produces a value according to the chron or enum value of the serial that can be used to sort it. For serials not produced via the Serial's module, the active date from asset.copy is used to sort the items.

[Liam Whalen (whalen-ld)]

Here is my working branch for master:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/RT16023_to_LP1429317

[Dan Wells (dbw2)]

Liam, thank you for your willingness to jump in with both feet to try and solve this issue. Better display of serial "units" is certainly something I'd like to see incorporated, and it's clear you've given the issue a lot of thought.

That said, as I mentioned in IRC last week, I have some serious concerns about the branch as offered. This may not be an exhaustive list, but here are a few things which stood out:
  1. The fundamental goal here seems to be sorting of serial units, so I would expect any solution to make use of the sort_key column which is purpose-built for this task. (I know you mentioned in IRC already that you weren't aware of this column when you wrote the code.) The sort_key column has been fairly neglected, but the principle of using a pre-built key for sorting is certainly very doable with this data set, and is the best strategy (IMHO) for this type of situation.
  2. There is already an alternate "copy" display for serials (the somewhat mislabeled "fully compressed" display). This branch has a lot of similarities to that display in overall direction, yet the code is wholly separate. I believe there is room to extend or build upon what is there so that, in the end, we have a more unified code path with just enough options to satisfy each local need.
  3. In one spot, the code compares copy counts with serial item counts to determine if a record is fully serial. This won't always work, as a serial unit can have more than one item, but will still be a single copy. In fact, since serial units *are* copies, it seems reasonable to find a way to sniff out the unit-ness of each copy and organize the display accordingly (I think the "compressed" display does something along those lines, but could be mistaken).
  4. I am curious about some of the coding conventions being used in a few places, such as assigning 'undef's to reset vars, or manually rearranging arrays. My initial sense is that a number of lines could be removed or simplified, but maybe they're doing something I don't quite understand at first glance.

With the conference only a few weeks away, rather than try to hash this all out here or in IRC, maybe we can plan to talk about serial copy/unit display in person? Once we are on the same page, I suspect we could make some quick progress on a better unified display.

Thanks again, Liam.

[Liam Whalen (whalen-ld)]

Dan, thank you for taking the time to look over my code. I appreciate your comments. I agree that sort_key is a better option. I wanted to move my ranking code into a database key, but time did not allow me to move the changes into the database rather than calculating the value on the fly.

2. I am not aware of the "alternate" copy display. This code arranges the display of holdings data in the record view, and I did not know of any other method of changing the display in that section.

3. The attempt to determine if an item is serial may be Sitka specific. We have some cases where a record may have one library assign copies as items and MFHD, and other libraries assign copies via the serials module. I welcome a better way to do this, especially if my method is not complete.

4. I was hoping to meet with you at the conference, so that we could discuss this code. I am glad you mention it. I look forward to discussing this with you.

Thank you Dan

[Kathy Lussier (klussier)]

Marking incomplete while these issues are being resolved.

[Jeff Davis (jdavis-sitka)]

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?

[Jeff Davis (jdavis-sitka)]

In IRC, Mike Rylander pointed at bug 1315552, which may result in unrelated changes to evergreen.ranked_volumes. Worth keeping an eye on in the context of this bug.