Bug 13615 - callnumber.pl when editing existing 942h or 952o adds a space and digit
Summary: callnumber.pl when editing existing 942h or 952o adds a space and digit
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 3.18
Hardware: All All
: P5 - low minor (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-22 19:50 UTC by Elaine Bradtke
Modified: 2017-06-14 22:10 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
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 Elaine Bradtke 2015-01-22 19:50:04 UTC
Disclaimer: I'm not certain I understand what callnumber.pl should do.  I have been experimenting with enabling it in 942h to pull the callnumber from our 099 field (it doesn't) and / or in 952o to do the same thing (it does if the plugin is not enabled in the 942). If I enable it only in the 942h, it will automatically populate the 952o using what's entered in the 942h. That in itself seems counter-intuitive.

Note: our call numbers are not unique. I don't know how this relates to bug 13364, or if there is an underlying assumption that a field with callnumber.pl enabled will be unique.

When editing a catalogue record, we manually type in the contents of the
942$h (call number). When editing this field in a reopened record, after hitting save, a space and numeral 1 magically appear following the call number, completely without our input.

Here it is in a record - the call number should be only "QM" as it is in
the 099 field. It appears to be adding 0001 in the  942 $6 which we have set to ignore. If the 1 is successfully deleted from the $h, the 0001 also vanishes from $6. 


000		00720ndm a22002057a 4500
001		201501211025.nw
003		UkLoVW
005		20150121224121.0
008		150121q1926 enkfmle nn 0 eng d
040		_aUkLoVW_beng_cUkLoVW
099		_aQM
100	1	_913719_aHooton, P. M.
245	10	_aManuscript music book /
300		_a6 p. :_bmusic ;_c30 cm.
500		_aManuscript music book with country morris and sword dance tunes, including bass parts in some cases. The name P. M. Hooton is on the front cover, probably Miss P. M. Hooton of Norwich who was an EFDS member in the 1920s.
650	7	_9127_aDance music
650	7	_9163_aEngland
850		_aUkLoVW
942		_2VWML_cMS_hQM 1_n0_6QM0001
999		_c65844_d65844

Other tests I've run:
The following things happen only after I edit the field in question.
With the plugin callnumber.pl activated in both 942h and 952$o :
 the 1 appears after the call number in 942h as described above.  But, it vanishes again without being deleted manually - it does not appear in the MARC after saving. The 952$o is populated automatically with the information from 942 h.

With the plugin enabled in 942h, if I click on the box to the right of the 942h (this is only visible when the plugin is activated)  -  it inserts the 1. 

If I disable the plugin in 942 and enable it in 952, it will pull the information directly from the 099 field to 952o. But if you edit an existing item's 952o, it adds the 1. If there is an item attached to the same biblio that has the 1 already inserted, a subsequently edited item will add a 2. I haven't gone further than that, but it appears to be keeping track and incrementally changing the number it inserts.

The problem was reported by staff using Windows and Chrome.  I have replicated it on Mac OSX using Chrome and Firefox.
Comment 1 Elaine Bradtke 2015-01-23 02:05:11 UTC
After discussing this with the IT wizard, I now understand where the numbers are coming from.  Many of our call numbers consist of nothing more than two upper case letters, for example QM. The plugin is looking at that and seeing a prefix and adding sequential numbers. It still doesn't explain why the plugin pulls from the 099 when used in the 952 field, but not when used in the 942 field.

Perhaps a brief explanation of what this plugin is meant to do would be a useful addition to the manual?
Comment 2 Owen Leonard 2016-06-21 12:28:05 UTC
(In reply to Elaine Bradtke from comment #1)

> Perhaps a brief explanation of what this plugin is meant to do would be a
> useful addition to the manual?

Could you open a separate documentation bug report for that?
Comment 3 Elaine Bradtke 2016-06-21 17:00:59 UTC
Done, see bug 16791