<html>
<body>
At 12:44 PM 1/11/2016 +1100, David Cook wrote:<br>
<blockquote type=cite class=cite cite>Content-Type:
multipart/alternative;<br>
<x-tab> </x-tab>boundary="----=_NextPart_000_008A_01D14C6D.DDE56680"<br>
Content-Language: en-au<br>
Hi all:<br>
Recently,
<a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084">http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084</a>
was pushed to master. It adds a cronjob which deletes bibliographic records, if their LDR05 is d(ie status deleted).</blockquote><br>
Brendan, David,<br><br>
Thanks for your work on this. I have sometimes wondered what the LDR, Pos 05 - Record status d - Deleted "Record has been deleted" actually means.<br><br>
My question is: how many cataloguers take the time and trouble to modify LDR pos05, rather than just "hit delete" for a record?<br><br>
From a Koha db viewpoint, either the record is in MySQL and therefore (probably?) should get indexed by Zebra, or it has been deleted by a cataloguer -- logically gone, terminally, no bytes left on the hard disk -- except that Koha has tables "deletedbiblio", "deletedbiblioitems" and "deleteditems" which (as far as I can tell) do not contain the LDR, therefore cannot cross-reference pos05=d (and I'm not certain that there is a way to "undelete" -- can it be done?)<br><br>
Best -- Paul<br><br>
<br>
<blockquote type=cite class=cite cite> <br><br>
While Im all for that, Im thinking that it would also be a good idea to hide these records with LDR05 din the OPAC before the cronjob is run.<br><br>
<br><br>
We cant necessarily rely on all Koha instances running this cronjob, nor can we rely on the frequency. Shouldnt we be hiding these records from the OPAC as soon as theyre marked as deleted? <br><br>
<br><br>
Ive opened a bug for this purpose: <a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537">http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537</a><br><br>
<br><br>
It should be a pretty easy change, especially when using special attribute @attr 14=1 to avoid past OpacSuppression problems, but I thought Id ask folk if its something theyd be interested in. Wed probably still want to see these records in the Staff Client, as we want to be able to find all records in the database in the Staff Client.<br><br>
<br><br>
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 doesnt send metadata for deleted records). Id match the existing record in Koha using the identifier, and then set LDR05 to din accordance with the OAI-PMH deleted status. Then, that record would disappear from the OPAC, so that end users dont see this skeleton record. <br><br>
<br><br>
David Cook<br><br>
Systems Librarian<br><br>
Prosentient Systems<br><br>
72/330 Wattle St, Ultimo, NSW 2007<br><br>
<br>
_______________________________________________<br>
Koha-devel mailing list<br>
Koha-devel@lists.koha-community.org<br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" eudora="autourl">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
website : <a href="http://www.koha-community.org/" eudora="autourl">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" eudora="autourl">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" eudora="autourl">http://bugs.koha-community.org/</a> </blockquote>
<x-sigsep><p></x-sigsep>
---<br>
Maritime heritage and history, preservation and conservation, <br>
research and education through the written word and the arts.<br>
<<a href="http://navalmarinearchive.com/" eudora="autourl">http://NavalMarineArchive.com</a>> and <<a href="http://ultramarine.ca/" eudora="autourl">http://UltraMarine.ca</a>><br>
</body>
</html>