Browse the Catalog bug with the OPAC

[Steve Callender]

Tested in 3.0.3 but looks to affect all of 3.0.

When going to the OPAC and then going to "Browse the Catalog", searches are giving an error.

The error states,

An error occurred browsing records. Please try again in a moment or report the issue to library staff.

Doing the same search in the staff client works. It looks like the difference in searching is related to a flag that designates one as a staff client search, other other as not.

For example, this works,

select metabib.browse( 'title', 'fish', '1', NULL, 't', NULL, '10');

This does not,

select metabib.browse( 'title', 'fish', '1', NULL, 'f', NULL, '10');

The staff flag is utilized in metabib.staged_browse as follows,

IF NOT staff THEN
    SELECT x.c_attrs, x.b_attrs INTO c_tests, b_tests FROM asset.patron_default_visibility_mask() x;
END IF;

Steve

[Terran McCanna (tmccanna)]

We're not having problems with the browse part of the OPAC in 3.0.2.

See: http://gapines.org/eg/opac/browse?blimit=20&qtype=author&bterm=m&locg=1

[Kathy Lussier (klussier)]

I see the same error on one of my test servers running master. I suspect it's related to one of the visibility fixes that made it into 3.0.3.

[Mike Rylander (mrylander)]

DING DING DING!

Kathy, you're exactly right. Branch forthcoming...

[Mike Rylander (mrylander)]

Aforementioned branch is here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1746584-browse-visibility-test

From the commit message:

With updates to address visibility testing issues for LURIs, a change was made
to allow the default bib tests to supply the most appropriate query_int
operator with which to join those to non-default tests. The browse code,
however, is all database-level and was not adjusted with the Perl code that
implements general search. This commit addresses that issue by acknowledging
that the bib vis testing code to provide its own operator, either | or &, as
appropriate to the actual default test values.

[Jason Stephenson (jstephenson)]

I was going to look into this on a vm with 3.0.3 and production data, but turns out the db upgrade and ingest is going to take too long.

FWIW, I was not able to reproduce this on master with concerto data, but none of my searches turned up records with located URIs. Are there any in concerto?

[Kathy Lussier (klussier)]

This bug is unrelated to Located URIs. In my testing, also done with concerto data, the error occurred in the public catalog with any browse search.

[Jason Stephenson (jstephenson)]

I'll give it another go. I think it was not happening for me because I had been using the web staff client in the same browser where I tried to reproduce this.

[Jason Stephenson (jstephenson)]

Mike's branch works for me, so I pushed it to master and rel_3_0.

Thanks, everyone!