Simplified Pull List - Need fuller title

Bug #1048822 reported by Ben Shum on 2012-09-10
This bug affects 7 people
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen master

In using the simplified pull list, a staff member noticed that the titles shown/printed in the Simplified Pull List only lists the first part of the title entry. This was especially problematic for identifying unique records where the subtitle held important information. An example was like DVD series where the subtitle contained the season number.

It would appear that the current interface is using the title from simple record. The proposed change would be to use a fuller title string similar to ones from previous hold pull list interfaces like the alternate print strategy.

Changed in evergreen:
status: New → Incomplete
Changed in evergreen:
status: Incomplete → Triaged
Kathy Lussier (klussier) on 2013-01-04
Changed in evergreen:
status: Triaged → Confirmed

reporter.super_simple_record uses only the 245a for the title.

I'm wondering if the best approach to addressing this is to expand the title to include subfield p and n to include things like "Season 1".

Or should there be a new reporter.super_simple_record field that contains that info? Something like title_np. So that the behavior of the title field doesn't change.

I would rather just have one title field, but there may be good reasons not to change how it behaves.

Examples: Here are some examples of records that are difficult to identify from the current simplified holds list because there are many titles with the same 245a. Staff currently have to compare barcodes which takes extra time, or look up the title first in the staff client and make a note on the list.

"kung Fu Panda, legends of awesomeness. The Scorpion sting"
"Kung Fu Panda, legends of awesomeness. Good croc, bad croc"

Outside of the simplified pull list, I've found that I often need to pull in the 245 n or p in other reports that go out to staff so they know which specific title the customer wanted, so fixing this would help out in many other reports.


Here is a branch that adds the first occurrence of a 245(b|n|p) to the title in reporter.super_simple_record.


It appears to work on a 2.8.4 test system. Who wants to try it in production? The reporter.materialized_simple_record table needs to be rebuilt for this to show up, which might take some time for large numbers of titles.


tags: added: needsreleasenote pullrequest

I'll add release notes if this seems like a reasonable approach to this problem.

Chris Sharp (chrissharp123) wrote :

I tested this and see that it works, but the resulting title can be very very long (ex. "history of the old cheraws containing an account of the aborigines of the pedee the first white settlements their subsequent progress civil changes the struggle of the revolution and growth of the country afterward extending from about a d 1730 to 1810 with notices of families and sketches of individuals"). I consulted one of our cataloging experts and she suggested not including subfield $b in the result.

Galen Charlton (gmc) wrote :

I note that the metabib display fields enhancement (bug 1251394) now has a fair amount of momentum. It provides a more general mechanism for parsing out bits of bib record to display, and if it gets baked sufficiently for 3.0, using it as a basis for a fix for this particular bug (as it might manifest in the web staff client) would be my preference.

However, I'll reevaluate later this summer in case it looks like metabib display fields won't make it in after all.

(Galen, wearing RM hat)

I've updated the commit for this issue with a slightly different strategy.

Exclude the subfield b, include all of the n and p subfields in the same order they appear in the 245.

With our data this results in an increase in the number of titles over 60 characters by 302 out of 240,000 records.

The performance seems to be pretty close to the original. When viewing all records with 290K bib records the default takes 14-16 seconds and the new version takes maybe a second longer. The planning time takes a few ms longer.

I end up using reporter.super_simple_record for all sorts of other reports that are sent to staff, so fully identifying a specific copy will help for all of those reports.


We have been using this change in production now for a few days and I haven't heard any problems yet. It really helps with TV series DVDs in the simplified pull list. They used to need to look each one up to find out what season and discs the hold was for.

Dan Pearl (dpearl) wrote :


Changed in evergreen:
assignee: nobody → Dan Pearl (dpearl)
Dan Pearl (dpearl) wrote :

Signed-off-by: Dan Pearl <email address hidden>

Behaves as advertised. Thank you, Josh.

Changed in evergreen:
assignee: Dan Pearl (dpearl) → nobody
Dan Pearl (dpearl) on 2017-07-28
tags: added: signoff
tags: added: signedoff
removed: signoff
Changed in evergreen:
milestone: none → 3.0-alpha
Kathy Lussier (klussier) on 2017-07-31
tags: added: xulclient
Kathy Lussier (klussier) on 2017-08-29
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Kathy Lussier (klussier) wrote :

Thank you Josh and Dan! I added a release notes entry and merged the branch to master for inclusion in 3.0.

Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers