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

[Bug 40914] New: 653 subject genre should display as a genre
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40914 Bug ID: 40914 Summary: 653 subject genre should display as a genre Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 187118 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187118&action=e… GENRE is not with the genres in the bibliographic detail view The second indicator of the 653 defines the index term category. For example, if the second indicator is a 6, the index term is assigned as a genre. However, Koha seems to consider the 653 as a general subject and ignores the second indicator. In the genre example, the index term should appear with the genres in the bibliographic detail view of the record, but it is not. To Replicate 1. Edit a record and add a 653_6 $a GENRE. Save 2. View the record and see the genre is included with the Subjects and not the Genres. (see attached image) Link the Library of Congress page for the 653. https://www.loc.gov/marc/bibliographic/bd653.html Consideration may be needed for the other categories. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 27637] New: Allow ReservesMaxPickUpDelay to be adjusted based on item values
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27637 Bug ID: 27637 Summary: Allow ReservesMaxPickUpDelay to be adjusted based on item values 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The syspref ReservesMaxPickUpDelay contains a number of days to be added to the current date in order to derive the expiration date for a hold. It allows no variation for item types, libraries, etc. I propose a new companion syspref of ReservesMaxPickUpDelayAdjustments (or something). It'd take a set of item table fields, values, and numbers to be added to the ReservesMaxPickUpDelay value. So something like: holdingbranch: CPL: 2 itype: DVD: -3 Would mean holds on items at CPL would get 2 extra days, holds on DVDs would get 3 fewer days. Whatever syntax we arrive at should allow grouping conditions, so a library could adjust pickup delays for only a specific itype at a specific branch, for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 40912] New: Receive shipments button requires full acquisitions permissions not just order_receive
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40912 Bug ID: 40912 Summary: Receive shipments button requires full acquisitions permissions not just order_receive Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org The permission check to display the Receive shipments button in the Vendors table and Vendors page requires full acquisitions permissions. (Any route like koha/acquisition/vendors) It doesn't just check just for the sub permission order_receive. >From VendorShow.vue line 48: <ToolbarButton v-if=" vendor.active && vendor.baskets_count > 0 && isUserPermitted('CAN_user_acquisition_order_receive') " :to="{ path: '/cgi-bin/koha/acqui/parcels.pl', query: { booksellerid: vendor.id }, }" icon="inbox" :title="$__('Receive shipments')" callback="redirect" /> This looks like it should work to check for the order_receive sub permission, but it only renders when the user has full acquisitions permissions. This is similar to bug 40684, so my guess is it needs a similar fix in /api/v1/swagger/paths/acquisitions_orders.yaml -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 --- Comment #13 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- (In reply to Julian Maurice from comment #11) > Ah sorry I forgot to include it in the test plan: you need to run > misc/devel/update_dbix_class_files.pl and restart koha Doh, I shoulda thought of that. Thanks! I've signed this off, but if someone replaces my SO I'd be happy to QA. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #187050|0 |1 is obsolete| | --- Comment #12 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Created attachment 187105 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187105&action=e… Bug 15248: Use record matching rules to find duplicate while cataloging This patch allows to configure how Koha searches for duplicates when cataloging manually by using a record matching rule. For each framework we can now set a record matching rule to use when searching for duplicates. This allow to use different matching rules while in acquisition for instance (ACQ framework). If a matching rule is selected, we also have the ability to forbid the creation of duplicate: if a duplicate is found and this option is enabled, the usual option to create a duplicate will be hidden. If no matching rule is selected, then the default matching mechanism is used. Test plan: 1. Create a record matching rule matching on ISBN Threshold: 100 Record type: biblio Match point: Search index: "isbn" Score: 100 Tag: "020" (or "010" for UNIMARC) Subfields: "a" Offset: 0 Length: 0 Normalization rule: Remove spaces No match checks 2. Edit the default MARC framework and select the new matching rule and enable "Forbid duplicate creation" 3. Create a biblio with an ISBN 4. Make sure your new biblio is indexed in Zebra or ES 5. Try to create a biblio with the same ISBN. You should see a warning about the duplicate with no option to create the duplicate biblio 6. In the acquisitions module, in a basket add a new order from an external source (requires a configured Z39.50/SRU server) 7. Choose a record with an ISBN 8. Once the order is created, try to create a new order from an external source and choose the same record. You should see a warning about the duplicate. 9. Edit the record matching rule and disable "Forbid duplicate creation" 10. Redo step 5. Now there should be an option to create the duplicate record. 11. Redo step 8. Now there should be an option to create the duplicate record. 12. Run the following test scripts: - t/db_dependent/Search.t - t/db_dependent/Matcher.t Sponsored-by: SCD Lyon2 Signed-off-by: Andrew Fuerste Henry <andrew(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35886] New: FindDuplicate only checks first ISBN
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35886 Bug ID: 35886 Summary: FindDuplicate only checks first ISBN Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When ordering a title via z39.50, the duplicate match is only done on the first ISBN. This can lead to duplicates being ordered and created. To recreate: 1. Have a record that you can find via z39.50 2. Copy the ISBN 3. In Acquisitions, create a basket 4. Add to basket from an external source 5. Using the copied ISBN, search a z39.50 source 6. Click the result and click Order --> It should warn for a duplicate 7. Click Cancel 8. Edit the record, add a second ISBN 9. Redo steps 4-6 --> It should warn for a duplicate 10. Click Cancel 11. Edit the record, place the second ISBN in first position 12. Redo steps 4-6 --> No duplicate warning! Note: if you cancel after step 12, the duplicate record will have been created. You will need to search your catalog and delete the record to redo the tests. I don't know if that is only in the case of z39.50 or if other types of orders also have that same problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35886 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7132] Check for duplicates when creating a new record in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7132 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #187062|0 |1 is obsolete| | --- Comment #5 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Created attachment 187103 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187103&action=e… Bug 7132: Acq: Check for duplicates when ordering from empty record To test using a new empty record: 1. Ensure you have a vendor and a new basket available for ordering. Click on “+Add to basket” and select “From a new (empty) record” 2. Choose an existing record to test with for example “CSS : the definitive guide” (http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=12&sear…) 3. Copy over the main details from the existing record in order to fill out the required details of the new order. I.e Title, and Koha item type. Click add item and then select a fund. It’s not necessary to fill anything else out. 4. Click save and notice that the duplicate record is not found. 5. Apply the patch and restart_all. Clear cache in your browser if necessary. 6. Repeat steps 2 - 4. This time a duplicate warning will appear. Ensure that all options of the duplicate warning work as expected. 7. Sign off and have a great day! Signed-off-by: Kim Gnerre <kgnerre(a)hotchkiss.org> -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 7132] Check for duplicates when creating a new record in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7132 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0