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

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #234 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- There are lots of signoffs on these patches, can this be marked Passed QA? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33632] New: Editing a list with multiple pages always returns to first page
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33632 Bug ID: 33632 Summary: Editing a list with multiple pages always returns to first page Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When removing items from page 3 of a 10 page list, the user is always returned to page 1 of the list once the browser refreshes the page. The user than has to navigate back to the page of the list they were working on to continuing to work. This is time consuming when working on large lists. To reproduce: 1. Create a list with enough items to have multiple pages. 2. Navigate to page 3 of the list. 3. Select a few items and remove them from the list. The user is then returned to page 1 of the list. It would be nice if the user was returned to the page they were on, which would be page 3 of this example and not page 1. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 31740] New: Illrequests table has a foreign key constraint on status_alias
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31740 Bug ID: 31740 Summary: Illrequests table has a foreign key constraint on status_alias Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I am not sure the intent of this foreign key, however it seems problematic as we can't tie it to a single category To test: 1 - Add an authorised value for Asort1: Authorised value: MONKEY Description: Capuchin 2 - Add an authroised value for LOC: Authorised value: MONKEY Description: Spider 3 - Put an illrequest in the DB: INSERT INTO illrequests (branchcode,status,status_alias) VALUES ('CPL','REQUEST_TEST','MONKEY') 4 - Delete one of the authorised values above 5 - Check the DB: SELECT status_alias FROM illrequests WHERE status = 'REQUEST_TEST' 6 - Note the status is nulled by deletion of unrelated authroised value -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 32130] New: Vue files must be kept tidy
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32130 Bug ID: 32130 Summary: Vue files must be kept tidy Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Keywords: rel_22_11_candidate Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 32030 We want to keep them tidy, and all use the them rules. To enforce that we should have a test in xt to catch possible discrepancies. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 33183] New: Error inserting matchpoint_components when creating record matching rules with MariaDB 10.6
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33183 Bug ID: 33183 Summary: Error inserting matchpoint_components when creating record matching rules with MariaDB 10.6 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The word "offset" is now a keyword. At the very least we need to escape the fieldname with backticks. It would be nice to switch to Koha::Objects for this module eventually. C4::Matcher::_store_matchpoint(): DBI Exception: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'offset, length) VALUES ('27', '1', '999'...' at line 2 at /usr/share/koha/lib/C4/Matcher.pm line 314 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 33150] New: Add specific message for renewal too_soon situation
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33150 Bug ID: 33150 Summary: Add specific message for renewal too_soon situation Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org The message "No renewals allowed" is incorrect when it is too soon for renewal. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 32519] New: In Elasticsearch mappings table add search field name
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32519 Bug ID: 32519 Summary: In Elasticsearch mappings table add search field name Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com In Elasticsearch mappings table, in tabs for mappings we should add search field name in addition to label ; in order to find them when searching using DataTable search field. This is very useful when debugging. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 33063] New: Duplicated reports should maintain subgroup of original
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33063 Bug ID: 33063 Summary: Duplicated reports should maintain subgroup of original Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org When one duplicates a report that's in a group, the new report defaults to going into the same group as the original. But if the original report also has a subgroup that is not passed on to the duplicate. A duplicated report should default to the same group *and* subgroup as its original. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[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

[Bug 33189] New: Plugin upload should prompt for kpz files
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33189 Bug ID: 33189 Summary: Plugin upload should prompt for kpz files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, when you click "Choose file" when uploading a plugin, it looks for "All Files (*.*)", but really we only ever want "*.kpz" files. By changing the HTML we should be able to make it only look for "*.kpz" files which should make uploads a bit more convenient. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15