Non-MFHD summary holdings display (serials) shows regardless of scope in TPAC

[Kathy Lussier]

Evergreen version: 2.2.3

When using a non-compressed serials holdings display, tpac will display holdings statements from all libraries even if the user was scoped to a specific library.

See as examples

http://evergreen.noblenet.org/eg/opac/record/1797638?query=new%20yorker;qtype=keyword;locg=2;expand=issues#issues

and

http://bark.cwmars.org/eg/opac/record/527343?query=new%20yorker;qtype=title;locg=142;expand=issues#issues

Ideally, the display would only show holdings statements from the scoped org unit and its children, as is done with a compressed view, with the possible option to see more holdings from other libraries.

[Dan Wells (dbw2)]

I’m no longer certain that this is actually a bug, at least not as described here. In my testing, the MFHD records scope properly provided that ‘owning_lib’ attribute is set properly in serial.record_entry. The interface only allows you to set this when you first create the MFHD record, so that might be masking the problem for some libraries.

Please look into this and see if this is the case. To correct it, you might try something like:

UPDATE serial.record_entry SET owning_lib = (SELECT id FROM actor.org_unit WHERE name = 'Example Branch 1') WHERE marc LIKE '%Example Branch 1%' AND record = 2;

substituting your branch name for ‘Example Branch’ and your bib record ID for the record you are testing for the ‘2’ in “record = 2”. If that works, and assuming your branch names are completely unique, you could be brave and update all the MFHD records for a single branch by removing the “AND record = 2” portion entirely.

If anyone can otherwise confirm this bug, please do post the setup required to make it happen. Thanks!

[Kathy Lussier (klussier)]

Hi Dan,

In looking at the example at http://egtraining.noblenet.org/eg/opac/record/1797638?query=new%20yorker;qtype=keyword;locg=2;expand=issues#issues, I ran the following SQL query to see if this owning library were set correctly.

SELECT id,record,owning_lib FROM serial.record_entry WHERE record = '1797638'

The results are:

"id","record","owning_lib"
"117","1797638","4"
"876","1797638","15"
"949","1797638","18"
"1038","1797638","18"
"1134","1797638","22"
"1347","1797638","26"
"218","1797638","5"
"8545","1797638","44"
"8910","1797638","37"

However, in digging further, I think I've found the problem isn't with the MFHD records that people manually add. The problem is with the holdings statements automatically generated from the serials module.

For example, when I'm scoped to Beverly Public Library (http://evergreen.noblenet.org/eg/opac/record/1797638?query=new%20yorker;qtype=keyword;locg=2;expand=issues#issues), I see:

The manually-entered MFHDs for Beverly's two branches
The automatically-generated holdings summaries for Lynnfield and Marblehead.

When I'm scoped to the NOBLE branch, I see the automatically generated summaries from the Lynnfield and Marblehead libraries again while also seeing the manually-entered holdings statement for the NOBLE branch.

When scoped to Marblehead or Lynnfield, I see their textual holdings statement alongside the generated holdings summary http://egtraining.noblenet.org/eg/opac/record/1797638?query=new%20yorker;qtype=keyword;locg=26;expand=issues#issues.

I guess the bug should really be that the automatically-generated summaries should follow the same rules as the manually-entered holdings statements.

[Dan Wells (dbw2)]

Kathy, this new information helped a lot. I think I have pinpointed the source of the problem; please check it out:

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

Thanks,
Dan

[Kathy Lussier (klussier)]

It works for me! Signed off at

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

Thanks so much Dan!

[Dan Wells (dbw2)]

I was about to push this on with Kathy's signoff, but noticed a small error in my code. It actually isn't causing any problems, but it should really be fixed as part of this bug (since this bug contributes to the error).

Please check it out here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1078787_sdist_tpac_scoping_fix_small_fix

user/dbwells/lp1078787_sdist_tpac_scoping_fix_small_fix

This branch is rebased and includes Kathy's signoff plus my small fix.

[Kathy Lussier (klussier)]

Still looks good Dan!

I've signed off on the new branch at:

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

[Dan Wells (dbw2)]

Pushed to master through 2.5. Thanks, Kathy!