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

[Bug 8425] New: Duplicate barcodes generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '15

04 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 Priority: P5 - low Change sponsored?: --- Bug ID: 8425 Assignee: koha-bugs(a)lists.koha-community.org Summary: Duplicate barcodes generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on Severity: normal Classification: Unclassified OS: All Reporter: dcook(a)prosentient.com.au Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha Duplicate barcodes are generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on. The problem is that you can accidentally attach 3 items to an order, but only 1 will be saved to the database. When you go to receive your order, you can only receive 1 item as the other two were never made, since the barcode wasn't unique. In 3.8.0, a software error comes up which prevent any item creation, I believe, but master (3.9.x) doesn't throw any warnings or errors. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 9047] New: show hold info on self check out
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '15

04 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9047 Priority: P5 - low Change sponsored?: --- Bug ID: 9047 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: show hold info on self check out Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha In the self-check UI, it would be great if patrons could view holds and place in the queue (like they can when they log in to the opac). It would also be nice if it showed what holds were ready for pick up - like it does on the staff circ screen. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 13909] New: _debar_user_on_return doesn't honour finesCalendar
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13909 Bug ID: 13909 Summary: _debar_user_on_return doesn't honour finesCalendar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The routine should be using C4::Overdues::_get_chargeable_units instead of an ad-hoc calculation of the overdue days to use as basis for the calculatio here: my $calendar = Koha::Calendar->new( branchcode => $branchcode ); # $deltadays is a DateTime::Duration object my $deltadays = $calendar->days_between( $dt_due, $dt_today ); To reproduce: - Set finesCalendar = "directly" - Have a circulation rule stating: interval for calculating fines = 1 suspension days = 3 - Have the calendar set for sunday and saturday as holidays. - Checkout an item with a branch/itype/borrower category that matches the defined circ rule with a hand-writen due date to (say) last friday. - Check the item in => FAIL: Notice that the user is debarred using the calendar (skipping saturday and sunday). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 14419] New: Expanding facets (Show more) performs a new search
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14419 Bug ID: 14419 Summary: Expanding facets (Show more) performs a new search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: nick(a)quecheelibrary.org QA Contact: testopia(a)bugs.koha-community.org Currently when loading facets for a page facets are calculated for the set number of records but only 5 are pushed to the html. Click the "Show more" link on any facet group requires performing the whole search again. If I am right, the heavy work is pulling facets from the records, so I say, why not push all the facets to the page and make them collapsible to save space? -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 14458] New: Add SwaggerUI documentation for RESTful API
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14458 Bug ID: 14458 Summary: Add SwaggerUI documentation for RESTful API Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 13799 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 9601] New: ccsr opac no results found ugly
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9601 Bug ID: 9601 Summary: ccsr opac no results found ugly Classification: Unclassified 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: nengard(a)gmail.com Created attachment 15280 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15280&action=edit no results In the CCSR template the no results page could use some work. See attached. The column on the left looks like it wants to appear and the text at the top is smooched together. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 12625] New: Delete component parts when deleting the parent from detailed-view
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12625 Bug ID: 12625 Summary: Delete component parts when deleting the parent from detailed-view 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: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl See Bug 11175 for explanation of component parts. This feature automatically deletes all linked component parts when the component parent is deleted using "catalogue/detail.pl -> Edit -> Delete record" Generalizing this to C4::Biblio::DelBiblio() is not a good idea because we don't wan't to delete all component parts when we are for example, merging records :) -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 12902] New: Cronjob monitoring script, nagios3 compatible
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12902 Bug ID: 12902 Summary: Cronjob monitoring script, nagios3 compatible Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: gmcharlt(a)gmail.com Created attachment 31509 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31509&action=edit initial patch After having issues with cronjobs not always running or getting regression issues, I decided to give a try to create a cronjobs monitoring solution. This patch introduces a wrapper script to log and time cronjobs. The wrapper script's log output is used to analyze whther cronjobs ran and if there were any errors. Also cronjobs timings can be validated to prevent nasty errors with for. ex. expiring waiting holds one day too early/late. This check can also be integrated to nagios! Also provided is a scaffold to start introducing more nagios-checks, with example command and service configurations. This patch introduces a koha_cronjobs-script to read the /var/spool/cron/crontabs/koha and analysz its contents. Then one can validate whether the cronjob timings are right (this is not mentioned in the manual at all) and what is right is (currently) based on my honest feelings. Then each cronjobs frequency is determined and the cronjobs log output is checked based on the script parameters. Currently the cronjob frequencies are split to minutely, hourly, daily, etc. Koha_cronjobs-script is meant to be ran on those intervals to catch errors ASAP. I would also like to hear what kind of cronjob timings other libraries use? -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 13660] New: rebuild_zebra_sliced.sh - Exclude export phase and use existing exported MARCXML.
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13660 Bug ID: 13660 Summary: rebuild_zebra_sliced.sh - Exclude export phase and use existing exported MARCXML. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org When looking for a bad MARC Record using the rebuild_zebra_sliced.sh, it is useful to skip the complete MARCXML exporting from Koha and reuse the exported files for Zebra indexing. This patch adds a new parameter: -x | --exclude-export Do not export Biblios from Koha, but use the existing export-dir Which depends on the: -d | --export-dir Where rebuild_zebra.pl will export data Default: $EXPORTDIR !---------! ! TEST PLAN ! !---------! 1. Run "./rebuild_zebra_sliced.sh --length 1000" to export 1000 MARC Records and slice them to one big 1000-Record chunk. 2. Realize that you get an imaginary "stack smashing detected"-error crashing your indexing at some Record you dont know of and can't make out from the indexing logging. 3. Start looking for the bad Record by running: "./rebuild_zebra_sliced.sh --exlude-export --chunk-size 10" To skip Biblios export from Koha which takes ~2h and get straight into splitting your exported biblios to chunks of 10, and importing them. You know which chunk fails so it is much easier to find the issue there. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 13807] New: SIPServer Input loop not checking for closed connections reliably
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13807 Bug ID: 13807 Summary: SIPServer Input loop not checking for closed connections reliably Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Debugging some sip connections found that a server could get stuck with a partially unread buffer when the remote closed the connection. This could mean it was also not responding to signals to shut down. Reworked the main loop to be a bit more careful about checking the connection status. Moved it from the Sip.pm module into the server where it seemed to belong more logically. Have been running this with some other modifications in production sites for some time and appears to have enhanced reliability and ability to control the server. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2