July 2015 - Koha-bugs - lists.koha-community.org

[Bug 12142] New: option to automatically add a processing fee when an item is marked lost
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '15

07 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12142 Bug ID: 12142 Summary: option to automatically add a processing fee when an item is marked lost Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice if there was a sys pref or something in the circ matrix that let you define a procession fee for when an item is marked lost. So if the item is marked lost either manually or automatically (with the cron) the system can charge a fee in addition to the lost item fee. Right now libraries are doing this manually. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 13540] New: Item's permanent_location is set to CART if an Item is edited when it's location is CART.
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '15

07 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13540 Bug ID: 13540 Summary: Item's permanent_location is set to CART if an Item is edited when it's location is CART. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com :-:TEST SETUP:-: 0a. System preference "ReturnToShelvingCart" must be 'Move'. 0b. Find any Item (I69) 0c. Set I69's location to "Book Cart" (BC) or anything but empty. :-:REPLICATE ISSUE:-: 1. Check-in the I69 and the location should turn to 'CART' (returned today). 2. Go to the "Edit Item"-view for I69, don't change anything, simply click "Save changes" 3. Observe that the permanent_location has changed to 'CART'. This is not good since now the location data is forever lost again (Bugg 7817). The "cart_to_shelf.pl --hours 24"-script cannot return the Item to the proper place ;( -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 10477] New: Increased flexibility for upload of Staged MARC records
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '15

07 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10477 Bug ID: 10477 Summary: Increased flexibility for upload of Staged MARC records Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: amitddng135(a)gmail.com Increased flexibility for upload of Staged MARC records. When uploading bulk MARC records against existing records - need further option to allow the process to just add/merge extra MARC tags rather than having to completely overwrite an existing record or just leave the existing record unchanged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 7646] New: Printing w/o the SQL Code showing
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '15

07 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7646 Priority: P5 - low Change sponsored?: --- Bug ID: 7646 Assignee: gmcharlt(a)gmail.com Summary: Printing w/o the SQL Code showing QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: ssammons(a)npelem.com Hardware: All Status: NEW Version: rel_3_6 Component: Reports Product: Koha I have made modifications to the template file. It added a text link to remove the SQL statement from the print view. Thus saving the need to use CSV/TSV exports. The print text will not show on the print out as is. I added a little .noprint class to the template file. Then I added my text with a print dialog and class change JS. Please see: http://pastebin.com/LWR3BqiW for the changes specifically lines 22-26 & line 501 -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 14583] New: Subfields not deleted when automatically merging authorities.
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14583 Bug ID: 14583 Summary: Subfields not deleted when automatically merging authorities. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: maxime.beaulieu(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This problem happens when editing autorities with syspref "dontmerge" enabled. Subfield deletion is not reflected in the referencing record. How to reproduce: 0) Set the "dontmerge" syspref to "Do" 1) Create an authority record. 2) Set values in the 245$a and 245$v subfields. 3) Edit or create a biliographic record and link the authority. 4) Edit the linked authority: remove the 245$v subfield add a value in the 245$z sufield 5) Check the authority values in the bibliographic record: The $v subfield is still there (merge failed) The $z subfield was added (merge worked) (subfields and $v and $z were arbitrarely chosen) A patch will follow. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 5264] New: Retain additional bibliographic subfields when merging authorities
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5264 Summary: Retain additional bibliographic subfields when merging authorities Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: PATCH-Sent Component: Cataloging AssignedTo: m.de.rooy(a)rijksmuseum.nl ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 The current code in AuthoritiesMarc.pm rewrites all subfields from the report tag in the authority record to fields in related bibliographic records when merging authorities. Additional subfields in the biblio records (e.g. relator code or term) are lost in the process. The patch retains the original algorithm but restores the additional subfields from the original biblio record when rewriting the linked marc fields. The problem also exists in 3.0. Two separate patches have been submitted. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 3

[Bug 14202] New: Unexpected parameter for window.open in marc21_linking_section plugin
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14202 Bug ID: 14202 Summary: Unexpected parameter for window.open in marc21_linking_section plugin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Code contains: window.open(\"/cgi-bin/koha/cataloguing/plugin_launcher.pl?plugin_name=marc21_linking_section.pl&index=\" + i + \"&result=\"+defaultvalue,\"marc21_field_7\"+i+\"\",'width=900,height=700,toolbar=false,scrollbars=yes'); The part ,\"marc21_field_7\"+i+\"\", is somewhat unexpected. If I am correct, js could interpret this as the name parameter of window.open. Note that this name is not the title. I propose to remove it. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 9614] New: Fines not assessed after renewing an item
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9614 Bug ID: 9614 Summary: Fines not assessed after renewing an item Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: elliott(a)bywatersolutions.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When an item is overdue and is renewed the fines that were assessed are removed. This is obviously not a desired behavior. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 10450] New: Editing serials predicts wrong
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10450 Bug ID: 10450 Summary: Editing serials predicts wrong Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: colin.campbell(a)ptfs-europe.com I have seen this happen since Koha 3.8 but thought it was just me - now I'm going to report a bug in case someone can track down the problem. Here's an example: ---- I have the July issue of Food & Wine in hand. I am in the Food & Wine serials record and filling in the date of next publication and the '# starts with' for predictions. I put 07/01/2013 for next publication and I put a 7 in the predictions chart (since I am starting these records off now) But when I go to check in the July issue, it gives 2013:8 for the issue and publication date as 08/01/2013. ---- This always happens when you edit an existing serial record's prediction pattern. No matter what you put in it always generates the next one - not the one you entered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 11496] New: The number of tested records when searching for duplicates during import is too low
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11496 Bug ID: 11496 Summary: The number of tested records when searching for duplicates during import is too low Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, only the first 10 records returned by koha for a given matchpoint are tested. This is not enough in some cases, because a significant matching record can be beyond these 10 first results. Please note that when the checkpoint is about fields with unique identifiers, like ISBN, the problem won't occur. On the other hand, when the checkpoint is about something less precise, like an author name, the matching record can be beyond the 10 first results. When that happens, the matchpoint will fail, the match threshold won't be reached, and a duplicate record will be created. -- You are receiving this mail because: You are watching all bug changes.

1 11