Patrons can now delete titles that they do not wish to appear in their Check Out History.
Deleted titles will also not appear in the downloaded CSV file.
When disabling checkout and/or holds history in the public catalog’s Search and History Preferences tab, patrons will be warned that the operation is irreversible when history data exists that will be deleted as part of the update.
The list of copies on the catalog’s record details page now includes the part label in the default sort order.
Specifically, copies are now sorted by (in order), org unit, then call number, then part label sortkey, then copy number, and finally barcode.
Previously, the hierarchy was org unit, then call number, then copy number, and finally barcode
A common usage of the catalog is to do a search in a restricted scope, like a local library. When the results are lacking, the search is repeated in a consortium-wide scope. This feature provides an optional button and checkbox to alter the depth of the search to a defined level.
This feature is enabled by default and can be configured in the Depth Button/ Checkbox section of config.tt2.
A limiter to exclude electronic resources from search results is now available on the advanced search screen and from the search results page. This limiter will exclude any search results with an item form of o or s. This limiter will be applied on top of any other format limiters used in the search.
The checkboxes are disabled by default. To display them in both places, set the ctx.exclude_electronic_checkbox setting in config.tt2 to 1.
Evergreen’s unAPI support now includes access to many more record types. For example, the following URL would fetch bib 267 in MODS32 along with holdings, volume, copy, and record attribute information:
https://example.org/opac/extras/unapi?id=tag::U2@bre/267{holdings_xml,acn,acp,mra}&format=mods32
To access the new unAPI features, the unAPI ID should have the following form:
tag::U2@
bre
(bibs)
biblio_record_entry_feed
(multiple bibs)
acl
(copy locations)
acn
(volumes)
acnp
(call number prefixes)
acns
(call number suffixes)
acp
(copies)
acpn
(copy notes)
aou
(org units)
ascecm
(copy stat cat entries)
auri
(located URIs)
bmp
(monographic parts)
cbs
(bib sources)
ccs
(copy statuses)
circ
(loan checkout and due dates)
holdings_xml
(holdings)
mmr
(metarecords)
mmr_holdings_xml
(metarecords with holdings)
mmr_mra
(metarecords with record attributes)
mra
(record attributes)
sbsum
(serial basic summaries)
sdist
(serial distributions)
siss
(serial issues)
sisum
(serial index summaries)
sitem
(serial items)
sssum
(serial supplement summaries)
sstr
(serial streams)
ssub
(serial subscriptions)
sunit
(serial units)
/
biblio_record_entry_feed
class, multiple IDs separated
by commas)
bre.extern
(information from the non-MARC parts of a bib
record)
/
and org unit; "-" signifies
the top of the org unit tree
/
and org unit depth
/
and a path. If the path
is barcode
and the class is acp
, the record ID is taken
to be a copy barcode rather than a copy ID; for example, in
tag::U2@acp/ACQ140{acn,bre,mra}/-/0/barcode
, ACQ140
is
meant to be a copy barcode.
&format=
and the format in which the record
should be retrieved. If this part is omitted, the list of available
formats will be retrieved.
The stock indexing definitions now include a search and facet index on the form/genre field (tag 655). This allows genre links in the public catalog record display to retrieve works in the same genre. The public catalog genre links will no longer display content from the 659 MARC fields.
The genre facet will also display by default in the public catalog. A partial reingest during upgrade is required to use this index.
Catalog search now limits the number of facets retrieved per defined facet field. Setting a limit is useful so that `open-ils.cstore backends don’t end up needlessly consuming memory when fetching facets for a large result set; if a broad search retrieves over 10,000 author facets (say), even the most persistant user is not going to actually look at all of them. Fetching fewer facets can also slightly speed up generation of search results.
The limit is controlled by a new global flag, search.max_facets_per_field
,
whose label is "Search: maximum number of facet values to retrieve for
each facet field". The default limit value is 1,000, but lower values
(e.g., 100) are perhaps even better for most catalogs.