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

[Bug 32804] New: Importing and replacing items causes inconsistency when itemnumber match and biblio match disagree
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Bug ID: 32804 Summary: Importing and replacing items causes inconsistency when itemnumber match and biblio match disagree Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When 'Item processing' option during import is set to 'replace' itemnumber matches do not check any other data - so the item's biblionumber is set to the matched biblionumber, but the biblioitemnumber is not updated or checked This means that if you import a record containing an item with an itemnumber from another record you will end up with an item with mismatched biblio and biblioitem numbers This happens in consortia when multiple libraries have ordered the same biblio. Two biblios are created, later the final import with barcodes etc. is imported to replace items, and the more full bib is chosen for the biblio match, so items are half moved. To recreate: 1 - Be using the sample data in koha testing docker 2 - Stage the sample file on this report 3 - Match on KohaBiblio(999$c) / Item processing: replace 4 - Note the biblio match is "The complete novels / Austen, Jane" 5 - View the staged marc, note the barcode 39999000004090 in an item 6 - Search for that barcode 7 - You find biblio "Five novels : complete and unabridged / Gustave Flaubert" 8 - Import the file 9 - Check the db: SELECT * FROM items WHERE biblionumber != biblioitemnumber; 10 - Note the mismatch -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[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

[Bug 33173] New: Save and continue button in standard cataloging module broken
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33173 Bug ID: 33173 Summary: Save and continue button in standard cataloging module broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1 - Edit a record in the standard editor 2 - Click on to tab 2 3 - Click 'Save and continue' 4 - Error: tab is not defined -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15