Catalogue does not display serials holdings for bib record with an MFHD record owned outside of search scope

[Dan Scott]

* Evergreen 2.0.6
* OpenSRF 2.0.0
* PostgreSQL 9.0.4

In rdetail.js, Dojo dies with a null reference error when an MFHD record is retrieved that is outside of the current OU search scope. For example, if a given bib record has one linked MFHD record for BR1, and one linked MFHD record for BR4, the details page chokes trying to draw the MFHD holdings in a scope that only includes BR1 and ends up drawing nothing. Ungood.

Moving the ownership check and invoking _holdingsDrawMFHD() only after ensuring that the record is within our scope resolves the problem.

I have pushed a working branch with a fix to user/dbs/fix-mfhd-render

[Dan Wells (dbw2)]

Hi Dan,

Thanks for this report. The branch does fix the described issue, but causes a different problem with the way we are using 'entryNum' in a few places (menu entries and display ordering).

I was about to attach a patch to this message, but the more I kept experimenting, the less I was sure of the desired behavior in certain circumstances. The fix in the branch ends up changing a few other display results, so I figured we might want to talk it over now.

Assume a three level system like:

CONS
--SYSA
----BR1
----BR2
--SYSB
----BR3

All branches have a MFHD.

Here are a few questions:
1a) When browsing at location CONS, do we display all the MFHD records or none at all?
1b) If we display nothing, when browsing at BR1 but a depth of '0' (i.e. Everywhere), do we display BR1 MFHD, nothing, or something else?

2) I am fairly sure when browsing at SYSA at its normal depth (1), we want to see both BR1 and BR2 MFHDs. That said, when browsing at BR1 but a depth of '1' (i.e. This system), do we see both BR1 and BR2, or just BR1?

I'll stop there, as any more questions I have might not make sense depending on the answers to these.

Thanks,
Dan

[Dan Scott (denials)]

Thanks for the review, Dan. I'd be interested in understanding what effect you're seeing this have on entryNum; we need to start thinking about this for the TT OPAC display.

Quick answer: I'm strongly tempted to keep the scoping as simple as possible. Our users tend to get confused by scope vs. system/branch selection as it is, and MFHD display does not necessarily identify which OU actually contains the holdings.

So I would answer:

1a) At CONS, I would want to display all MFHD records.

1b) When browsing at BR1, I would want to display BR1 and below.

2) When browsing at SYSA at depth 1, I would want to see both BR1 and BR2. When browsing at BR1 with a scope of 1, I would still want to see just BR1 and below.

I'm also going to bump the priority of this because the current code prevents catalogers from being able to edit, add, or delete MFHD records if they run into the error condition described above (which is what prompted this ticket in the first place).

[Dan Wells (dbw2)]

I think your answers are exactly the right place to start. At some point we might consider further emulating the copy scoping in cases where no MFHD would display at all, or a link to 'see all', but that can come later, probably even post TT-opac.

That said, here is a patch for your consideration. entryNum is currently used in a variety of ways, including correlating XUL menu entries with what is on the page. Of course there are other ways to do it, but short of rethinking a number of things, I think preserving the effect with a simple closure gets the job done. Also, if we are only ever displaying from the current location down, we no longer need to do the depth-checking and climbing at all.

Thanks,
Dan

[Dan Scott (denials)]

Dan - thanks! I have applied your patch, confirmed that it works as desired on our end, and committed our respective commits from master through rel_2_0.