April 2014 - Koha-bugs - lists.koha-community.org

[Bug 7413] New: Allow OPAC renewal x days before due date
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '14

09 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7413 Bug #: 7413 Summary: Allow OPAC renewal x days before due date Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com Currently RenewalPeriodBase can be set to 2 different options: 1) When renewing checkouts, base the new due date on current date. This means that when a patron renews the item at the checkout date, the renewal counter will increment, but the due date will not change - the loan period is still the same. If he renews one day after checkout - he will get a reneal of one day and so on. 2) When renewing checkouts, base the new due date on the old date of the checkout. This means the renewals can be done immediately after checkout. So if you allow 3 renewals and a loan period of 4 weeks, the patron can log into his account and do all the renewals immediately. This will mean he effectively gets a loan period of 4 + 3*4 weeks = 16 weeks. I see no reason why a clever student shouldn't do this to make sure he can keep the text books as long as possible without any holds forcing him/her to return the books. One solution here would be to allow renewals only x days before the book is due. As the loan periods can be very different (overnight loans, 4 weeks, 7 days...) it would be cool if this could be implemented in circulation rules. -- 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 79

[Bug 12049] New: DatePicker not translated
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '14

08 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12049 Bug ID: 12049 Summary: DatePicker not translated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Tested on 3.14.05, the JavaScript calendar aka DatePicker is not translated in circulation page for date due and renew date (you see Now, Done ...). Strange because the page calls calendar.inc which contains translated texts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 12044] New: Checkout should not be possible if a patron's fines will block the transaction
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '14

08 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12044 Bug ID: 12044 Summary: Checkout should not be possible if a patron's fines will block the transaction Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a patron cannot check out because they are over the limit specified by the noissuescharge system preference and the logged in user doesn't have permission to override the limit the barcode input field should not appear. The user should see a message explaining that checking out is blocked by the outstanding charge. Currently the user is able to submit the barcode without any warnings about the block, and only after the page refreshes do they get a warning. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11984] New: Show number of item(s) on order in the catalogue holdings without having to create item records
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '14

06 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11984 Bug ID: 11984 Summary: Show number of item(s) on order in the catalogue holdings without having to create item records Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: imingchan(a)yahoo.com.au QA Contact: testopia(a)bugs.koha-community.org In OPAC/staff catalogue, show number of item(s) on order without having to create item record(s). We have opted to create item record only when receive ordered goods, because this allowed us to cancel an order, without also having to delete linked item record(s). Currently item record(s) must be created in order for such information to be presented in OPAC or staff catalogue. Ideally, "On Order" information should be presented similarly to number of reservation(s) attached to each catalogue record, such as: [Qty] on order; or [Qty] on order for [Holding Library 1]; [Qty] on order for [Holding Library 2], etc. Perhaps we then specify whether to show a grand quantity total on order, or quantity breakdown for each holding library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 12038] New: Need a provision to search specific barcode/accession number
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '14

05 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12038 Bug ID: 12038 Summary: Need a provision to search specific barcode/accession number 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: vimal0212(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Librarians need to search and find specific book using barcode. In present situation, advanced search has the provision to search barcode, it give a big list of books instead of single book. I think koha search barcode from xml, so it display a big list of books. We need to get details of specific book from advanced search. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8244] New: Script to find exporter problems
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '14

04 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8244 Priority: P5 - low Change sponsored?: --- Bug ID: 8244 CC: jonathan.druart(a)biblibre.com Assignee: julian.maurice(a)biblibre.com Summary: Script to find exporter problems Severity: enhancement Classification: Unclassified OS: All Reporter: julian.maurice(a)biblibre.com Hardware: All Status: NEW Version: master Component: Test Suite Product: Koha About one month ago, we (BibLibre) discover a bug in our source code. The problem was: a page that used to work correctly suddenly refuse to work because of "Undefined subroutine &get_infos_of at C4/Items.pm (line 1075)" (approximative message) in reserve/request.pl The piece of code in cause was a "use C4::Members" in C4/Budgets.pm. A modification of C4::Budgets was causing reserve/request.pl to crash... (ouch!) In fact it introduced a circular dependency. To avoid this kind of discovery, we decide to write a script that try to detect as many problems as possible. Patch and description follow. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 12007] New: http://manual.koha-community.org/3.12/en/basicparams.html#authorizedvalues needs more info
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '14

