Bug 11780 - Need to prevent specific fields from being overwritten with z39.50 import
Summary: Need to prevent specific fields from being overwritten with z39.50 import
Status: RESOLVED DUPLICATE of bug 14957
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-18 14:18 UTC by Jeremy Evans
Modified: 2020-01-05 12:07 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Evans 2014-02-18 14:18:42 UTC
In our previous LMS we could associate specific marc fields as "local use" in the configuration. If a marc record was overwritten with another via z39.50 these local use files remained in the new record. (if it was in a field that also contained data in the incoming record, then a 2nd instance for that field was created - e.g. multiple 500 notes, etc
e.g. we need to keep our own 001 control numbers as Analytics links from other records get broken if this is replaced with the 001 of a new record say from LC or NLM. At the moment I have to note the existing 001 & put that value in again after replacing the record.  There are also local notes fields etc that we would want to keep.

It would be useful if this setting is also framework specific. (e.g. to keep certain fields for serials but not for monographs etc)
Comment 1 Martin Stenberg 2015-10-26 13:16:33 UTC
Related to bug 14957
Comment 2 David Cook 2019-05-14 05:26:09 UTC
I think this would be relevant when importing records for the first time via Z39.50 as well.

For instance, it seems highly unlikely that you'd want to import the 9XX and 85X fields from another library's bibliographic record.

However, with that framework, you'd want to be able to have your own 9XX and 85X fields, so deleting the fields from the framework is not an acceptable "workaround" to prevent importing of certain fields.
Comment 3 Katrin Fischer 2020-01-05 12:07:13 UTC

*** This bug has been marked as a duplicate of bug 14957 ***