http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- All we'd need to do is change biblio-zebra-indexdefs.xml/xsl so that we're indexing LDR05, add "@attr 14=1 @not record_status=d" at the start of all OPAC queries (ie where we already have OPAC Suppression code), and we'd be fine. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- Created attachment 46509 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=46509&action=edit Bug 15537 - Hide records on Leader 05 = d in OPAC Currently, if a bibliographic record has a record status of "deleted" (ie LDR05=d), it shows up in the catalogue. This patch indexes the LDR05 character into the Record-status index (already defined in bib1.att). It creates a CCL qualifier for that index, and it adds a condition to OPAC queries where it only returns records that do not have a LDR05 of "d". Test Conditions: 1) With QueryParser 2) Without QueryParser 3) With OpacSuppression 4) Without OpacSuppression Test Plan: Before applying patch: 1) Choose a bibliographic record and change the LDR05 to "d" 2) Try searching for that record in the OPAC 3) Note that it appears in the search results (or takes you directly to the record) Apply patch. After applying patch: 4) Try searching for that record in the OPAC 5) Note that the record doesn't appear in the search results 6) Re-try steps 4 & 5 with each of the 4 test conditions outlined above. It should work the same regardless of using the QueryParser or OpacSuppression. NOTE: When using the QueryParser, you might need to vary your syntax. For instance, w/ QP you'd need "local-number:492 || local-number:495" whereas w/o QP you'd need "local-number:492 or local-number:495". NOTE: For extra points, double-check the staff client to make sure that you can still find records that have a LDR05 of "d". -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #46509|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- Created attachment 46511 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=46511&action=edit Bug 15537 - Hide records on Leader 05 = d in OPAC (follow-up) This follow-up adds a warning message on the detail page in the staff client, which says that the record will not appear in the OPAC. It also includes some logic in opac-detail.pl which prevents an OPAC user from visiting it directly. Test Plan: Apply the patch. 1) Visit a staff client page for a bib record with LDR05=d. 2) Note that there is a warning message saying that it will not be visible in the OPAC 3) Visit the corresponding OPAC page for the bib record 4) Note that you get a redirect to a 404. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- NOTE: I have not tested this in UNIMARC or NORMARC, although I've provided Zebra changes for both. They should be OK, but I haven't confirmed that to be the case. I have only tested MARC21. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- ADDITIONAL TESTING NOTE: You'll need to re-index Zebra before this feature works... otherwise the Record-status index won't be populated... -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gmcharlt@gmail.com --- Comment #9 from Galen Charlton <gmcharlt@gmail.com> --- [copying feedback I posted to koha-devel] On Sun, Jan 10, 2016 at 8:44 PM, David Cook <dcook@prosentient.com.au> wrote:

We can’t necessarily rely on all Koha instances running this cronjob, nor can we rely on the frequency. Shouldn’t we be hiding these records from the OPAC as soon as they’re marked as “deleted”?

I’ve opened a bug for this purpose: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537

I am in mild disfavor of this proposal, particularly as implemented in current patch. Using a cronjob to delete records where Leader/05 is set to 'd' is useful when the library has arranged their workflow such that they *know* that Leader/05 = 'd' is being used consistently to signify that a record is no longer wanted. However, for a library that has not hitherto cared about the values in that position, unconditionally suppressing the display of such records could come as an unwelcome surprise. That said, it is also a reasonable choice for a library to want to use the Leader/05 as suppression criterion. Consequently, I suggest adding a configuration option. For that matter, making it configurable (say, by allowing the library to specify a set of query additions for the purpose of filtering records from public display) could result in a more generally useful mechanism.

I admit that I have a special interest in this where I might be overlaying existing records using a mostly empty skeleton record generated from an OAI-PMH identifier and a OAI-PMH deleted status (OAI-PMH doesn’t send metadata for deleted records). I’d match the existing record in Koha using the identifier, and then set LDR05 to “d” in accordance with the OAI-PMH deleted status. Then, that record would disappear from the OPAC, so that end users don’t see this skeleton record.

I do not find this a compelling use case as stated. If the goal is to allow harvesting and overlay records from an OAI-PMH provider to also delete bibs from a Koha database... coding so that the records are *actually* deleted seems more direct. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |ASSIGNED --- Comment #11 from David Cook <dcook@prosentient.com.au> --- Hmm, I don't seem to be getting the emails about comments... I agree that I should add a system preference in this case. I've also followed up Galen's emails on koha-devel regarding OAI-PMH, and I think I'm going to go a different route, which makes this bug and its patches irrelevant for bug 10662. Resetting this bug to assigned, although I'm in no rush to finish this bug due to the change in direction of bug 10662. -- You are receiving this mail because: You are watching all bug changes.