04 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12007 Bug ID: 12007 Summary: http://manual.koha-community.org/3.12/en/basicparams.h tml#authorizedvalues needs more info Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: nengard(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org "If you would like to limit this authorized value category to only specific libraries you can choose them from the 'Branches limitation' menu. To have it show for all libraries just choose 'All branches' at the top of the list." Please update information to explain that limiting branches doesn't affect items that already have the location being edited in use will be unaffected. Please explain that this only affects setting the location. If the location is set by another library that uses it, it will still appear in the record, regardless of your library. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 1993] Task Scheduler Needs Re-write
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '14

03 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1993 Galen Charlton <gmcharlt(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|12031 | -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 11487] New: Untranslatable tooltip "Dates of birth should be entered in the format ..."
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '14

03 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11487 Bug ID: 11487 Summary: Untranslatable tooltip "Dates of birth should be entered in the format ..." Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr The following text is not picked up by the translation toolchain: koha-tmpl/intranet-tmpl/prog/en/includes/patron-search.inc: content: 'Dates of birth should be entered in the format "[% format %]"', -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 12035] New: Purchase Order Overflows Incorrectly
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '14

03 Apr '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12035 Bug ID: 12035 Summary: Purchase Order Overflows Incorrectly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, if you add a large number of baskets while using a "OrderPdfFormat" of "pdfformat::layout3pages" or "pdfformat::layout3pagesfr", the basket table will overlap over the bottom footer (which includes the page numbers), and the overflow will start mid-way down the new page. This is because we've configured our PDF::Table objects incorrectly for the printbaskets() sub. Of course, the chances of having enough baskets in a basket group to trigger such an overflow might be quite small, so this might not happen very often. Still, it's a bug nonetheless. You can test it out by filling your database with bogus baskets; I've included some SQL at the bottom of this bug report to aid with that. Layout Config: layout3pages.pm,layout3pagesfr.pm: Current config for printbaskets: start_y => 230/mm, next_y => 230/mm, start_h => 230/mm, next_h => 230/mm, Note that the "next_y" and "next_h" are the same as the "start_*". This means that they'll start midway down the page on the new (overflow) page. My suggested replacement for printbaskets: start_y => 230/mm, #($start_y - $start_h = $bottom_margin), according to PDF::Table source code next_y => ($height - 5)/mm, start_h => 210/mm, next_h => ($height - 25)/mm, I'm using the $height variable here because that's the same measurement used by some page headers in the printorders() sub in this same module. -- The printorders() subs are all right in all the "OrderPdfFormat" options. The bottom margin is probably too large in layout3pages(fr).pm, but better too large than too small. layout2pages.pm: printorders: start_y => 285/mm, next_y => 285/mm, start_h => 260/mm, next_h => 260/mm, layout3pages.pm,layout3pagesfr.pm: printorders: start_y => 270/mm, next_y => 285/mm, start_h => 250/mm, next_h => 250/mm, --- [Note: the following SQL was created based on a Koha 3.8 database so YMMV.] *Create bogus baskets: INSERT INTO aqbasket Select null,rand() as basketname,note,booksellernote,contractnumber,creationdate,closedate,booksellerid,authorisedby,booksellerinvoicenumber,basketgroupid from kohatest38.aqbasket where basketno = 8; *Create bogus orders: INSERT INTO aqorders Select null, 1, entrydate,quantity,currency,listprice,totalamount,datereceived,booksellerinvoicenumber,freight,unitprice,quantityreceived,cancelledby,datecancellationprinted,notes,supplierreference,purchaseordernumber,subscription,serialid,(SELECT basketno FROM aqbasket WHERE basketno not in (select basketno from aqorders) limit 1) as 'basketno',biblioitemnumber,timestamp,rrp,ecost,gst,budget_id,budgetgroup_id,budgetdate,sort1,sort2,sort1_authcat,sort2_authcat,uncertainprice,claims_count,claimed_date from aqorders limit 1; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0