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

[Bug 30337] New: Holds to Pull ( pendingreserves.pl ) ignores holds if priority 1 hold is suspended
by bugzilla-daemon＠bugs.koha-community.org 05 May '23

05 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30337 Bug ID: 30337 Summary: Holds to Pull ( pendingreserves.pl ) ignores holds if priority 1 hold is suspended 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Holds to Pull ( pendingreserves.pl ) ignores holds if priority 1 hold is suspended, and shows the wrong number of "patrons with holds" which presumably tells the librarian how many copies to pull from the shelves. Test Plan: 1) Create a record with one or more holdable items 2) Place two holds on the record 3) Note they show in the holds to pull report 4) Suspend the priority 2 hold 5) Note the report continues showing that 2 patrons have holds 6) Resume the priority 2 hold 7) Suspend the priority 1 hold 8) Note the hold disappears from the holds to pull report 9) Apply this patch 10) Restart all the things! 11) Reload the holds to pull report 12) The report should show one hold that needs an item pulled to fill it! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 22714] New: ILL table population call might benefit from being inside the datatable
by bugzilla-daemon＠bugs.koha-community.org 05 May '23

05 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22714 Bug ID: 22714 Summary: ILL table population call might benefit from being inside the datatable 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: --- As pointed out by Owen (http://irc.koha-community.org/koha/2019-04-16#i_2134071) the ILL table doesn't display any "loading" message while the API call is in progress. It would be a better experience for the user if it did. We should investigate populating the table from within the datatable object, we will then get the benefit of then in built loading message. If not, we could always add a message manually. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 29303] New: quick add form duplicates HTML ID's
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29303 Bug ID: 29303 Summary: quick add form duplicates HTML ID's Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We noticed while trying to add some jQuery to the quick add from that there are duplicate id's on the page for each input. The jQuery on memberentrygen.tt checks to see what fields should be present on the quick_add_form and then uses jQuery clone() to add them to the quick_add_form. The problem is this creates duplicate ID's which is invalid HTML. We should change those cloned ID's so they are not duplicates. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 28641] New: ILLHiddenRequestStatuses does not consider custom statuses
by bugzilla-daemon＠bugs.koha-community.org 03 May '23

03 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28641 Bug ID: 28641 Summary: ILLHiddenRequestStatuses does not consider custom statuses Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com The ILLHiddenRequestStatuses syspref does a good job of filtering out requests that have statuses matching the specified values, but it doesn't take into account custom statuses. To demonstrate this, create a custom ILL status authorised value, give a request that value, then specify the status code in ILLHiddenRequestStatuses. Then view the list of requests, the list will contain the request with the custom status. Additional filtering needs to be added to filter out requests with a custom status code matching the specified values. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 29173] New: Button "replace authority record via Z39/50/SRU" doesn't work
by bugzilla-daemon＠bugs.koha-community.org 03 May '23

03 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29173 Bug ID: 29173 Summary: Button "replace authority record via Z39/50/SRU" doesn't work Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To replace an authority record via Z39.50/SRU there are two buttons on differents pages but their behaviour is not the same. One pre-fill the search form but the other don't. If I do: 1- go to the detail page of an authority record [Koha]/cgi-bin/koha/authorities/detail.pl?authid=[ID] where Koha is your instance of koha and ID is your authority id 2- On the menu Edit click on the button "Replace record via Z39.50/SRU" Then: "Z39.50 authority search points" pop up but all field are empty. But If I do: 1- go to the detail page of an authority record [Koha]/cgi-bin/koha/authorities/detail.pl?authid=[ID] where Koha is your instance of koha and ID is your authority id 2- On the menu Edit click on the button "Edit record" 3- Click on the button "Replace record via Z39.50/SRU search" Then: "Z39.50 authority search points" pop up with usefull values already filled (for example the Author) There is the same two button for bibliographic record and both of them pre-fill the form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 78

[Bug 29942] New: Spurious commit in mysql session storage
by bugzilla-daemon＠bugs.koha-community.org 03 May '23

03 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29942 Bug ID: 29942 Summary: Spurious commit in mysql session storage Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org The DBI storage driver for CGI::Session commits any on-going transactions in its destructor subroutine. Consequently if SessionStorage is set to mysql, instantiating a session and assigning it to a local variable inside a transaction will unexpectedly cause the transaction to be committed as illustrated by the below script. I have reported this issue upstream and created pull requests but it is unclear if anyone is maintaining CGI::Session. https://rt.cpan.org/Ticket/Display.html?id=140855 https://github.com/cromedome/cgi-session/pull/5 We should maybe consider maintaining our own fork of CGI::Session. #!/usr/bin/perl -w use DBI; use C4::Auth; use Koha::Database; use strict; my $dbh = C4::Context->dbh; my $schema = Koha::Database->schema; print "SessionStorage: '" . C4::Context->preference('SessionStorage') . "'\n"; sub test { my $session = C4::Auth::get_session(""); } $dbh->do("CREATE TABLE IF NOT EXISTS `tmp_test_cgi_session` (foo TINYTEXT)"); eval { $schema->txn_do(sub { my $sth = $dbh->prepare("INSERT INTO `tmp_test_cgi_session` VALUES ('foo')"); $sth->execute(); test(); die "error"; }); }; if ($@) { print $@, "\n"; } my $sth = $dbh->prepare("SELECT * FROM `tmp_test_cgi_session`;"); $sth->execute(); # The INSERT of the foo row should have been rolled back, but isn't when # SessionStorage is 'mysql'. while (my $row = $sth->fetchrow_arrayref) { print $row->[0], "\n"; } $dbh->do("DROP TABLE `tmp_test_cgi_session`"); -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 22718] New: Authorized value for not for loan not showed in cataloging search results
by bugzilla-daemon＠bugs.koha-community.org 02 May '23

