Issues

Select view

Select search mode

 
50 of 83

z39.50 should not return suppressed bibs/holdings

Done

Description

Currently z39.50 results (for opac results) include suppressed bibs and holdings.  This is a problem for a couple of reasons:

1) The response includes electronic resources that have been suppressed.  The vendor making the opac z39.50 call does not have an indication that the record is suppressed...so they may display it to library patrons as an available electronic resource.  (See attached screen print)

2) If you have a suppressed print holding records with no items ...this is also confusing on the vendor side.  It appears as if items are missing from the response.

 Adding a couple of watchers in case anyone wants to comment/give feedback. thank you!

Solution:
made the relevant one-line change to the sample configuration that comes with the software:
"queryFilter": "cql.allRecords=1 NOT discoverySuppress=true"
https://github.com/folio-org/Net-Z3950-FOLIO/blob/a1725e115325a2ef6ccb49470868477e33877f5e/etc/config.json#L29
If Cornell, Lehigh, TAMU or other institutions need help with updating the configuration then please contact

will update the Iris release notes.

 

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Attachments

1

Checklist

hide

TestRail: Results

Details

Assignee

Reporter

Priority

Development Team

Thor

Fix versions

Release

R2 2021 Bugfix

Affected Institution

Cornell
Lehigh
TAMU

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created July 6, 2021 at 4:58 PM
Updated December 6, 2021 at 1:46 PM
Resolved July 16, 2021 at 10:58 AM

Activity

Show:

Anne L. HighsmithSeptember 29, 2021 at 3:39 PM

 I asked  , our sysadmin, to change the filter to

"queryFilter": "source==marc NOT discoverySuppress==true"

as instructed and tested again. Same scenario as before: an instance that is not suppressed, has 1 unsuppressed holding with unsuppressed item and 1 suppressed holding with 1 suppressed item. When I queried for that instance specifically (find @attr 1=12 "in00001326971") it returned 2 holdings records, 1 for the unsuppressed holdings/item combo and 1 for the suppressed holdings/item combo.

So this filter appears, if we have it correctly implemented, appears not to filter suppressed holdings correctly.

Julian LadischSeptember 28, 2021 at 10:40 AM

: Please try

All other possibilities incorrectly reject an instance if

a) two holdings of the instance have different discoverySuppress status or if

b) two items of the instance have different discoverySuppress status.

Julian LadischSeptember 28, 2021 at 10:21 AM

Both source and discoverySuppress have a field index and not a word based full text index: https://github.com/folio-org/mod-inventory-storage/blob/master/src/main/resources/templates/db_scripts/schema.json

To make use of these database indexes and get best performance you should use the field index operator == and not the word based full text index =.

Replace

by

For details see https://dev.folio.org/faqs/explain-cql/

Julian LadischSeptember 28, 2021 at 10:15 AM
Edited

AND cql.allRecords=1 can be removed: You only need to prepend cql.allRecords=1 if the CQL query starts with NOT.

can be replaced by

Anne L. HighsmithSeptember 27, 2021 at 10:39 PM
Edited

 I have been following this discussion somewhat. Based on your most recent update, we have the filter in our Juniper HF1 instance set to 

"queryFilter": "source=marc AND cql.allRecords=1 NOT discoverySuppress=true NOT holdingsRecords.discoverySuppress=true NOT item.discoverySuppress=true NOT item.barcode=''",

 

I tested this against an instance that is not suppressed, has 1 unsuppressed holding with unsuppressed item and 1 suppressed holding with 1 suppressed item. When I queried for that instance specifically (find @attr 1=12 "in00001326971") it returned no hits. If I'm understanding your instructions correctly and we have it implemented correctly, I would have expected 1 hit on that record. Thanks.

TestRail: Cases
TestRail: Runs