September 2019 - Koha-bugs - lists.koha-community.org

[Bug 22305] New: Add syspref to allow ILL to be hidden in OPAC
by bugzilla-daemon＠bugs.koha-community.org 24 May '20

24 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22305 Bug ID: 22305 Summary: Add syspref to allow ILL to be hidden in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Target Milestone: --- It is conceivable that a site may only want ILL to be a staff function. Currently it is all or nothing, i.e. if it's enabled it appears for staff and patrons. We should add a syspref to allow it to be hidden outside the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 21727] New: Add Koha::Account::update_debit
by bugzilla-daemon＠bugs.koha-community.org 24 May '20

24 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21727 Bug ID: 21727 Summary: Add Koha::Account::update_debit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org There should be a high-level method for update existing debits, similar to Koha::Account::add_credit and Koha::Account::add_debit It will handle updating the line, and adding an offset. Envisaged use case is for debit amendments and fine increments. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 62

[Bug 23257] New: OPACHoldsIfAvailableAtPickup not working correctly for single branch installations
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23257 Bug ID: 23257 Summary: OPACHoldsIfAvailableAtPickup not working correctly for single branch installations Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Found this testing in 17.11, needs to be confirmed for versions higher up: - Have only 1 library in your system - Set OPACHoldsIfAvailableAtPickup to "not allow" - Create a circulation condition allowing "on shelf holds" - Go to the OPAC - try to place a hold. It won't be possible. (NOT OK) - Go to the staff side- try to place ahold. It will be possible. (OK) - Change the pref - Holds should work in both staff and OPAC. - Change the pref back to "not allow", add a second library - Holds will be possible. (NOT OK it requires a second library) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 22572] New: Garbled content of MARC control fields in MARC view
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22572 Bug ID: 22572 Summary: Garbled content of MARC control fields in MARC view Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- MARC control fields consist of a fix number of positions that can contain blanks. The "MARC view" in the Koha staff client and the Koha OPAC garbles the content of such fields when the field contains more than one consecutive blank - in this case more than one consecutive blank is automatically collapsed down by the webbrowser to just one. Additionally blanks may be trimmed at the end of the content of a field. For example MARC 008 does and must consist of exactly 40 positions, thus a line like the following (as shown via webbrowser in the MARC view) is always wrong: 800422s1978 sz a 1 ger In fact the correct content of MARC 008 would look like the following 800422s1978 sz a 1 ger Or better visible, when using # instead of blanks: 800422s1978####sz########a#####1###ger## Seemingly, this applies to all MARC control fields: 006 (fix length 18 positions), 007 (variable length of up to 23 positions), 008 (fix length of 40 positions). In the database the content of these fields is correct. Maybe before showing the blank character in the "MARC view" it should be coded as HTML entity   so the webbrowser doesn't collapse it. Also it may be a good idea to show the beginning and the end of such fields because otherwise (like in the above example) it is not visible that the field does contain two positions with blanks at the end. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 19349] New: Allow to store biblio record' s creator and last modifier in MARC
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19349 Bug ID: 19349 Summary: Allow to store biblio record's creator and last modifier in MARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This will allow to store borrowernumber and name of biblio record's creator and last modifier in the MARC record. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 17932] New: Koha::Object should provide a TO_JSON method
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17932 Bug ID: 17932 Summary: Koha::Object should provide a TO_JSON method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The Koha::Object class should provide a TO_JSON method that prepares data for JSON output. Right now, booleans are returned as integer values, and thus invalid for JSON output as boolean values. -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 19410] New: Koha::Objects needs a ->search_for_api method
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19410 Bug ID: 19410 Summary: Koha::Objects needs a ->search_for_api method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We should extend Koha::Objects so searching can deal with squery parameters, specially handling pagination, results sorting, matching criteria, etc. This could be easily implemented using: - Bug 19196 (Pagination handling helpers) - Bug 19278 (Make REST api default page size configurable) - Bug 19234 (Query params handling helpers) - Bug 19369 (Query pagination to SQL::Abstract) - Bug 19370 (Query order by to SQL::Abstract) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 20567] New: "Holds per record (count)" limit is not enforced after item is captured for hold
by bugzilla-daemon＠bugs.koha-community.org 21 May '20

21 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20567 Bug ID: 20567 Summary: "Holds per record (count)" limit is not enforced after item is captured for hold Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: margaret(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 74042 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=74042&action=ed… Multiple holds on one item record in staff client "Holds per record (count)" limit is not enforced after an item on the record is captured for hold and moves from Pending to Waiting Pickup status. At this point it is possible to place another hold on that record in violation of the "Holds per record (count)" setting. I was able to replicate this behavior with the following steps: 1. Set "Holds per record (count)" to 1 for your patron category/item type rule 2. Create a record and add at least two items, making sure the MARC and Item Koha Item Type is filled in 3. Place a hold on the record for a patron 4. Check in one of the items and confirm/transfer/capture the hold for the patron 5. Place a second hold on the same record for the same patron In either Staff or Opac the second hold on this bib is allowed after the first hold moves to Waiting for Pickup status. I think that this problem is very closely related to bugzilla 17978 and or 15404, but I did not see a specific mention of the "Holds per record (count)" limit upon perusal of those bugs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 22917] New: Circulation.t fails if tests are ran slowly
by bugzilla-daemon＠bugs.koha-community.org 21 May '20