02 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22718 Bug ID: 22718 Summary: Authorized value for not for loan not showed in cataloging search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- In the search results in cataloging module (staff client interface), the reason why an item is "not for loan" isn't showed (in the Location column) and can create some confusing situation. For example, some schools put the authorized values for online items and they can't be available for a physical loan but are always available. Are we able to add in the authorized value for the "not for loan" status, something like "not for loan (authorized value)" ? In the same manner as it appears in a normal search in the catalog. In the cataloging module, the info only appears in the detailed view of the item. Thanks, Alexandre -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 28093] New: Additional configuration option(s) for Shibboleth-only mode
by bugzilla-daemon＠bugs.koha-community.org 01 May '23

01 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28093 Bug ID: 28093 Summary: Additional configuration option(s) for Shibboleth-only mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: Boze.1(a)nd.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Regarding bug 18506 , in the staff client with Shibboleth Only Mode enabled, when one logs out, the user is immediately logged back in to the staff client. I understand that this is the intended behavior and could be solved by using Single LogOut (SLO). SLO, however, would log the user out of all current Shibboleth sessions, which would not be desirable (for us). In addition, if the user is already logged in to Shibboleth, when visiting the staff client for the first time, the user is automatically logged in without seeing a login page. We would find it preferable if there were an option for Shibboleth-only mode (in the staff client) to have a landing page that would prompt the user to log in (whether or not the user had already authenticated). If the user was already authenticated, the user would simply be passed on to the staff client without needing to provide credentials. On logout, the user would return to the landing page but not be logged out of Shibboleth. Another alternative could be to have a new option that would disable local logins (except for self checkout) if some other authentication method (CAS, Shibboleth) has been activated. Basically this would look the same as the current login page, but with no option for local login. On logout, the user would be returned to the login page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 27765] New: Unable to set a custom order to library branches on opac-library.pl
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27765 Bug ID: 27765 Summary: Unable to set a custom order to library branches on opac-library.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org Per this comment on #13388 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13388#c28 it's not possible to rearrange the order of library branches on the "Libraries" opac-library.pl page, they must be sorted alphabetically ascending. Alphabetical ordering isn't ideal for all library systems. For instance, we have three branches: Oakland, San Francisco, and a small Materials Library that's based in SF. Alphabetically, Materials comes first but it's the least generically useful. We generally list it last when we have the option e.g. when presenting branch hours. While this bug is related to the OPAC, I suspect that Koha Administration > Branches is ultimately what needs a change, adding an ordering component to the information stored about library branches which controls the opac-library.pl display. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 29607] New: addorderiso2709: The stored discount when importing an order from a file is invalid
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29607 Bug ID: 29607 Summary: addorderiso2709: The stored discount when importing an order from a file is invalid Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: christophe.torin(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org In the Acquisitions module : - Create a new vendor with a discount (Or select one that has a discount). Here the discount will be 25% - Create a new basket or select an existing one - Select "Add to basket" => From a staged file - Add an order from one of the file ==> Here, you can use a specific discount for the order, to override the vendor discount. The result should be quite the same if you do, but with this discount - The order is created ==> Modify the order - The discount is 0.25% instead of 25% Note that the prices are initially correctly calculated, but the discount value will appear as false. Plus, if you modify the order and change a price, the wrong discount will be used. In database, the discount is indeed stored as a value between 0 and 1, but only in that case (for the vendor, it is the actual percentage, and when you create an order from anoher source, it is stored correctly) This was reported on Koha 20.11, but is still relevant on master. In the code, this happens because the discount value is first divided by 100 to calculate the price, but it is that divided value that is stored in database, instead of the whole percentage value. On the master branch, in the file Koha/acqui/addorderiso2709.pl, the line where it's done are lines 166, 279 and 340 What I would suggest is : - Remove the division per 100 on those lines (166, 279 and 340) - Divide per 100 only when calculating the price (lines 283, 285, 344, 346) ==> ( 1 - $c/100 ) instead of ( 1 - $c ) - In the template (for importing from file), add a "%" just to be clear that the discount is a percentage, and not a value between 0 and 1 I know there was a kind of security (divide by 100 if the input is > 1), but it could be the other way around (multiply by 100 if the input is < 1). But as it is based on the field that is in the form, with a simple "%" indication it should not be needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19