Monographic parts in sample data live in non-holdable copy locations
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Low
|
Unassigned | ||
2.12 |
Fix Released
|
Low
|
Unassigned |
Bug Description
The Concerto sample data includes two bibliographic records with copies that have monographic parts. In both cases, the copies that have monographic parts live in non-holdable copy locations. This makes it difficult to use the sample data for anything related to part holds.
We should have some parts copies in the dataset that are available for holds.
One expedient solution is to change the Thesis copy location in the test data to be holdable. On both records, most of the parts copies are landing in that Thesis copy location.
Another better solution might be to add bib records to the dataset for titles that in real life are likely to have parts (a popular DVD set or a multivolume work). Instead of randomly generating copy assets for these bib records, we could consider assigning them copy locations that we know are holdable. However, I wouldn't want to pursue this solution until we make progress on bug 1672434.
summary: |
- Monographic parts in sample data lives in non-holdable copy locations + Monographic parts in sample data live in non-holdable copy locations |
Changed in evergreen: | |
milestone: | 3.0-rc → 3.0.1 |
Changed in evergreen: | |
milestone: | 3.0.1 → 3.next |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
I have a working branch at http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ kmlussier/ lp1672435- make-theses- holdable that implements the more expedient solution in a way that I thought would be least disruptive to the existing tests.
After loading the branch, I got failures in three perl live tests: 02-simple_circ.t, 09-lp1198465_ neg_balances. t , live_t/ 24-offline- all-assets. t However, I get the exact same failures on a clean master system. I'm guessing the problem is related to something on my local system rather than with the above code, but somebody else may want to verify that it doesn't break any tests.