March 2012 - Koha-bugs - lists.koha-community.org

[Bug 7597] New: fines not recording the right info in the stats table
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7597 Bug #: 7597 Summary: fines not recording the right info in the stats table Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com I did some testing today of paying fines and watched my DB only to find that the data being recorded when writing off a fine is wrong. http://screencast.com/t/XuhUtQRMccr When you write off a fine it's using the wrong branch code and it seems to be writing off the wrong amount altogether. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 26

[Bug 7485] New: Cannot edit barcode on Fast Add
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7485 Bug #: 7485 Summary: Cannot edit barcode on Fast Add Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha.sekjal(a)gmail.com When new records use the fast add/ill framework, after initially adding an item record, including its barcode, when you go back to edit the item record, the barcode field is not editable -- in fact, nothing displays in the barcode field! (see attached) I replicated this behavior using both the Fast Cataloging link under Circulation, and by starting a new record from the Cataloging module using the Fast Add framework. I was able to temporarily resolve this for one of our libraries by having her switch the record framework to default. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 10

[Bug 6372] New: Batch progress bar does not check for 0 size jobs; should be in separate js too
by bugzilla-daemon＠bugs.koha-community.org 08 May '12

08 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6372 Bug #: 6372 Summary: Batch progress bar does not check for 0 size jobs; should be in separate js too Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Batch progress bar does not check for 0 size jobs, and divides by 0, with unpredictable effects. Also, putting progress bar javascript inline makes it impossible to debug. It is possible that this change will improve situation with some bugs reported against background jobs that use progress bar. -- 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 15

[Bug 7588] New: adding reserve restrictions after cataloging items can cause non-holdable items to be picked for holds
by bugzilla-daemon＠bugs.koha-community.org 08 May '12

08 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7588 Bug #: 7588 Summary: adding reserve restrictions after cataloging items can cause non-holdable items to be picked for holds Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests AssignedTo: koha.sekjal(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com When items are originally cataloged with an unrestricted item type and subsequently edited to a restricted item type with a restriction of 'home library' or 'No Holds,' Koha treats the item as unrestricted and allows those items to fill holds even after they are changed to a restricted i-type...because they were unrestricted at the time the hold was placed. The work around for this is to 1. make sure that your holdability rules are defined before you catalog items and allow patrons to place holds. 2. catalog restricted item types as restricted from the very start. I'm not sure how we can actually *fix* this bug, but I wanted to document the workaround. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 7528] New: amount subtracting 1 cent
by bugzilla-daemon＠bugs.koha-community.org 04 May '12

04 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7528 Bug #: 7528 Summary: amount subtracting 1 cent Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 - low Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com When adding an order if you enter an amount and hit tab it puts the amount minus 1 cent in the next couple fields - see here: http://screencast.com/t/SbVVtte8zHvk It's crazy - and critical that it be fixed. Nicole -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 9

[Bug 7816] New: use encoding(UTF-8) not utf-8 for output streams
by bugzilla-daemon＠bugs.koha-community.org 04 May '12

04 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7816 Priority: P5 - low Change sponsored?: --- Bug ID: 7816 Assignee: gmcharlt(a)gmail.com Summary: use encoding(UTF-8) not utf-8 for output streams QA Contact: koha.sekjal(a)gmail.com Severity: minor Classification: Unclassified OS: All Reporter: colin.campbell(a)ptfs-europe.com Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Product: Koha Setting :utf-8 on output streams flags the stream as unicode but does not ensure output is encoded as such using ':encoding(UTF-8) is the correct call. Fixed already in most files authorities/ysearch.pl reintroduces a case of not using encoding and causes make test to fail if TEST_QA is set -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 7701] New: Error when sending serial alerts
by bugzilla-daemon＠bugs.koha-community.org 04 May '12

04 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7701 Priority: P5 - low Change sponsored?: --- Bug ID: 7701 Assignee: gmcharlt(a)gmail.com Summary: Error when sending serial alerts QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Product: Koha Probably due to bug 6875, C4::Letters is no longer used by C4::Serials, so that when SendAlerts is called (exactly when this happens is a mystery to me), you will get an error. Adding a "require C4::Letters;" and prefixing SendAlerts to C4::Letters:: should fix it. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 7451] New: PrepareItemrecordDisplay missing $subfield_data{id} which breaks AJAX value_builders
by bugzilla-daemon＠bugs.koha-community.org 04 May '12

04 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7451 Bug #: 7451 Summary: PrepareItemrecordDisplay missing $subfield_data{id} which breaks AJAX value_builders Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: dpavlin(a)rot13.org QAContact: ian.walls(a)bywatersolutions.com When using value_builders which have AJAX callback (like cataloguing/value_builder/stocknumberam123.pl) we get JavaScript error in browser because we are not initializing $subfield_data{id} (which is used as unique identifier for this particular field instance). This problem is also evident as warnings in intranet error log like this: Use of uninitialized value $subfield_data{"id"} in concatenation (.) or string at /srv/koha_ffzg//C4/Biblio.pm line 2664 but this affect just hidden fields and is not fatal, as opposed to AJAX example which breaks functionality. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 23

[Bug 7778] New: Not possible to add new z39.50 servers
by bugzilla-daemon＠bugs.koha-community.org 04 May '12

04 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7778 Priority: P5 - low Change sponsored?: --- Bug ID: 7778 Assignee: gmcharlt(a)gmail.com Summary: Not possible to add new z39.50 servers QA Contact: koha.sekjal(a)gmail.com Severity: blocker Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: Z39.50 / SRU / OpenSearch Servers Product: Koha It's not possible to add a new z39.50 server in current master. After saving you get a success message, but the server is not added. The logs show an error: [Wed Mar 21 12:20:42 2012] [error] [client 127.0.0.1] [Wed Mar 21 12:20:42 2012] z3950servers.pl: DBD::mysql::st execute failed: called with 9 bind variables when 10 are needed at /home/katrin/kohaclone/admin/z3950servers.pl line 115., referer: http://localhost:8080/cgi-bin/koha/admin/z3950servers.pl?op=add_form -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 7786] New: Adding More Lists to the Add-to combo of staff search results
by bugzilla-daemon＠bugs.koha-community.org 03 May '12

03 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7786 Priority: P5 - low Change sponsored?: --- Bug ID: 7786 Assignee: m.de.rooy(a)rijksmuseum.nl Summary: Adding More Lists to the Add-to combo of staff search results QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: m.de.rooy(a)rijksmuseum.nl Hardware: All Status: ASSIGNED Version: master Component: Virtual Shelves Product: Koha This report complements report 7732 for staff side. Difference is that the option More Lists was never in the staff client. Just as in report 7732 I am adding this option to the combo if the number of lists exceeds 9 for private or public. Testplan: Have <=9 private lists and <=9 public lists. The more lists option should not be in the Add to combo in catalogue search results. Add some private lists so that count>9. Check again (refresh). The option More Lists should come up now at the end of the list just before New List. -- You are receiving this mail because: You are watching all bug changes.

1 8