Browse search not including scoped electronic bibs

Bug #1773479 reported by Blake GH on 2018-05-26
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

EG 3.1.0

I have confirmed that my test case does have entries in metabib.browse_entry. I have confirmed that the bib does return in basic search results via keyword and title.

Here is and example from concerto:

It should be showing bib 238 in the browse results. For convenience the link to the record is:

It does work for bibs that are branch scoped:

In this case we are looking for this bib:;fi%3Asearch_format=ebook;locg=4;detail_record_view=0;expand=marchtml#marchtml

Which does work. It seems that the difference is the 856$9 being scoped to a branch instead of CONS.

a. bellenir (abellenir) on 2018-06-21
Changed in evergreen:
status: New → Confirmed
Jason Stephenson (jstephenson) wrote :

There are some in the community who do not consider this to be a bug, i.e. they do not want electronic resources showing up in browse.

Therefore, I am setting the importance of this bug to Wishlist to indicate that it is a new feature.

Also, the new code should be governed by an org. unit setting or settings (as appropriate) to enable the feature. I feel it should be off by default and should be enabled explicitly by those sites that want to use it.

Changed in evergreen:
importance: Undecided → Wishlist
Blake GH (bmagic) wrote :

Older versions of Evergreen do have CONS level electronic bibs results in browse. The newer versions of EG eliminated this feature.

Jason Stephenson (jstephenson) wrote :

Actually, I misunderstood the problem when I commented earlier. Ignore me. I retract my comment.

Changed in evergreen:
importance: Wishlist → Medium
Dan Wells (dbw2) wrote :

I have a possible fix for this issue, and will prepare a branch this afternoon.

Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Dan Wells (dbw2) wrote :;a=shortlog;h=refs/heads/user/dbwells/lp1773479_located_uri_browse


Okay, from the commit:

Located URIs depend upon bib-level visibility, as there are no copies to work with. The browse code, however, was joining in the copy visibility table as if it would always have at least one row per bib, but in the case of located URIs, it does not.

Let's change it to a LEFT JOIN to allow the bib row to stay in consideration, at which point the existing bib visibility check can do its job.

Now, the code here is pretty thick, but I think this is a relatively benign change, and it solves the issue for me.

(P.S., I don't think there is a difference between CONS and not-CONS in this case, but rather that the examples in question happened to have a copy attached which hid this bug.)

Dan Wells (dbw2) on 2018-11-12
tags: added: pullrequest
Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
milestone: none → 3.3-beta1
Mike Rylander (mrylander) wrote :

WORKSFORME. Thanks, Dan! Committed to 3.1 through master.

Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
status: Confirmed → Fix Committed
Changed in evergreen:
assignee: Mike Rylander (mrylander) → nobody
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