Before customizable Best Hold Selection Sort Order was implemented, the
non-FIFO hold order considered more-constrained holds before
less-constrained ones on the assumption that there would be more copies
available to less-constrained ones. That ordering didn't make it into
the BHSSO implementation, so this commit corrects that by sorting this
part in descending selection depth order rather than the default
ascending.
This is not relevant in most cases, but when soft hold boundaries are
used, and during the transition from a non-resource-sharing to a
resource-sharing enviroment, it can have an effect if "depth" is
selected as a BHSSO component.
0b24af2...
by
Jane Sandberg <email address hidden>
Revert "lp1895699: search results page lets user know that course materials filter has been applied"
This reverts commit 828a6f871fbe04d85c4c7132c37340b7f1f19811.
This led to a failure in live_t/35-multiclass-search.t, and sometimes led to cases where searching
with the course materials filter would time out or return an error.
The issue lies with the dynamic_filter_compile subroutine in QueryParser.pm. It makes an
assumption that any filter with an entry in config.record_attr_definition will also have
entries in config.coded_value_map. This db migration had no such coded_value_map entries,
so it added a function call to the query_int_wrapper function, which works in some environments
and doesn't in others. We don't want that!