http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537
Galen Charlton <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #9 from Galen Charlton <[email protected]> --- [copying feedback I posted to koha-devel] On Sun, Jan 10, 2016 at 8:44 PM, David Cook <[email protected]> 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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
