July 2024 - Koha-bugs - lists.koha-community.org

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '24

31 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs(a)lists.koha-commun |baptiste.wojtkowski@biblibr |ity.org |e.com CC| |baptiste.wojtkowski@biblibr | |e.com --- Comment #15 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Note, the proposed approach does not solve any problem of concurrent accesses to barcode.pl but I do not think it could be resolved without refactoring barcode.pl. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '24

31 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 --- Comment #14 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Created attachment 169884 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169884&action=e… Bug 8425: Increment the barcode on each call of set_barcode() Duplicate barcodes are generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on. The problem is that you can accidentally attach 3 items to an order, but only 1 will be saved to the database. When you go to receive your order, you can only receive 1 item as the other two were never made, since the barcode wasn't unique. In 3.8.0, a software error comes up which prevent any item creation, I believe, but master (3.9.x) doesn't throw any warnings or errors. Yes.. This tries and solve a bug from 3.8.0 /o/ Test plan: 1 - set syspref "autoBarcode" to generated in the form <branchcode> yymm001 2 - set the barcode field to "barcode.pl" in marc structure 3 - create a new basket 4 - add one item to this basket 5 - click on the barcode field -> it should have a barcode 6 - click on add item and click on the new barcode fiels, it should have the same value APPLY PATCH: 7 - click on the barcode field -> it should have a barcode 8 - click on add item and click on the new barcode fields, it should have an higher barcode. Note : The barcode is incremented each time the barcode with an empty value is clicked on and only on "hbyymmincr" mode. Therefore, if the librarian removes the value from barcode and click again, they could get another barcode. I do not know if it is an issue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '24

31 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 --- Comment #13 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Created attachment 169883 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169883&action=e… Bug 8425: Add an offset parameter for barcode generation in hbyymmincr barcode.pl In order to propose a patch for 8425 and 30056, we need to have the possibility to ask for multiple barcodes without storing a new barcode. See 8425 and 30056 for more information. Note: Since 30056 also needs this patch, these are splitted in order to rebase easier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '24

31 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 35299] New: Allow for items with specific not for loan values to appear in the holds queue
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '24

