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

[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 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 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

[Bug 13391] New: MARC 008 builder plugin not compatible with browser autocompletion
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13391 Bug ID: 13391 Summary: MARC 008 builder plugin not compatible with browser autocompletion Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the koha-tmpl/intranet-tmpl/prog/en/js/xmlControlfield.js (line 317) there are two JS events (onkeyup and onfocus) being handled for 008 MARC plugin <input ...> fields (for MARC21 008 plugin, <input> is used e.g. for dates, country codes and language codes). But there is a slight problem with onkeyup event handler: apparently this event does not fire when: - user starts to enter some characters using the keyboard, - and then chooses something from the autocompletion list offered by browser. End result is that in such circumstances only the first character[s] entered in the given field are saved in 008 (only the part that was typed on the keyboard), and the remaining characters are effectively lost / being ignored by 008 plugin (unless the user "returns" to this field, i.e. gives it focus once again, before clicking "OK"). Replacing 'onkeyup' with 'oninput' in line 317 looks like the easiest solution for this issue; it works fine in recent (HTML5 compliant) browsers, but OnInput event handler is relatively new thing - it would not work in old, "legacy" WWW browsers. I guess we can also add autocomplete='off' to the <input> fields generated by renderPositions() function in xmlControlfield.js ;). I'm wondering what would happen if we try to put both oninput=.. and onkeyup= event handlers in those fields (probably both of them would fire when user enters something, but maybe that will be not necessarily such a bad thing ?). However, none of those methods are quite sufficient for older browsers. Reparsing all fields on form submit may help a little bit - so changes in the entered values which may have been previously ignored by the plugin would have a chance to be saved in 008 after all - but that's only a partial solution, the 008 contents being displayed on top may still sometimes get "out of sync" with the individual values below.. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 13435] New: OPAC self registration can't find OPAC_REG_VERIFY notice if it is assigned to a branch
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '15

05 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13435 Bug ID: 13435 Summary: OPAC self registration can't find OPAC_REG_VERIFY notice if it is assigned to a branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Email verification can look very broken for multi branch systems - if there is no "all libraries" notice defined for "OPAC_REG_VERIFY," but one defined for a specific branch, the self registration code can't find the notice and thus the verification email is not sent. Additionally, this code will only ever return the "all libraries" version of this notice, as it never passes a branchcode - making this notice useless on a per-branch basis. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 9468] New: Add ability to hide items from purchase suggestions forms
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '15

05 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9468 Bug ID: 9468 Summary: Add ability to hide items from purchase suggestions forms 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: kyle(a)bywatersolutions.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 88