Summary: | Add mapping for items.stocknumber to MARC21 | ||
---|---|---|---|
Product: | Koha | Reporter: | Katrin Fischer <katrin.fischer> |
Component: | MARC Bibliographic data support | Assignee: | Katrin Fischer <katrin.fischer> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | enhancement | ||
Priority: | PATCH-Sent (DO NOT USE) | CC: | chris, jcamins, koha.sekjal, m.de.rooy |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 5860 | ||
Bug Blocks: | |||
Attachments: |
Patch adding 952$i and mapping to items.stocknumber to frameworks
Adding new index stocknumber on field 952$i Added inv: as alias for index Alternative to 0001: Description changed to 'Inventory number' instead of 'Stocknumber' Follow up patch for Norway file |
Description
Katrin Fischer
2011-03-07 09:20:51 UTC
I favor your idea! We "misused" copynumber (952t) on item level for inventory number. This makes it show up in several opac/intranet places (detail view etc.) To make the switch, we would like to see the new field show up there too as well as searching for it in zebra, etc. Hi Marcel, thx for your comment! I think we should have a second bug for the display issues? Once we have a save place to store the information we can work from that. I also had requests to make the inventory number show up on OPAC and make it easier to search for it. Checking with some of our data I see that the items.stocknumber field is unique. This is good, because in theory inventory numbers should be unique. In practice you will often get old data with duplicate numbers. Marcel: Do you think this is a problem? (In reply to comment #3) > Checking with some of our data I see that the items.stocknumber field is > unique. This is good, because in theory inventory numbers should be unique. In > practice you will often get old data with duplicate numbers. > Marcel: Do you think this is a problem? No, it should not be a problem for us. Would favor keeping it unique.. Yes, I favor that too. But already ran into data that needs to be cleaned before I can move it out of the xml and into the new field. Is someone opposed to map 952$i to items.stocknumber in the frameworks by default? I would like to start working on this. Created attachment 3512 [details] [review] Patch adding 952$i and mapping to items.stocknumber to frameworks Created attachment 3517 [details] [review] Adding new index stocknumber on field 952$i (In reply to comment #7) > Created attachment 3512 [details] [review] > Patch adding 952$i and mapping to items.stocknumber to frameworks Tested (with install). Works OK. Signed off. Will test the other one too. (In reply to comment #8) > Created attachment 3517 [details] [review] > Adding new index stocknumber on field 952$i Katrin: Could you check on the following? In bib1.att 1028 is already conform LOC standard: Stock-number. Should we use that one instead of adding 1062? You could also add a line: stocknumber Stock-number Note too that 1062 is in the reserved LOC range. You could better pick a number in the 8XXX range as has been done for item attributes already. Furthermore, I already signed the first patch. But this second patch makes me wonder if we not better mention it: inventory number? That would also make the choice for a new number 8XXX more acceptable. I will send a mail to the dev list for the name issue. After that I would be happy to sign a revised patch. I think we concluded that 1028 was reserved for the supplier's stock number, rather than the local number. (In reply to comment #11) > I think we concluded that 1028 was reserved for the supplier's stock number, > rather than the local number. OK. Zeno Tajoli was the only one responding to the mail and favored inventory number too. I would say: let's call it inventory number instead of stocknumber and pick a 8000 number for it in bib1.att. And Katrin? Hi Marcel, I don't completely understand. What do you want to rename? The index or the field description in the frameworks? I agree that inventory number has a better sound to me - the German word is Inventarnummer. I decided to name it after the field in items, because I thought a new name might cause confusion. Renaming in the frameworks in fine for me though. But I don't understand your concerns about 1062 http://www.loc.gov/z3950/agency/defns/bib1.html Number-local-acquisition 1062 Document acquisition number assigned by the system. Which is exactly what a inventory number is. Why should we choose another attribute? Created attachment 3600 [details] [review] Added inv: as alias for index Created attachment 3601 [details] [review] Alternative to 0001: Description changed to 'Inventory number' instead of 'Stocknumber' Tested: Added inv: as alias for index Tested: Alternative to 0001: Description changed to 'Inventory number' instead of 'Stocknumber' (Tested sql files on English) Signed off both patches. Will add another comment about a related error, but not originating from these patches. Stumbled while testing this patch on another error in C4/Items. If I entered a duplicate inventory number, the item was not saved but the user is not warned. This error comes from an existing bug [read: not existing code] in C4/Items. Only the logfile tells you what happened. Created bug 6041 for this. [Mon Apr 04 10:05:12 2011] [error] [client 192.87.126.61] [Mon Apr 4 10:05:12 2011] additem.pl: DBD::mysql::st execute failed: Duplicate entry 'invtest' for key 3 at /usr/share/koha/testclone/C4/Items.pm line 2157., referer: http://libdevelop.rijksmuseum.nl:8009/cgi-bin/koha/cataloguing/additem.pl?op=edititem&biblionumber=144200&itemnumber=147307 [Mon Apr 04 10:05:12 2011] [error] [client 192.87.126.61] [Mon Apr 4 10:05:12 2011] additem.pl: ERROR in _koha_modify_item UPDATE items SET homebranch=?,replacementprice=?,restricted=?,items.cn_sort=?,wthdrawn=?,more_subfields_xml=?,booksellerid=?,holdingbranch=?,damaged=?,stocknumber=?,notforloan=?,replacementpricedate=?,itemnumber=?,ccode=?,itemnotes=?,location=?,itemcallnumber=?,stack=?,barcode=?,itemlost=?,uri=?,items.cn_source=?,materials=?,enumchron=?,dateaccessioned=?,copynumber=?,permanent_location=?,price=?,paidfor=?,itype=? WHERE itemnumber=?Duplicate entry 'invtest' for key 3 at /usr/share/koha/testclone/C4/Items.pm line 2160., referer: http://libdevelop.rijksmuseum.nl:8009/cgi-bin/koha/cataloguing/additem.pl?op=edititem&biblionumber=144200&itemnumber=147307 The first patch applied, the second one fails error: patch failed: installer/data/mysql/pl-PL/marcflavour/marc21/optional/marc21_fastadd_framework.sql:118 error: installer/data/mysql/pl-PL/marcflavour/marc21/optional/marc21_fastadd_framework.sql: patch does not apply error: patch failed: installer/data/mysql/pl-PL/marcflavour/marc21/optional/marc21_simple_bib_frameworks.sql:180 error: installer/data/mysql/pl-PL/marcflavour/marc21/optional/marc21_simple_bib_frameworks.sql: patch does not apply Did you hand edit your patch? It does not apply to blobs recorded in its index. Cannot fall back to three-way merge. Patch failed at 0001 Bug 5839: Add mapping for items.stocknumber to MARC21 [marcel@RKM004 testclone]$ git reset --hard HEAD is now at e1a0b4a bug 4865: added dependency for using memcached for sessions [marcel@RKM004 testclone]$ git am -3 ../5839a-sign.patch Applying: Bug 5839: Add index stocknumber on 952$i [marcel@RKM004 testclone]$ git am -3 ../5839b-sign.patch Applying: Bug 5839: Add mapping for items.stocknumber to MARC21 The patch attached to this bug applies fine, the signed offone sent to the list doesn't. Applying the original one. Pushed, please test Comment on attachment 3512 [details] [review] Patch adding 952$i and mapping to items.stocknumber to frameworks Alternative was pushed. Created attachment 3614 [details] [review] Follow up patch for Norway file Norwegian installer file updated Resetting status to Signed for tiny follow up fix. Follow up pushed This doesn't seem to apply to upgrades, and it probably should. You mean the updates to the framework? I am not sure there is a save to do this. A library might have used the field for local purposes. Adding an index and a mapping for newly installed libraries doesn't hurt them. But updating the framework and changing the mapping in the items table might cause trouble. Fair enough. I'm going to close the bug, then, since it works on new installations. |