[Koha-bugs] [Bug 13615] New: callnumber.pl when editing existing 942h or 952o adds a space and digit

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13615

            Bug ID: 13615
           Summary: callnumber.pl when editing existing 942h or 952o adds
                    a space and digit
 Change sponsored?: ---
           Product: Koha
           Version: 3.18
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: Cataloging
          Assignee: gmcharlt at gmail.com
          Reporter: eb at efdss.org
        QA Contact: testopia at bugs.koha-community.org
                CC: m.de.rooy at rijksmuseum.nl

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.

-- 
You are receiving this mail because:
You are watching all bug changes.