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

[Bug 17328] New: Koha fixes for Mysql 5.7
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '21

19 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17328 Bug ID: 17328 Summary: Koha fixes for Mysql 5.7 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I'm accruing many little issues. while running the code. I'll put the patches in, at least to document them. If the powers-that-be decide to fix in differently, all the same to me. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 18191] New: REST API: Add endpoint to list valid pickup locations
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '21

18 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18191 Bug ID: 18191 Summary: REST API: Add endpoint to list valid pickup locations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Bug 7534, Bug 7614 and Bug 18072 let us limit the choices of pickup location when placing a hold. Add a REST API endpoint that uses this functionality. GET /biblios/{biblionumber}/pickuplocations GET /item/{itemnumber}/pickuplocations Returns an array of library-objects that represent a set of libraries that can be used as pickup locations for hold of the given biblio/item. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 21997] New: SIP patron information requests can lock patron out of account
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '21

18 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21997 Bug ID: 21997 Summary: SIP patron information requests can lock patron out of account Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Many SIP services send an empty password field (AD). Even if allow_empty_passwords is enabled for the given SIP account, this empty password is run though Koha's password checker which increments the number of login attempts for a patron. Thus repeated patron information requests can lock a patron out! Empty password fields in SIP should not call for a password check if allow_empty_passwords is enabled. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 18747] New: Select All in Add Patron Option in Patron Lists only selects the first 20 entries
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '21

16 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18747 Bug ID: 18747 Summary: Select All in Add Patron Option in Patron Lists only selects the first 20 entries Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: karen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Select all only selects the first 20 records in the Add Patrons option of Patron Lists, even if you change the view to show 50, 100, or all options. The expected behavior is that Select All would select all the options. To recreate this issue, go to Patrons -> Patron Lists -> Select a patron list -> Select Add Patrons in the Action button menu. Next, select 50, 100 or All entries to show. Then, click on Select All. Only the first 20 entries are selected, not all of the entries on the screen. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 21093] New: Problem when using specify due date with fast add
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '21

16 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21093 Bug ID: 21093 Summary: Problem when using specify due date with fast add 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the specify due date option and then created a fast add, the checkbox "Remember for sesssion" gets automatically checked and even after unchecking it and using "Clean" the date keeps reappearing until you switch to another patron account. To test: - Set the specify due date option to a date, don't check the checkbox - Enter an unknown barcode - Click on fast add - Add a record - Add an item (don't change the barcode!) - The item is checked out to the patron - Verify: The checkbox is "Remember for session" is checked now - Uncheck checkbox and clear the specified date - Check out another item - Verify that the date is back. So there is 2 problems here: - Checkbox should not check itself - it shoudl be able to clear the date -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 15883] New: Upgrade jQuery from v1.7.2 in the staff client
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '21

15 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15883 Bug ID: 15883 Summary: Upgrade jQuery from v1.7.2 in the staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 14546 In order to upgrade Bootstrap in the staff client we first need to upgrade jQuery. After discussing it some in IRC (http://irc.koha-community.org/koha/2016-02-22#i_1791968) this is the plan I'm working on right now: An initial patch will start by adding the basis for upgrades: 1. Add a new version of doc-head-close.inc which includes new version of jQuery and jQueryUI. That include file will be named doc-head-close-jquery.1.12.0.inc to reflect the version of jQuery it uses. 2. Add the 1.12.0 version of jQuery, naming the file jquery-1.12.0.min.js 3. Add the latest version of jQueryUI, 1.11.4, naming the files jquery-ui-1.11.4.js and jquery-ui-1.11.4.min.css. Subsequent patches can take a page-by-page approach to the upgrade, dropping in the new include file and making any upgrades necessary to Javascript on that page. As compatibility issues are discovered, affected JS files can be re-created with updated file names to reflect the jQuery version, as in "basket-jquery-1.12.0.js" Disadvantages to this method: 1. It's possible some patches will have to touch both doc-head-close.inc and doc-head-close-jquery.1.12.0.inc. However that file changes fairly seldom. 2. git history getting lost between files. Can it be done so that the new include file keeps the history of doc-head-close.inc and doc-head-close.inc is created as if it is the new file? Eventually it could be removed. I would like to hear opinions and suggestions about this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14546 [Bug 14546] Make staff client use Bootstrap -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 21932] New: reservetype and reserveexpiration needed for holds (reserves and old_reserves tables)
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21932 Bug ID: 21932 Summary: reservetype and reserveexpiration needed for holds (reserves and old_reserves tables) Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I see an inherent flaw in the reserves table and process. If a hold is waiting, and someone changes the status from waiting back to a priority level, the waiting status is removed, but the expiration remains. Also, if the hold was a first available hold, it is now changed to an item level hold for the item it was on hold for. I would suggest that a new field be created for the holds table, such as reservetype, and is marked as 'ANY' or 'SPECIFIC'. I would suggest that a new field be created for the reservation expiration called reserveexpiration, separate from the waiting expiration, as to maintain a reservation cutoff date if the status is changed back to a priority level. This would make the expirationdate exclusive to waiting items. I would suggest that when priority level is changed from waiting to a priority level, the reservetype is checked, and if it is marked as ANY, the item number be removed. If it is SPECIFIC, the item number is kept. I would suggest that the expirationdate be cleared if changed from a waiting status to a priority level. I would suggest that all pages that show the "Expiration date" as the reservationexpiration, if exists, or superseded by expirationdate, if exists. No need to have a separate cell for both. I would suggest that when a hold is triggered and marked as waiting, the expiration date is calculated, or limited to the reservationexpiration, whichever is shorter. No sense in holding it longer than the patron was willing to wait for it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 18328] New: There is no history for article request
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '21

11 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18328 Bug ID: 18328 Summary: There is no history for article request Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Il would be useful if the "Cancelled requests" and "Completed requests" of articles request were kept in different tabs, just like it exists for acquisition suggestions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 22004] New: When decreaseLoanHighHolds is set to Enable, suspended holds still count in the number of holds
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '21

08 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22004 Bug ID: 22004 Summary: When decreaseLoanHighHolds is set to Enable, suspended holds still count in the number of holds Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The system preference decreaseLoanHighHolds if set to enable allows the library to modify the checkout length if a records has X number of holds. Unfortunately, Koha will look at the holds and determine to use this system preference and not discard the suspended holds. For example if a library had this system preference to decrease the loan period if a record has 2 holds on it, if there are 2 holds on the item, but one hold has been suspended, then Koha should not decrease the checkout period - however it does. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18017] New: [Unimarc] Importing biblios from Z39.50 servers duplicates related authorities
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '21

08 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18017 Bug ID: 18017 Summary: [Unimarc] Importing biblios from Z39.50 servers duplicates related authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is a unimarc bug only: When importing biblios from Z39.50, related authorities are wrong matched by the linker. This causes duplicates of authorities. The problem come from a bad marc definition in unimarc/authorities/authority-koha-indexdefs.xml which does not create a index for matching an entire heading. -- You are receiving this mail because: You are watching all bug changes.

1 43