31 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35299 Bug ID: 35299 Summary: Allow for items with specific not for loan values to appear in the holds queue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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: clemens.tubach(a)kit.edu, gmcharlt(a)gmail.com, michaela.sieber(a)kit.edu We’d like to be able to specify a list of not for loan values that will be considered eligible to fill holds and appear in the holds queue and ideally the pending holds list as well. These would usually be negative not for loan values, that can be placed on hold. It should be possible to still exempt some status, like -1 = on order. Use Case: In libraries with closed stacks there are often items that are not for loan, but can be requested for use in a reading room. Staff will then get the items and fill the holds, but they won't be checked out on self checks etc. An on-site checkout might be forced. (see Library of Congress: https://ask.loc.gov/law/faq/300644) In order for this process to work the library needs the information about the requested items in order to be able to pull the items in the closed stacks. We have tested a change in Holdsqueue.pm that works, but should be made properly configurable: https://git.koha-community.org/Koha-community/Koha/src/branch/master/C4/Hol… Change: $items_query .= " WHERE items.notforloan = 0 To: $items_query .= " WHERE items.notforloan in (-2, -3, 09) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 36717] New: Merge "Patrons (custom slip)" and "Patrons (custom message)" in Notices
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36717 Bug ID: 36717 Summary: Merge "Patrons (custom slip)" and "Patrons (custom message)" in Notices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org With the introduction of custom email messages in Bug 29393, we discussed (https://chat.koha-community.org/koha-community/pl/ixoy58im47dhpr4gmwtn9sdbjw) the opportunity to merge the "Patrons (custom slip)" notice type introduced in Bug 32986 and the new "Patrons (custom message)" notice type. The "custom slips" would be notices with the print message transport type, and the "custom messages" (email messages) would be notices with the email message transport type. To get there: 1. Go to Tools > Notices and slips 2. Click New notice --> Notice there is a category "Patrons (custom slip)" and (after bug 29393) "Patrons (custom message)" Create and use a custom slip 3. Click "Patrons (custom slip)" 4. Enter a code and a name (e.g. TESTSLIP, Test slip) 5. Click the "Print" tab 6. Enter content in the "Message subject" and "Message body" fields 7. Click "Save" 8. Go to a patron's account 9. Click "Print" --> There should be an option to "Print test slip" (or whatever name you gave it) Create and use a custom message 10. Go back to Tools > Notices and slips > New notice 11. Click "Patrons (custom message)" 12. Enter a code and a name (e.g. TESTMESSAGE, Test message) 13. Click the "Email" tab 14. Enter content in the "Message subject" and "Message body" fields 15. Click "Save" 16. Go to a patron's account 17. Make sure the patron has an email address 18. Click "Add message" 19. In "Add message for" choose Email --> In "Patron notice" there should be "Test message" (or whatever name you gave it) The proposition was to merge the two notice types and only show the ones with the "Print" message transport type filled in the "Print" menu, and only show the ones with the "Email" message transport type filled in the "Add message" menu. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 35189] New: Itemtypes SVG icons should be limited in height/width
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35189 Bug ID: 35189 Summary: Itemtypes SVG icons should be limited in height/width Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 158067 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=158067&action=e… Screenshot Steps to reproduce the issue: 1. On Staff interface, on Administration > Item types, modify any item 2. Choose an SVG image as a remote image for an Item type, for eg https://raw.githubusercontent.com/FortAwesome/Font-Awesome/afecf2af5d897b76… Save changes. When listed on itemtypes.pl the icon is not too big, but if you edit again the itemtype (using above SVG, more than 1200px width). This also impact at some degree on Advanced search (staff and OPAC, search.pl, opac-search.pl). -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 37527] New: Fix grammar in UpdateNotForLoanStatusOnCheckin example
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37527 Bug ID: 37527 Summary: Fix grammar in UpdateNotForLoanStatusOnCheckin example Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In Administration > System preferences, UpdateNotForLoanStatusOnCheckin currently has an example with the following explanation: "When an item is checked in, if it's item type matches CR then when the value on the left (1) matches the items' not for loan value it will be updated to the value on the right." It should be corrected to say: "When an item is checked in, if its item type matches CR and its not for loan value matches the value on the left (1), then the item's not for loan value will be updated to the value on the right." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37170] New: Elasticsearch is functioning correctly with indices being rebuilt and searchable, but the "About Koha" page incorrectly shows Elasticsearch as "not running."
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37170 Bug ID: 37170 Summary: Elasticsearch is functioning correctly with indices being rebuilt and searchable, but the "About Koha" page incorrectly shows Elasticsearch as "not running." Change sponsored?: --- Product: Koha Version: 24.05 Hardware: Macintosh OS: Other Status: NEW Severity: critical Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: aungmo(a)gmail.com I am experiencing an issue with the Koha "About Koha" page. Although Elasticsearch is functioning correctly (indices are being rebuilt, and records are searchable), the "About Koha" page displays Elasticsearch status as "not running." Steps to Reproduce: Set up Koha with Elasticsearch as the search engine. Successfully rebuild Elasticsearch indices using the command: docker exec -it koha koha-elasticsearch --rebuild --verbose -d mylibrary [436] Checking state of biblios index [436] Dropping and recreating biblios index [436] Checking state of authorities index [436] Dropping and recreating authorities index [436] Indexing biblios [436] Committing final records... [436] Total 1 records indexed [436] Indexing authorities [436] Committing final records... [436] Total 1 records indexed Perform searches in both OPAC and Staff interfaces, confirming that records are searchable. Navigate to the "About Koha" page. Expected Behavior: The "About Koha" page should display the Elasticsearch version, number of nodes, and status as running. Actual Behavior: The "About Koha" page displays: Elasticsearch: Version: | Nodes: | Status: not running System Information Koha version: 24.05.01.000 OS version: Linux 96b981d24116 6.6.31-linuxkit (running on macOS) Perl version: 5.036000 MySQL version: 10.6.18-MariaDB-ubu2004 Apache version: 2.4.59 (Debian) Elasticsearch version: 8.13.0 (single-node cluster) Deployment method: Docker Base image: debian Elasticsearch Configuration in koha-conf.xml: <elasticsearch> <server>elasticsearch:9200</server>  <index_name>koha_mylibrary</index_name>   <cxn_pool>Static</cxn_pool>   </elasticsearch> docker exec -it koha curl -X GET "http://elasticsearch:9200/_cluster/health?pretty" { "cluster_name" : "docker-cluster", "status" : "yellow", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 1, "active_primary_shards" : 10, "active_shards" : 10, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 10, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 50.0 } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 37521] New: KOHA ERM REPORT CANNOT BE AUTOMATED
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37521 Bug ID: 37521 Summary: KOHA ERM REPORT CANNOT BE AUTOMATED Change sponsored?: --- Product: Koha Version: 23.11 Hardware: HP OS: Windows Status: NEW Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: belal.ahmadi(a)uwl.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Hi, I wanted to automate koha ERM reports which are different from the normal custom reports that extract data from the tables. The reports on ERM can neither be automated nor the query for the report can be accessed. If the developers could add a feature to automate ERM eUsage reports, that would be ideal and very much appreciated. Best regards -- You are receiving this mail because: You are watching all bug changes.

1 2