21 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22917 Bug ID: 22917 Summary: Circulation.t fails if tests are ran slowly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- After bug 21213 we wanted to know why Circulation.t was failing randomly on a given test. Since it is pushed, it failed (at least) twice, with the same error: # Failed test 'AddReturn must have debarred the patron' # at t/db_dependent/Circulation.t line 3112. # got: '' # expected: '1' # AddReturn returned message $VAR1 = { # 'WasReturned' => 1 # }; # Failed test 'Test at line 1918' # at t/db_dependent/Circulation.t line 3116. # got: '0' # expected: '1' # Failed test 'Test at line 1918' # at t/db_dependent/Circulation.t line 3119. # got: undef # expected: '2019-05-30' # Looks like you failed 3 tests of 21. The test at line 3113 expects the flags 'WasReturned' and 'Debarred' to be set, but only WasReturned is. Which means the patron has not been debarred. It is not because the checkout has not been detected as overdue. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 23234] New: Circulation.t failing on June 28th 2019
by bugzilla-daemon＠bugs.koha-community.org 21 May '20

21 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23234 Bug ID: 23234 Summary: Circulation.t failing on June 28th 2019 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Not sure what is behind this. kohadev-koha@kohadevbox:/home/vagrant/kohaclone$ date Fri Jun 28 13:02:16 -05 2019 kohadev-koha@kohadevbox:/home/vagrant/kohaclone$ prove t/db_dependent/Circulation.t # Failed test 'Cannot auto renew, too late - no_auto_renewal_after is inclusive(returned code is auto_too_late)' # at t/db_dependent/Circulation.t line 691. # got: 'auto_too_soon' # expected: 'auto_too_late' # Looks like you failed 1 test of 14. # Failed test 'too_late_renewal / no_auto_renewal_after' # at t/db_dependent/Circulation.t line 722. # Failed test 'GetLatestAutoRenewDate should return -5 days if no_auto_renewal_after = 5 and date_due is 10 days before' # at t/db_dependent/Circulation.t line 862. # got: '2019-06-23T18:01:00' # expected: '2019-06-23T18:01:00' # Failed test 'GetLatestAutoRenewDate should return +5 days if no_auto_renewal_after = 15 and date_due is 10 days before' # at t/db_dependent/Circulation.t line 869. # got: '2019-07-03T18:01:00' # expected: '2019-07-03T18:01:00' # Failed test 'GetLatestAutoRenewDate should return +2 days if no_auto_renewal_after_hard_limit is defined and not no_auto_renewal_after' # at t/db_dependent/Circulation.t line 876. # got: '2019-06-30T00:00:00' # expected: '2019-06-30T00:00:00' # Failed test 'GetLatestAutoRenewDate should return +2 days if no_auto_renewal_after_hard_limit is < no_auto_renewal_after' # at t/db_dependent/Circulation.t line 882. # got: '2019-06-30T00:00:00' # expected: '2019-06-30T00:00:00' # Looks like you failed 4 tests of 5. # Failed test 'GetLatestAutoRenewDate' # at t/db_dependent/Circulation.t line 887. # Looks like you failed 2 tests of 71. # Failed test 'CanBookBeRenewed tests' # at t/db_dependent/Circulation.t line 998. # Failed test 'AddReturn must have debarred the patron' # at t/db_dependent/Circulation.t line 86. # got: '' # expected: '1' # AddReturn returned message $VAR1 = { # 'WasReturned' => 1 # }; # Failed test 'Test at line 1967' # at t/db_dependent/Circulation.t line 90. # got: '0' # expected: '1' # Failed test 'Test at line 1967' # at t/db_dependent/Circulation.t line 93. # got: undef # expected: '2019-07-12' # Looks like you failed 3 tests of 21. # Failed test 'AddReturn + suspension_chargeperiod' # at t/db_dependent/Circulation.t line 1976. # Looks like you failed 2 tests of 45. t/db_dependent/Circulation.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/45 subtests Test Summary Report ------------------- t/db_dependent/Circulation.t (Wstat: 512 Tests: 45 Failed: 2) Failed tests: 15, 29 Non-zero exit status: 2 Files=1, Tests=45, 27 wallclock secs ( 0.08 usr 0.01 sys + 19.81 cusr 4.37 csys = 24.27 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

1 15