[Bug 7817] New: Items Permanent location (shelving location) is set to NULL when item is edited
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Priority: P5 - low Change sponsored?: --- Bug ID: 7817 Assignee: gmcharlt@gmail.com Summary: Items Permanent location (shelving location) is set to NULL when item is edited QA Contact: koha.sekjal@gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: joy@bywatersolutions.com Hardware: All Status: NEW Version: rel_3_6 Component: Cataloging Product: Koha When an item is edited, the field items.permanent_location is set to NULL. This causes significant problems when a library is utilizing the CART and PROC system preferences to assign CART and PROC shelving locations. If items.permanent_location is NULL then there is no way to restore the original shelving location for these items. This results in significant data loss for libraries. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Joy Nelson <joy@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=7634 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Joy Nelson <joy@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - low |P1 - high Severity|enhancement |critical -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz --- Comment #1 from Chris Cormack <chris@bigballofwax.co.nz> --- I suspect this is because permanent_location is not mapped to a marc field. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle.m.hall@gmail.com --- Comment #2 from Kyle M Hall <kyle.m.hall@gmail.com> --- Is the solution then to add a default mapping to Koha? The problem is that all the possible 952 subfields are being used. I tried mapping it to 960$l just to see what would happen, and items.permanent_location is still set to NULL when the item is edited. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Kyle, according to the MARC it's also possible to use upper case letters. We have used some of them with more_subfields_xml in migrations. But I am not sure we should really treat this field lika a normal item field. Perhaps it should be tied to the functions it was added for? So before Koha changes the location to a temporary location (CART or PROC) it could save the current location to the permanent_location field. Would that make sense? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=6034 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #4 from Kyle M Hall <kyle.m.hall@gmail.com> --- I have found the problem: Bug 6034, Shelving cart feature can wipe permanent shelving location in certain circumstances, added "permanent_location => undef" at line 430 of Items.pm. When permanent_locations is not mapped, it always uses null as the value from this hash. Solution: comment out line 430. I don't know if this will have any other affects. Potential problem: If a library decides to map permanent_location to a marc field, they will be unable to set it to a null value. Possibly better solution: build %default_values_for_mod_from_marc via a subroutine that checks to see if each column is mapped to a marc field, and deletes that key if it is not. That way, any unmapped fields will not be nulled when an item is edited. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Fred P <fred.pierre@smfpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fred.pierre@smfpl.org --- Comment #5 from Fred P <fred.pierre@smfpl.org> --- We implemented with the capital C for permanent location, editing the default MARC framework to add 952 C, and defining that like 952 c, referencing authorized value for LOC, and displaying on tab 10 (items(10)) so that it appears on the "Edit item" screen. Not sure if this breaks any of the CART functions. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Jorge de Cardenas <jdeca@smfpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdeca@smfpl.org --- Comment #6 from Jorge de Cardenas <jdeca@smfpl.org> --- (In reply to comment #3)
Hi Kyle,
according to the MARC it's also possible to use upper case letters. We have used some of them with more_subfields_xml in migrations.
But I am not sure we should really treat this field lika a normal item field. Perhaps it should be tied to the functions it was added for? So before Koha changes the location to a temporary location (CART or PROC) it could save the current location to the permanent_location field. Would that make sense?
I would be interested to know the consequences of mapping to an upper case (952C) for Permanent Location and having it available on the items edit page. It appears that LibLime might be doing this. We want to implement a temporary location. Items are pulled for a display and the location is changed to reflect that temporary location. When that item is checked out and checked back in the Permanent Location is copied to the Location, automatically and the item goes back to the regular shelf. We have been doing this using the Lost status but that requires custom coding to allow holds on certain items with a Lost Status and displaying their Temporary Location. When these items are circulated they revert back to a normal Available status. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #7 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- Created attachment 28949 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28949&action=edit Bug 7817 - Items Permanent location (shelving location) is set to NULL when item is edited A quick fix to prevent more damages. No perceived side-effects so far. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff CC| |olli-antti.kivilahti@jns.fi --- Comment #8 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- I would like to know why such a serious issue hasn't been fixed to master? Clearly this problem has been identified years ago and somebody must have fixed it (because atleast the creator of ReturnToShelvingCart uses this feature), but the fix never made it here??? Why? I was able to fix the ~4500 missing permanent_locations from our installation specific identifier in the items.itemcallnumber. But others are not so lucky. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to Olli-Antti Kivilahti from comment #8)
I would like to know why such a serious issue hasn't been fixed to master? Clearly this problem has been identified years ago and somebody must have fixed it (because atleast the creator of ReturnToShelvingCart uses this feature), but the fix never made it here??? Why?
I was able to fix the ~4500 missing permanent_locations from our installation specific identifier in the items.itemcallnumber. But others are not so lucky.
I imagine this issue hasn't been fixed, because it requires a specific configuration and someone to notice a problem. I believe that for this issue to occur you would need the following config: 0) Set the Shelving Location for an item during 'Add item' (this will populate 'item.location' and 'item.permanent_location' with the LOC authorized value for the shelving location AND - 1a) 'NewItemsDefaultLocation' set to 'PROC' and 'InProcessingToShelvingCart' set to 'ON' OR 1b) 'ReturnToShelvingCart' set to 'ON' - AND 2) Edit the item before checking it (since editing the item will clear 'item.permanent_location' due to a missing Koha => MARC mapping THEN Run 'cart_to_shelf.pl' -- At Prosentient, none of our libraries use any of these system preferences, so it hasn't been an issue. As for other libraries/vendors, I suspect that there could be any number of reasons for a fix not making it here. Either people don't use these preferences, they haven't noticed the problem, or they've created a custom solution that they don't think is appropriate for the community. -- I haven't looked at the code (and I probably won't since it doesn't affect any of my libraries at present), but there's an explanation. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #28949|0 |1 is obsolete| | --- Comment #10 from David Cook <dcook@prosentient.com.au> --- Created attachment 28970 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28970&action=edit Bug 7817 - Items Permanent location (shelving location) is set to NULL when item is edited A quick fix to prevent more damages. No perceived side-effects so far. Signed-off-by: David Cook <dcook@prosentient.com.au> This is actually a perfectly good fix for this issue. I've changed the explanatory comment to explain why. Another option would be to remove the 'exists' check in the sub _do_column_fixes_for_mod(), but this is just as functional. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #28970|0 |1 is obsolete| | --- Comment #11 from David Cook <dcook@prosentient.com.au> --- Created attachment 28971 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28971&action=edit Bug 7817 [SIGNED OFF] - Items Permanent location (shelving location) is set to NULL when item is edited A quick fix to prevent more damages. No perceived side-effects so far. Signed-off-by: David Cook <dcook@prosentient.com.au> This is actually a perfectly good fix for this issue. I've changed the explanatory comment to explain why. Another option would be to remove the 'exists' check in the sub _do_column_fixes_for_mod(), but this is just as functional. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- So much for not looking into this one, eh? ;) By the way, I've tested this fix with the "cart_to_shelf.pl" cronjob, and it works perfectly. The "AddItem" and "ModItem" scripts now both properly populate "permanent_location" from "location" (whereas only "AddItem" did it properly before). CartToShelf() doesn't run into the same problem as the Item Editor because it's using the row from the items table rather than HTML form input, so permanent_location will already be set correctly when running "ModItem" and thus not overwritten by "Cart". Same goes for ShelfToCart(). Voila. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA CC| |jonathan.druart@biblibre.co | |m --- Comment #13 from Jonathan Druart <jonathan.druart@biblibre.com> --- I never seen this bug, but I think the Kyle's suggestion is better:
Possibly better solution: build %default_values_for_mod_from_marc via a subroutine that checks to see if each column is mapped to a marc field, and deletes that key if it is not. That way, any unmapped fields will not be nulled when an item is edited.
Marked as Failed QA. I will try to provide a patch soon. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|3.6 |master -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #13)
I never seen this bug, but I think the Kyle's suggestion is better:
Possibly better solution: build %default_values_for_mod_from_marc via a subroutine that checks to see if each column is mapped to a marc field, and deletes that key if it is not. That way, any unmapped fields will not be nulled when an item is edited.
Marked as Failed QA.
I will try to provide a patch soon.
Jonathan, why not pass this one as QA first so that the broken behaviour can be stopped sooner rather than later as per Olli's request? As for building %default_values_for_mod_from_marc for only mapped columns, I agree that is a better solution. I would gladly sign off that patch as well :). -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #15 from Jonathan Druart <jonathan.druart@biblibre.com> --- (In reply to David Cook from comment #14)
Jonathan, why not pass this one as QA first so that the broken behaviour can be stopped sooner rather than later as per Olli's request?
It seems the patch is not correct. Kyle explained the problem in his comment (comment 4): "Potential problem: If a library decides to map permanent_location to a marc field, they will be unable to set it to a null value." -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #28971|0 |1 is obsolete| | --- Comment #16 from Jonathan Druart <jonathan.druart@biblibre.com> --- Created attachment 29093 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=29093&action=edit Bug 7817: A DB field without a default mapping is set to a default value on editing If an item is edited and a field is not mapped to Koha, it is to 0 or NULL (depending on the default value defined). This patch adds a check on the mapping before editing the item. It there is no mapping, the DB value is not erased. Test plan: 1/ Edit an item and fill a value for a field 2/ Unmap this field 3/ Edit the item 4/ Verify that the value is not erased (using the MySQL CLI) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #17 from Jonathan Druart <jonathan.druart@biblibre.com> --- I am not really confident in this patch, so please test it deeply! It would be great to add some unit tests for the C4::Items::ModItemFromMarc routine... -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #18 from Jonathan Druart <jonathan.druart@biblibre.com> --- You can obsolete my patch if nobody wants it. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #29093|0 |1 is obsolete| | --- Comment #19 from Owen Leonard <oleonard@myacpl.org> --- Created attachment 30350 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30350&action=edit [SIGNED-OFF] Bug 7817: A DB field without a default mapping is set to a default value on editing If an item is edited and a field is not mapped to Koha, it is to 0 or NULL (depending on the default value defined). This patch adds a check on the mapping before editing the item. If there is no mapping, the DB value is not erased. Test plan: 1/ Edit an item and fill a value for a field 2/ Unmap this field 3/ Edit the item 4/ Verify that the value is not erased (using the MySQL CLI) Signed-off-by: Owen Leonard <oleonard@myacpl.org> This works as described in the test plan. After unmapping the field edits to the item did not result in loss of the data in that field. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl Assignee|gmcharlt@gmail.com |jonathan.druart@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #20 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- I will be looking at both patches soon (the version of Olli and Jonathan) in connection to QA if not passed by someone else :) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact| |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #30350|[SIGNED-OFF] Bug 7817: A DB |[SIGNED-OFF COUNTERPATCH] description|field without a default |Bug 7817: A DB field |mapping is set to a default |without a default mapping |value on editing |is set to a default value | |on editing -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #21 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 30923 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30923&action=edit Bug 7817 - Items Permanent location (shelving location) is set to NULL when item is edited A quick fix to prevent more damages. No perceived side-effects so far. Signed-off-by: David Cook <dcook@prosentient.com.au> This is actually a perfectly good fix for this issue. I've changed the explanatory comment to explain why. Another option would be to remove the 'exists' check in the sub _do_column_fixes_for_mod(), but this is just as functional. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Detailed comment on Bugzilla. Adding a small follow-up. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #30923|Bug 7817 - Items Permanent |[SIGNED_OFF ORIGINAL] Bug description|location (shelving |7817 - Items Permanent |location) is set to NULL |location (shelving |when item is edited |location) is set to NULL | |when item is edited -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #22 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 30924 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30924&action=edit Bug 7817: [QA FOLLOW-UP FOR ORIGINAL] QA Follow-up for original patch This patch removes the commented line for permanent_location. It adds a more general comment. It also adjusts the exists check on permanent_location. Furthermore, it removes the line for paidfor too. Also an internal field that was being cleared when editing items (same logic). Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion --- Comment #23 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- QA Comment: I looked at the first signed patch and also the signed counterpatch. I have a strong preference for the original patch. I think that the reason for failing QA on that patch was not really valid. If failed because "If a library decides to map permanent_location to a marc field, they will be unable to set it to a null value." A library should never decide that. Someone who maps permanent_location to a marc field, is doing something very weird! This item field is really a Koha internal for e.g. the CART functions. Nobody should use it for another reason (same for a few other item fields). We could hide such fields from using them in admin/koha2marclinks.pl and admin/marc_subfields_structure.pl (new report?) I think that one of the reasons for this problem is the historically grown 'hybrid' approach of items in Koha. We offer a MARC structure to edit them, but we do not save them in MARC but just in item fields. When saving an edited item, we call ModItemFromMarc with its default_values_for_mod_from_marc hash. Jonathan rebuilds this hash, but imo we should more focus on this subroutine. Let the subroutine only map the 952 fields to item fields, instead of doing what it does now (new marc record, transformMarcToKoha, get_unlinked_fields, etc.) This is too complicated. The second patch does not simplify the situation (not saying that it is theoretically correct btw). The first patch removes a non-marc item field from the default_values_for_mod_from_marc hash. This is a correct action; it should not be there. Other non-marc item fields should not be there either. Like paidfor (see follow-up). The counterpatch is a more drastic approach. It is not simple as mentioned. It does a lot more so it will add at least some to performance. And since it touches a lot more, it should be tested a lot more. I would favor pushing the first patch and refactor ModItemFromMarc with the counterpatch as a base. I will add a followup for the first patch and unhide the first patch, leaving the counterpatch as-is and set this report to In Discussion for one or two weeks, allowing all involved to give their opinion too. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #24 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- First point for the discussion (with thanks to cait): Should we add a dbrev (here) for installations that mapped internal fields to their MARC structure in Koha? Or at least check permanent_location and paidfor under this report? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #25 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think we need to make sure to cause no data loss for libraries that have changed the mappings. Maybe we should concentrate on the permanent location first with this patch and then concentrate on the paidfor in another patch series. Because... this paidfor is a bit of a mess: I researched a bit and until Fri, 18 Jul 2008: http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=bc408475f8afb0df... we delivered the standard frameworks with the nonpublic note mapped to paidfor. As there was never an update to change this, this would still be the case for older installations. I know the mapping exists in some of our installations that date back to 3.2. Also, it looks like the mapping still exists in the _current_ MARC21 FA frameworks (de-DE, en, es-ES, it-IT, nb-NO) and some UNIMARC frameworks. So the mappings are inconsistent right now. Bug 4222 tried to introduce a new database column for the nonpublic note, but sadly it's currently stuck in Failed QA because of some remaining problems with the last patch. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #26 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #25)
I think we need to make sure to cause no data loss for libraries that have changed the mappings. Maybe we should concentrate on the permanent location first with this patch and then concentrate on the paidfor in another patch series.
Thanks for looking at paidfor. I will open up a new report for that one and remove it from the follow-up. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #30924|0 |1 is obsolete| | --- Comment #27 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 31133 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31133&action=edit [QA FOLLOW-UP FOR ORIGINAL] Bug 7817: Follow-up for original patch This patch removes the commented line for permanent_location. It adds a more general comment. Adjusts the exists check on permanent_location. Adds a reference to bug 12817 that will deal with paidfor similarly. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=12817 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #28 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- I will open another new report for a dbrev that moves a mapped permanent_location (which should NOT be mapped!!) to the more_subfields_xml item field. That should be tested on its own. What I propose here, is add a dbrev warning if a library did map it. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=12818 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #29 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 31134 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31134&action=edit Bug 7817: QA Follow-up: Print a warning when permanent location is mapped Item field permanent location should not be mapped to the MARC structure. If a library did so, this dbrev will print a warning. If refers to report 12818 for help in moving the data to more_subfields_xml. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Tested by putting permanent_location in and out of the MARC structure. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #30 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Will leave this problem in discussion for another week to allow for further feedback. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #30350|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Passed QA --- Comment #31 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Moving the original patch now to Passed QA. (See comment23.) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #32 from Jonathan Druart <jonathan.druart@biblibre.com> --- (In reply to M. de Rooy from comment #31)
Moving the original patch now to Passed QA. (See comment23.)
What about the more generic way? Should we open a new bug report not to loose the patch (I understood that the only problem you found is the paidfor field)? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #33 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #32)
(In reply to M. de Rooy from comment #31)
Moving the original patch now to Passed QA. (See comment23.)
What about the more generic way? Should we open a new bug report not to loose the patch (I understood that the only problem you found is the paidfor field)?
Yes, please move it to a new report. Your patch could be the framework for refactoring ModItemFromMarc. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=12874 --- Comment #34 from Jonathan Druart <jonathan.druart@biblibre.com> --- (In reply to M. de Rooy from comment #33)
Yes, please move it to a new report.
Done, see bug 12874. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|jonathan.druart@biblibre.co |olli-antti.kivilahti@jns.fi |m | -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 --- Comment #35 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 31464 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31464&action=edit Bug 7817: (followup) add test on MARC bibliographic framework test Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master CC| |tomascohen@gmail.com --- Comment #36 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Patches pushed to master. Thanks Olli and Marcel. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=13026 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=13540 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org