commit 4095a9d568779e6f0064ce28611bd4b9b2c9c3a4 Author: Lucas Gass Date: Thu Nov 20 21:58:57 2025 +0000 Bug 9750: DB updates commit e251be1a8f0df09273b429a3d0aea1e16ba22262 Author: Pedro Amorim Date: Fri Oct 23 15:31:06 2026 +0000 Bug 42621: DBRev 26.06.00.039 Signed-off-by: Pedro Amorim commit 5e8e7fc12ff3805913bcbafd3a43c12d8a54ae32 Author: Matt Blenkinsop Date: Fri Oct 23 14:23:58 2026 +0100 Bug 42621: (QA follow-up) Use the root library group for report limits The saved reports list and direct report access used different rules when a group had sub-groups. The list collected the libraries under the user's immediate parent group. Direct access collected the libraries under the limited library's immediate parent group. With a root group holding Centerville and a sub-group holding Fairfield, a Centerville user saw a Fairfield-limited report but could not run it, and a Fairfield user could run a Centerville-limited report that was not listed. A library group now means the whole tree under the root group that has "Limit report access by group" ticked. This is the rule that local hold groups and local float groups already use (get_hold_libraries and get_float_libraries). library_group_limits returns the root groups and search_with_library_group_limits expands the root with all_libraries, so both sides agree. Libraries outside any such tree are still enforced as a group of one. The Library limits column now shows the root group title. Test plan: 1. Set LimitReportsBy to Library group 2. Create a library group "Reports test", tick "Limit report access by group", add Centerville to it 3. Add a sub-group "Sub" to "Reports test" and add Fairfield to "Sub" 4. Save a report limited to Fairfield and a report limited to Centerville 5. Create a staff user at Centerville and one at Fairfield with only catalogue and execute_reports 6. As the Centerville user: both reports are listed and both run 7. As the Fairfield user: both reports are listed and both run 8. As a user at a library outside the group: neither report is listed and opening either by URL with op=run gives "Access denied" 9. prove t/db_dependent/Koha/Reports.t Co-Authored-By: Claude Fable 5.1 Signed-off-by: Pedro Amorim commit 770b12d31ce8dead6d508d1d4de3dd44c0a53328 Author: Matt Blenkinsop Date: Fri Oct 23 14:23:55 2026 +0100 Bug 42621: (QA follow-up) Add LimitReportsBy to sysprefs.sql and fix the atomic update sysprefs.sql still listed LimitReportsByLibrary, so a fresh install had no LimitReportsBy row. get_saved_reports then compared an undefined preference value and crashed on the saved reports list with "Can't call method unblessed on an undefined value". check_sysprefs.t also failed with "Too many sysprefs in DB: LimitReportsBy". The atomic update also set options and type on the renamed preference. Since bug 41834 these columns must be NULL in the database, the YAML file owns them. The update now only renames the variable and converts the value. The stale preference name is also replaced in Reports/Guided.t. Test plan: 1. grep -n "LimitReportsBy" installer/data/mysql/mandatory/sysprefs.sql shows ('LimitReportsBy','none') 2. In ktd --shell: updatedatabase && restart_all 3. koha-mysql kohadev -e "SELECT variable, value, options, type FROM systempreferences WHERE variable = 'LimitReportsBy'" shows value none and NULL for options and type 4. prove t/db_dependent/check_sysprefs.t 5. Open the saved reports list, it loads without error Co-Authored-By: Claude Fable 5.1 Signed-off-by: Pedro Amorim commit 447b46002aea98030f1ddd5573ea8ae072f3e21f Author: Matt Blenkinsop Date: Fri Oct 9 10:07:57 2026 +0100 Bug 42621: (QA follow-up) Refactor for bug 43591 Assisted-by: Sonnet 5 (Anthropic) Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 5bfec2a55c53a22b296f75028f3ab1c4d71e8103 Author: Matt Blenkinsop Date: Thu Sep 24 11:19:10 2026 +0100 Bug 42621: (QA follow-up) Always render the column to prevent datatables error The library limit column was only rendered if the syspref was switched on but this would cause a databtables column index mismatch and throw an error. This patch always renders the column and handles the column value based on the syspref value rather than just showing/hiding it Assisted-by: Sonnet 5 (Anthropic) Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 7d4df738e24df6cef2e8def124fb3e0e78b83883 Author: Matt Blenkinsop Date: Fri Sep 18 16:56:15 2026 +0100 Bug 42621: (QA follow-up) Add POD to private subs in C4::Reports::Guided The QA script reports missing POD coverage for _get_columns, _build_query and _get_display_value. This is pre-existing but was requested during QA of this bug. Test plan: 1. prove t/db_dependent/Reports/Guided.t 2. Run the QA script, C4/Reports/Guided.pm no longer fails pod_coverage Co-Authored-By: Claude Fable 5.1 Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 7ba5aa2290baa327620d70bbac8719f3627935b9 Author: Matt Blenkinsop Date: Fri Sep 18 16:53:42 2026 +0100 Bug 42621: (QA follow-up) Display and enforce limits to ungrouped libraries When LimitReportsBy is set to library_group and a report is limited to a library that is not in any group with "Limit report access by group" enabled, the limit was enforced in the saved reports list but the "Library limits" column showed "No limitation". Direct access via can_access also ignored the limit entirely, because it only checked qualifying groups. An ungrouped library is now treated as a group of one. Two helpers are added to Koha::Object::Limit::LibraryGroup: - ungrouped_library_limits returns the limited libraries that are not members of any qualifying group - library_group_limit_branchcodes returns every branchcode the limit resolves to (stored branchcodes plus all members of qualifying groups) can_access uses the resolved branchcodes so listing and direct access agree. The saved reports table shows group titles followed by any ungrouped libraries as "Branch name (CODE)". Test plan: 1. Set LimitReportsBy to Library group 2. Create a library group containing Centerville and Fairfield, tick "Limit report access by group" 3. As a superlibrarian at Centerville, create a report limited to Fairview (not in any group) 4. Saved reports list: the report is hidden 5. Set your library to Fairview, reload the saved reports list 6. The report is visible and the Library limits column shows "Fairview (FRV)" instead of "No limitation" 7. Edit the report and add Centerville to the limit. The column shows the group title followed by "Fairview (FRV)" 8. Log in as a non-manager user at Fairfield and open the report from step 3 by URL. Access is denied 9. prove t/db_dependent/Koha/Reports.t Co-Authored-By: Claude Fable 5.1 Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit a078732c70422f061d0cec9d8d2b4d424363b0bc Author: Matt Blenkinsop Date: Wed Jun 10 13:47:26 2026 +0100 Bug 42621: DBIC Signed-off-by: Brendan Lawlor Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit d0d50e14ebf28e949867255ab7e6caeb0a812893 Author: Matt Blenkinsop Date: Wed Jun 10 13:47:16 2026 +0100 Bug 42621: Add unit test for lib group limits Test plan: Prerequisites 1. Three branches: Centerville, Fairfield, Fairview 2. Admin - Library groups: create root group "Test Group", enable Limit report access by group, add Centerville and Fairfield as child libraries (not Fairview) 3. Create an admin user with manage_report_limits permission (or superlibrarian) at branch Centerville 4. Create regular users with reports + execute_reports only (no manage_report_limits), one at each of Centerville, Fairfield, and Fairview 5. Admin - Administration - Columns settings - Reports - Saved reports (table_reports) - enable the Library limits column (it is hidden by default) Baseline - LimitReportsBy = No restriction 6. Set LimitReportsBy = No restriction 7. Admin user - create Report A - no "Library limitation" field visible, save report with any parameters, content is not important 8. Admin user - Reports list - no "Library limits" column visible even if enabled in column settings. Library mode - regression 9. Set LimitReportsBy = Library 10. Admin user - Reports list - "Library limits" column visible (if enabled in column settings) 11. Log in as the Fairview user - Reports list - "Library limits" column not visible as user doesn’t have manage_reports_limit permission 12. Admin user - edit Report A - Library limitation field should be visible - set limit to Centerville - report saves with Centerville limit 13. Fairview user - Reports list - Report A not visible 14. Regular user at Centerville - Reports list - Report A visible 15. Regular user at Centerville - edit Report A - save - limits preserved (fieldset not shown; backend preserves existing limits silently) 16. Admin user - Report A visible with "1 library limitation" tooltip showing Centerville. Delete Report A Library group mode - setup and limits column 17. Set LimitReportsBy = library_group 18. Admin user - Reports list - "Library limits" column still visible 19. Regular user at Centerville - Reports list - "Library limits" column not visible 20. Admin user - create Report B, set limit to Centerville - "Library limitation" fieldset visible, saves with Centerville as the limit 21. Admin user - Reports list - Report B shows "Test Group" in limits column 22. Admin user - create Report C with no limit - Report C shows "No limitation" in limits column Library group mode - access by group membership 23. Fairfield user - Reports list - Report B visible (Fairfield is in the same group as Centerville). Report C also visible (no limitation) 24. Fairview user - Reports list - Report B not visible (Fairview not in group) 25. Fairview user - navigate directly to Report B URL - access denied 26. Fairview user - Reports list - Report C visible (no limitation) Library group mode - ft_reports flag required 27. Admin - Library groups: disable "Limit report access by group" on "Test Group" 28. Regular user at Fairfield - Reports list - Report B no longer visible as it was limited to Centerville 29. Admin user - Report B limits column - shows "No limitation" 30. Re-enable the flag - Fairfield can see Report B again Library group mode - non-admin save behaviour 31. Regular user at Centerville - create new Report D - save - Report D automatically limited to Centerville (backend sets own branch; no fieldset shown). Verify by viewing the saved reports table as the Admin user - should show Test group as the limitation 32. Regular user at Centerville - edit Report B - save - existing limits preserved unchanged Switching modes 33. With Report B limited to Centerville and LimitReportsBy = library_group - Fairfield can access 34. Switch to LimitReportsBy to Library - Fairfield can no longer access Report B (exact branch match only) 35. Switch back to library_group - Fairfield can access Report B again 36. Switch to none - all reports accessible; no limits column or fieldset anywhere Signed-off-by: Brendan Lawlor Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit ed83a6ffc062806224349ee63129150874ae2fc9 Author: Matt Blenkinsop Date: Wed Jun 10 13:43:54 2026 +0100 Bug 42621: Update logic involving the old syspref to reflect the new LimitReportsBy Signed-off-by: Brendan Lawlor Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 9c3c5a0fea123c7898c1cb2640a25586ff0608a8 Author: Matt Blenkinsop Date: Wed Jun 10 13:43:07 2026 +0100 Bug 42621: Update reports search to be able to look up by library group Signed-off-by: Brendan Lawlor Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit a208eacae5a94736ca8bf2502a20d5783f3c31c1 Author: Matt Blenkinsop Date: Wed Jun 10 13:40:03 2026 +0100 Bug 42621: Add library group limit classes Designed to work as an extra layer on top of library_limits by using the same column but expanding the search to also include any branches in a library group Signed-off-by: Brendan Lawlor Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit a8e2ffbffeffa22cd4fce5a8bfb165de797c3008 Author: Matt Blenkinsop Date: Wed Jun 10 13:38:33 2026 +0100 Bug 42621: Handle the new ft_reports column in the UI Signed-off-by: Brendan Lawlor Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit b482621918449c2a1bc088d79c46f7e015eb2e5e Author: Matt Blenkinsop Date: Wed Jun 10 13:37:56 2026 +0100 Bug 42621: Update the LimitReportsByLibrary to LimitReportsBy Signed-off-by: Brendan Lawlor Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 3e4b103656cf49fc974c005a11c80fc34013d262 Author: Matt Blenkinsop Date: Wed Jun 10 13:34:16 2026 +0100 Bug 42621: Add a ft_reports column to library_groups Signed-off-by: Brendan Lawlor Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 9f2a612d56ae131365767f090a7cda12a84ea60e Author: Lucas Gass Date: Thu Oct 22 16:41:42 2026 +0000 Bug 42627: (follow-up) Add unit tests Signed-off-by: Pedro Amorim commit 46623ca11d33a281d0baf1db138a9e92bb37fa6f Author: Lucas Gass Date: Thu Oct 22 16:40:58 2026 +0000 Bug 42627: (follow-up) Move range logic to its own sub Signed-off-by: Pedro Amorim commit afde4c2f1503ed33ec49bd6f8dbd11e3bcaf37f4 Author: Lucas Gass Date: Tue Jul 7 20:54:27 2026 +0000 Bug 42627: Update labels Signed-off-by: Gretchen Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 1281908d0434eff6c51359024853e54c3c294011 Author: Lucas Gass Date: Tue Jul 7 20:52:37 2026 +0000 Bug 42627: Update scripts to account for count Signed-off-by: Gretchen Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit c94fe5e844dc88e606b3a8246bcff9c797cb6197 Author: Lucas Gass Date: Tue Jul 7 20:52:01 2026 +0000 Bug 42627: Update templates to use count instead of to To test: 1. APPLY PATCH, restart_all 2. Go to Cataloging > Label creator > Print barcode range 3. Notice the labels now read "Starting barcode" and "Number of barcodes to print" 4. Find a barcode in you system. In KTD I do something like 'select barcode from items limit 10;' to find some 5. Enter a barcode and choose 9999 as the "Number of barcodes to print" 6. You should see an error message like "Cannot print more than 1000 barcodes at a time." 7. Choose a more reasonable number like 10 and click 'Print range' 8. On the next page choose a template and a layout and click "Export" 9. On the next page you should see something like "Barcodes from 3999900000001 to 3999900000010". Make sure the range looks correct. 10. Now open the PDF and make sure everything looks correct Signed-off-by: Gretchen Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit fa2a4efb957599ad55a227bf261412aa51d61806 Author: Jacob O'Mara Date: Thu Oct 15 15:06:28 2026 +0100 Bug 43525: (QA follow-up) Show a readable enqueue error Signed-off-by: Jacob O'Mara Signed-off-by: Pedro Amorim commit 1e638e51931e2780116d732c7c1650d027102a23 Author: Jacob O'Mara Date: Thu Oct 15 15:06:28 2026 +0100 Bug 43525: (QA follow-up) Show why a patron cannot be deleted Signed-off-by: Jacob O'Mara Signed-off-by: Pedro Amorim commit aa2ecf8c9b64bd254e2a703daed0124e0f4cdf3a Author: Jacob O'Mara Date: Thu Oct 15 15:06:28 2026 +0100 Bug 43525: (QA follow-up) Report patrons that are not found Signed-off-by: Jacob O'Mara Signed-off-by: Pedro Amorim commit 6153ec8de84fb7bd0f0310beb7f4985150fea41e Author: Jacob O'Mara Date: Thu Oct 15 15:06:28 2026 +0100 Bug 43525: (QA follow-up) Wrap patron deletion in a transaction Signed-off-by: Jacob O'Mara Signed-off-by: Pedro Amorim commit db312561dd8a22e53c409f903b4120700e423588 Author: Lucas Gass Date: Mon Sep 14 21:23:46 2026 +0000 Bug 43525: Add unit tests prove -v t/db_dependent/Koha/BackgroundJob/BatchDeletePatron.t Signed-off-by: Michelle Spinney Signed-off-by: Jacob O'Mara Signed-off-by: Pedro Amorim commit f3d1f5e540435a2301180bfcdbd3a4acf4dc2923 Author: Lucas Gass Date: Mon Sep 14 21:16:28 2026 +0000 Bug 43525: Do not enqueue an empty job Noticed while attempting to add tests. Signed-off-by: Michelle Spinney Signed-off-by: Jacob O'Mara Signed-off-by: Pedro Amorim commit 809c162be428b3eb91cc0d162be7b6859ecaa7b7 Author: Lucas Gass Date: Fri Sep 11 19:57:17 2026 +0000 Bug 43525: Change cleanborrowers to accept a background job Signed-off-by: Michelle Spinney Signed-off-by: Jacob O'Mara Signed-off-by: Pedro Amorim commit 0d6fcb46168b77fdf82cf5aa52aa9fbff3876d76 Author: Lucas Gass Date: Fri Sep 11 17:28:05 2026 +0000 Bug 43525: Add a BatchDeletePatron background job and register it To test: 0. APPLY PATCH and restart_all 1. Make sure you have some patron ready for deletion. I also check how many borrowers and deletedborrowers I have at this step: select count(*) from borrowers; select count(*) from deletedborrowers; 2. Go to Tools -> Batch patron deletion and anonymization 3. Enter in some params that will return you borrowers. who have not borrowed since, whose expiration date is before, and/or whose patron category is 4. Check 'Verify you want to delete patrons' and run the job 5. On the next step make note of how many borrowers should be deleted 6. Choose 'Permanently delete these patrons'. 7. A background job should be enqueued, when it is finished check borrowers again ( select count(*) from borrowers; ) 8. Also check deletedborrower ( select count(*) from deletedborrowers; ) 9. The borrower who were deleted should be gone for the borrowers table. Deleteborrowers should not have gained any new rows. 10. Now try all the steps again but at step 6 this time choose 'Move these patrons to the trash' 11. This time those borrowers should end up in the deletedborrowers table Signed-off-by: Michelle Spinney Signed-off-by: Jacob O'Mara Signed-off-by: Pedro Amorim commit cc39040876b64ee1ac6157937a1295a421f4ef0e Author: Paul Derscheid Date: Fri Oct 16 12:22:16 2026 +0200 Bug 41514: (QA follow-up) Honour the trail period when extending a booked checkout Koha::Booking->store now enforces lead and trail periods, but Koha::Item->find_booking only checks the lead period at the global level. Renewing a booked checkout, or overriding its due date at checkout, into the next booking's trail window was allowed, and the booking end_date sync then silently failed on the clash. - find_booking with exclude_booking_id also adds the excluded booking's trail period and reads both rules for its pickup library - plain checkout lookups are unchanged Test plan: 1. prove /kohadevbox/koha/t/db_dependent/Circulation.t 2. prove /kohadevbox/koha/t/db_dependent/Koha/Item.t Assisted-by: Opus 5.5 (Anthropic) Signed-off-by: Paul Derscheid Signed-off-by: Pedro Amorim commit e773c3ec16b71c313515562076653f77d3ca1536 Author: Martin Renvoize Date: Thu Sep 3 21:06:50 2026 +0100 Bug 41514: (QA follow-up) Add explicit use Koha::CirculationRules to Koha::Booking _assign_item_for_booking() calls Koha::CirculationRules->get_effective_rules without the module being directly loaded. It currently works only because use Koha::Items transitively loads Koha::Item, which loads Koha::CirculationRules - a fragile, load-order-dependent dependency. Load it explicitly. Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 215b01c96354ee54217b1609e84628a7398adc0d Author: Martin Renvoize Date: Thu Sep 3 21:06:24 2026 +0100 Bug 41514: (QA follow-up) Use the itemtype_id filter for auto-assignment's lead/trail rule lookup _assign_item_for_booking() always looked up the bookings_lead_period / bookings_trail_period rule using the biblio's default itemtype (biblioitem.itemtype), even when the caller requested an "any item of itemtype X" booking via set_itemtype_filter() (wired up from the REST API's itemtype_id parameter). On a biblio with mixed item-level itemtypes that have different lead/ trail rules, this meant an item could be auto-assigned to a booking that actually violates its own itemtype's configured buffer period, because the exclusion query used the wrong itemtype's rule while the item search correctly used the filter for candidate selection. Use the itemtype filter for the rule lookup when it is set, falling back to the biblio's default itemtype otherwise. Test plan: 1. prove t/db_dependent/Koha/Booking.t Signed-off-by: Martin Renvoize Signed-off-by: Pedro Amorim commit 37fa6f5bcb62a0def429e078ce181d6115891e88 Author: Paul Derscheid Date: Thu Sep 3 16:45:50 2026 +0200 Bug 41514: (QA follow-up) Add Koha::Bookings->filter_by_overlapping After the previous follow-up the lead/trail rule lookup and the expanded overlap query existed three times: in Koha::Item::check_booking, Koha::Biblio::check_booking and Koha::Booking::_assign_item_for_booking. - Add Koha::Bookings->filter_by_overlapping, taking the period and the lead/trail days; callers chain it with filter_by_active - Fetch both rules with a single get_effective_rules call at each site - Use the new method at the three call sites Test plan: 1. prove t/db_dependent/Koha/Bookings.t t/db_dependent/Koha/Booking.t t/db_dependent/Koha/Item.t t/db_dependent/Koha/Biblio.t t/db_dependent/api/v1/bookings.t Assisted-by: Fable 5.1 (Anthropic) Signed-off-by: Paul Derscheid Signed-off-by: Pedro Amorim commit 470db1f52da35b58402a7906061f762a8425489d Author: Paul Derscheid Date: Thu Sep 3 16:17:21 2026 +0200 Bug 41514: (QA follow-up) Enforce lead/trail periods in item auto-assignment The "any item" path in Koha::Booking::store() excluded only items whose bookings overlapped the core date range, so a biblio-level booking could be stored on an item whose trail period it violates, while the same booking with an explicit item_id was rejected. _select_optimal_item() made this worse by preferring the just-vacated item. - Fetch bookings_trail_period alongside bookings_lead_period in _assign_item_for_booking() - Expand the existing bookings query by lead + trail on both sides, matching the check_booking() overlap condition This makes three copies of the rule lookup and expanded overlap query; the next follow-up consolidates them. Test plan: 1. Set bookings_lead_period=3 and bookings_trail_period=2 for a branch and itemtype 2. Create a biblio with two bookable items X and Y of that itemtype; book X for today+5..today+10 and Y for today+40..today+45 3. Via the REST API, POST a booking for that biblio without item_id for today+12..today+14 => Without this patch it is stored and assigned to X, inside X's trail period => With this patch it is assigned to Y; a second identical request is rejected with a clash 4. prove t/db_dependent/Koha/Booking.t Assisted-by: Fable 5.1 (Anthropic) Signed-off-by: Paul Derscheid Signed-off-by: Pedro Amorim commit d7ec0ee30f527b6c29cc86c375f8a24302af5486 Author: Martin Renvoize Date: Wed Mar 4 17:21:05 2026 +0000 Bug 41514: Enforce lead/trail periods server-side in booking API Previously, lead and trail period validation for bookings was only enforced in the UI (place_booking.js), allowing third-party API consumers to create bookings that violated the configured buffer zones. This patch adds server-side enforcement in the two check_booking() methods and the Booking->store() call: - Koha::Item::check_booking(): accepts an optional branchcode param, fetches bookings_lead_period and bookings_trail_period circ rules for the item's effective itemtype, expands the overlap query so that effective periods (core ± lead/trail) are checked rather than just core date ranges. Also expands the checkout-due-date check so that items must be returned at least lead_days before the booking start. - Koha::Biblio::check_booking(): same expansion using the global (itemtype-agnostic) rule as an approximation for biblios that have items of mixed types. The item-level check provides the definitive per-item validation. - Koha::Booking::store(): passes pickup_library_id as branchcode to both check_booking() calls so that branch-specific rules are used. Tests added to t/db_dependent/Koha/Booking.t covering: - booking ending in existing booking's lead period → clash - booking ending before effective period → OK - booking starting in existing booking's trail period → clash - new booking's lead period overlapping existing trail period → clash - booking starting after full effective period ends → OK - checkout due within lead period → clash - checkout due before lead period → OK Signed-off-by: David Nind Signed-off-by: Paul Derscheid Signed-off-by: Pedro Amorim commit 70e78014a00f4dc536a68326c84ba6b7f08d0626 Author: Pedro Amorim Date: Thu Oct 22 15:21:17 2026 +0000 Bug 15248: DBRev 26.06.00.038 Signed-off-by: Pedro Amorim commit e7f8fc45be4ae22b8bd7ad8626da9a225ce624e5 Author: Thibaud Guillot Date: Thu Aug 20 16:14:35 2026 +0200 Bug 15248: (QA follow-up) Fix duplicate record display in acquisitions and cataloguing Signed-off-by: Pedro Amorim commit 3c9f1e5788ec8ab80b91558a55dc872dc4aa00c3 Author: Thibaud Guillot Date: Wed Oct 21 14:44:41 2026 +0200 Bug 15248: (QA follow-up) Fix duplicate check when editing records - When editing a record, only check for duplicates if a matching rule is configured for the framework - 'Forbid creation of duplicate' no longer prevents saving an existing record: a warning is displayed with an option to save - Request one more match when excluding the edited record, so it does not hide an actual duplicate - Fix the description field when editing a non-default framework Test plan: 1. Apply the patches, updatedatabase and restart_all 2. Follow the steps of the 4 findings in the last QA comment => Finding 1: the record is saved without any duplicate warning => Finding 2: the BKS framework description is editable and saving works => Finding 3: editing biblio 155 warns about biblio 252 => Finding 4: editing biblio 252 shows a warning with 'Yes, save record', and the record can be saved 3. With 'Forbid creation of duplicate' enabled, create a new record with ISBN 0964479621 in the BKS framework => Creation is still forbidden 4. prove t/db_dependent/Search.t Co-Authored-By: Claude Opus 5.5 Signed-off-by: Pedro Amorim commit 3b75bad22aae3fd9d4c4690b1202a57a6ac5c3db Author: Nick Clemens Date: Tue Sep 22 18:51:07 2026 +0000 Bug 15248: (QA folllow-up) Only allow biblio matchign rules when editing frameworks This patch filters the list of potential matchers so only biblio matchers are offered. To test: 1 - Go to 'Administration' > 'Record matching rules' (http://localhost:8081/cgi-bin/koha/admin/matching-rules.pl) 2 - Click 'New rule', fill in a 'Rule code' and 'Description', set 'Record type' to 'Authority record' and 'Threshold' to 100, under 'Match points' set 'Search index' to Local-Number, 'Score' to 100, 'Tag' to 001, then save 3 - Go to 'Administration' > 'MARC frameworks' (http://localhost:8081/cgi-bin/koha/admin/biblio_framework.pl), click 'Edit' on 'Default framework' 4 - In the 'Matching rules used to find duplicates' dropdown, select the authority rule from step 3, then 'Submit' 5 - KO 6 - Apply patches, restart all 7 - Edit default framework again 8 - Confirm you cannot see the authority matchign rule 9 - Sign off! Signed-off-by: Nick Clemens Signed-off-by: Pedro Amorim commit b18d4c526703dcb88fee966c05c2d383d2980778 Author: Nick Clemens Date: Tue Sep 22 18:44:41 2026 +0000 Bug 15248: (QA follow-up) Remove unused variables Signed-off-by: Nick Clemens Signed-off-by: Pedro Amorim commit a893497526ca5ecf534ee5b43516162fe784ebbf Author: Thibaud Guillot Date: Thu Aug 20 16:20:52 2026 +0200 Bug 15248: (QA follow-up) Fix tidy warning on addbiblio.tt Signed-off-by: Pedro Amorim commit 6c5d437585e2468059a5f2d0f571936376bbd721 Author: Thibaud Guillot Date: Wed Jun 10 09:02:17 2026 +0200 Bug 15248: (follow-up) Check for duplicates when editing a bibliographic record Signed-off-by: Pedro Amorim commit 0dcd7a900257f4a804ae8af3de15a3cfa2337d37 Author: Andrew Fuerste-Henry Date: Fri May 1 18:15:23 2026 +0000 Bug 15248: (QA follow-up) Clear merge errors and tidy Signed-off-by: Pedro Amorim commit 9ee03277e6fd91fec1835899317bf5b2be0a599c Author: Nick Clemens Date: Wed Apr 22 11:20:59 2026 +0000 Bug 15248: (QA follow-up) Add POD Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 5d3ff8146103d68de140dcb5c3ac9e127a9c0601 Author: Julian Maurice Date: Fri Mar 27 15:13:23 2026 +0000 Bug 15248: Set forbid_duplicate_creation as boolean in schema Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit 8f97bcb48fd2202e340d0a2f27bfdf84a85eace8 Author: Julian Maurice Date: Fri Mar 27 15:10:44 2026 +0000 Bug 15248: Update DBIC schema Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit fed66ffc8c3b7c2506e6dc3fbb462ac6f2bfc48a Author: Julian Maurice Date: Wed Nov 13 16:55:25 2024 +0100 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 Signed-off-by: Jeanne Maurielle Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit dc8b6dfe5a6125b4ab614a57fbd6cebd72a34701 Author: Shi Yao Wang Date: Fri Oct 9 09:37:33 2026 -0400 Bug 23998: fix 500 errors and apply branch and syspref permissions Signed-off-by: Pedro Amorim commit a893b46e93b2bb20a586390a1d2c7d5ef7c90440 Author: Andrew Fuerste-Henry Date: Mon Oct 5 13:09:42 2026 +0000 Bug 23998: (QA follow-up) Tidy test file Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim commit f8268e82e4d4d7951095c7d51ab273c0caaf9ca2 Author: Shi Yao Wang Date: Fri Oct 2 17:10:43 2026 -0400 Bug 23998: REST API for messages - Remove message_date from put/patch Signed-off-by: David Nind Signed-off-by: Andrew Fuerste Henry Signed-off-by: Pedro Amorim