https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Sally Healey <sally.healey@cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sally.healey@cheshireshared | |services.gov.uk -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Fiona Borthwick <fiona.borthwick@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fiona.borthwick@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Rob Corp <robcorp169@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robcorp169@gmail.com --- Comment #4 from Rob Corp <robcorp169@gmail.com> --- We'd find this useful too -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=19406 Version|unspecified |master --- Comment #6 from Owen Leonard <oleonard@myacpl.org> --- Bug 19406 would simplify this feature a lot. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #8 from Sebastian Hierl <s.hierl@aarome.org> --- (In reply to Sebastian Hierl from comment #7)

We would welcome this feature as well and would be able to contribute to a development.

Actually, would anyone be interested in co-sponsoring? It seems that this would be a fairly easy (and affordable) thing to implement. Perhaps just two or three libraries coming together could make it happen. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Björn Nylén <bjorn.nylen@ub.lu.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjorn.nylen@ub.lu.se -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #11 from Christopher Brannon <cbrannon@cdalibrary.org> --- (In reply to Benjamin Daeuber from comment #10)

I think we'd be willing to fund some of this, but I'm curious what libraries want it to look like. There are a lot of things that happen on check-in (holds, transfers, notification of statuses). Do we want a table to appear (similar to the batch item modification tool) or do we want all those items to be checked in without user interaction and the various messages can be dealt with in other ways? For example, holds would later show up in the holds queue.

I think options like forgiving fines, check-in date, and trigger holds would all be good options. It should present a table of results. If there is a fine, it should show if it was forgiven. If there is a hold, there should be a button to confirm, confirm and print, or cancel (maybe), and when clicked, it would do it, but the buttons would disappear, but the table results remain intact. If nothing, it will just show it was checked in and the date it was checked in for. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Holly <hc@interleaf.ie> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hc@interleaf.ie -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Barbara Johnson <barbara.johnson@bedfordtx.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |barbara.johnson@bedfordtx.g | |ov -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #13 from Daniel Gaghan <daniel.gaghan@pueblolibrary.org> --- (In reply to Benjamin Daeuber from comment #12)

(In reply to Christopher Brannon from comment #11)

...

I think options like forgiving fines, check-in date, and trigger holds would all be good options.

It should present a table of results. If there is a fine, it should show if it was forgiven. If there is a hold, there should be a button to confirm, confirm and print, or cancel (maybe), and when clicked, it would do it, but the buttons would disappear, but the table results remain intact. If nothing, it will just show it was checked in and the date it was checked in for.

I like these ideas too, especially making trigger holds optional so this can be applied in a variety of situations. Trigger transfers would also need to be considered if libraries printed transfer slips or simply wanted to handle transfers some other way.

Another option I'd like to throw out is to integrate batch check-in with batch item modification. When we process new items or remove them from display it would be easier if they could be checked in all at once.

I agree with Benjamin Daeuber, item modification would be a great place to put the bulk check-in feature. Covid-19 closures has also made this feature even more useful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us --- Comment #15 from Rebecca Coert <rcoert@arlingtonva.us> --- I'd love to see Batch Check In made available with yes/no options on charging/forgiving fines, triggering holds, and setting the check-in date to something other than today. I'd like to see a system setting similar to Batch Checkout where you can dis/allow the function AND limit it to certain patron categories. The criteria(s) to select yes/no needs to be provided at the time of the batch process (e.g.: similar to Batch Patron Deletion) to allow multiple users the ability to customize the process to their needs. Someone using a barcode scanner in a large library may not want to activate holds because they're not near the items (letting the Holds Queue catch them). Checking in items from COVID Storage may want to trap holds but not charge fines. I think that the having more customization available, makes it more usable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Michal Denar <black23@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |black23@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #18 from Michal Denar <black23@gmail.com> --- Hi, if we process batch of documents we still need to process holds, items marked as lost, tranfers etc. Let's talk how solve these situations in UI. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #20 from Barbara Johnson <barbara.johnson@bedfordtx.gov> --- We would love to have a batch checkin feature and I agree with all of Christopher's comments on how this might work. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #22 from Christopher Brannon <cbrannon@cdalibrary.org> --- (In reply to Benjamin Daeuber from comment #21)

I wonder if this isn't best broken off into multiple tickets? There are three places, all with different considerations:

1. standard check-in module

2. check-in on patron account

3. batch item modification

I don't know how much of this functionality would overlap in Koha's innards, but they all strike me as different workflows.

I think the primary focus of this bug is the batch item modification. If we can incorporate this feature in other areas down the road, then most of the work will primarily be done. But I think the initial thought on this bug was for the batch tools. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Anna <urstanlib@urs.edu.ph> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |urstanlib@urs.edu.ph --- Comment #23 from Anna <urstanlib@urs.edu.ph> --- (In reply to Björn Nylén from comment #17)

I was envisioning a checkin process that would support a batch of book placed on an rfid pad. The checkins would be processed asynchonously via ajax calls. That way you could process books without waiting for pageloads etc. We're handling quite a lot of stack requests that need a checkin before being svailable for patrons. Being able to process them by just passing them over the rfid pad without more interaction would be a time saver.

I agree on this one. Batch check-in of books on RFID pad would save time. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 mathieu saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila@collect | |o.ca -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Jessie Zairo <jzairo@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jzairo@bywatersolutions.com | |, nick@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 pierre.genty@biblibre.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pierre.genty@biblibre.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #27 from Mubassir Ahsan <mahsandu@gmail.com> --- Hi, We are looking for this for localuse records. Everyday users left used books on the table, we like to add them to localuse check in. We are using blutooth handheld scanner to capture barcodes. but it is difficult to put all the barcode one by one. So batch check in is very much needed. Thanks. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 koha-US bug tracker <bugzilla@koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@koha-us.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Madge Boldt <mboldt@massasoit.mass.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mboldt@massasoit.mass.edu --- Comment #29 from Madge Boldt <mboldt@massasoit.mass.edu> --- I used the Inventory module to handle batch check ins for items that were still checked out and due prior to 2022. We wanted to remove these items, and batch delete did not allow it since they were still checked out. It's a decent workaround. Just be sure to only check in your own items, and create a report for collection development prior to removal from Koha. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=11858 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #32 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Thibault Keromnès from comment #31)

Is it a duplicate of BZ 32019 ?

No, but they are definitely related. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Catrina Berka <catrina@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |catrina@bywatersolutions.co | |m --- Comment #34 from Catrina Berka <catrina@bywatersolutions.com> --- (In reply to Madge Boldt from comment #33)

The ability to do a batch check in was resolved in Koha 23.05. There is a new Check In option at the bottom of Batch Item Modifications. Bywater highlights the change in their Monday Morning Minute. https://bywatersolutions.com/education/monday-minutes-batch-item-improvement

That feature is pretty great, but it doesn't address the need for this functionality for libraries using RFID pads. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Matthew Ciuccio <mciuccio@newcitylibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mciuccio@newcitylibrary.org --- Comment #36 from Matthew Ciuccio <mciuccio@newcitylibrary.org> --- Batch checkin would very very nice indeed. Fingers crossed it becomes a reality. Thank you. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #37 from Koha collecto <koha@collecto.ca> --- Hi I think this would be an excellent fuction to add to Koha. Thanks. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Ray Delahunty <r.delahunty@arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty@arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Koha collecto <koha@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|marjorie.barry-vila@collect | |o.ca, | |noemie.labine@collecto.ca | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Tom Rice <tom.rice@cityofcarrollton.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tom.rice@cityofcarrollton.c | |om --- Comment #40 from Tom Rice <tom.rice@cityofcarrollton.com> --- Batch check in would be a great time-saver. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #42 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 186374 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186374&action=edit Bug 19814: Add batch return functionality for RFID workflows This proof-of-concept adds batch return capability to the circulation returns page, designed primarily for RFID pad workflows while maintaining backward compatibility for single scan returns. Key Features: - Automatic RFID batch detection and processing with debouncing - Manual batch mode toggle in checkin settings - Single textarea element that adapts from single-line to multi-line - Batch results display with per-item status and messages Technical Implementation: - Backend auto-detects batch mode via newline presence in barcode input - Debouncing (500ms) prevents premature form submission during scanning for multi-line input - Textarea styling dynamically switches between single-line and multi-line modes - Batch processing reuses existing AddReturn() logic for consistency - All existing circulation rules, messages, and workflows preserved RFID Workflow: 1. RFID pad scans multiple items → deposits newline-delimited barcodes 2. Interface auto-expands to show all scanned items 3. Automatic submission after 0.5s delay 4. Batch results display with status for each item Manual Workflow: 1. Enable "batch mode" in circulation settings 2. Input field expands to textarea for multiple barcodes 3. Submit to see comprehensive batch results This is a proof-of-concept seeking user feedback before full development and refinement. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #44 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- # Batch Returns Feature - Test Plan for Librarians ## Overview This proof-of-concept adds batch return functionality to Koha's circulation returns page, specifically designed for RFID workflows while maintaining full backward compatibility with manual barcode entry. ## New Features 1. **Automatic RFID Batch Processing**: Scan multiple items with RFID pad - system automatically detects and processes all returns 2. **Manual Batch Mode**: Toggle in settings to enable textarea for typing/pasting multiple barcodes 3. **Comprehensive Results Display**: View status, messages, and details for each returned item 4. **Seamless Integration**: No changes to existing single-item workflow ## Test Scenarios ### Test 1: Traditional Single Item Returns (Should work exactly as before) **Purpose**: Verify existing workflow is unchanged **Steps**: 1. Go to Circulation → Check in 2. Enter a single barcode in the input field 3. Press Enter or click "Check in" 4. Verify item processes normally with all existing messages/alerts **Expected Result**: ✅ Identical behavior to current system --- ### Test 2: Manual Batch Returns **Purpose**: Test manual multi-barcode entry **Steps**: 1. Go to Circulation → Check in 2. Click the settings icon (⚙️) next to input field 3. Check "Enable batch mode for multiple returns" 4. Notice input field expands to textarea 5. Enter multiple barcodes, one per line: ``` 39999000001310 39999000001328 39999000001336 ``` 6. Click "Check in" **Expected Result**: - ✅ Batch results table appears showing each barcode - ✅ Success/failure status for each item - ✅ Individual messages (holds, transfers, etc.) per item - ✅ Regular checked-in items list also populated --- ### Test 3: RFID Batch Scanning (Key Feature) **Purpose**: Test automatic RFID workflow **Prerequisites**: RFID pad configured to output newline-delimited barcodes **Steps**: 1. Go to Circulation → Check in 2. Leave input field in default single-line mode 3. Place multiple items on RFID pad and scan 4. Observe interface automatically expands and shows all scanned barcodes 5. Wait approximately 0.5 seconds after scanning completes 6. System should automatically submit and process all items **Expected Result**: - ✅ Interface automatically switches to batch mode when RFID data arrives - ✅ All scanned barcodes visible in expanded textarea - ✅ Automatic submission after brief delay - ✅ Batch results showing all processed items --- ### Test 4: Mixed Success/Failure Results **Purpose**: Verify error handling in batch mode **Steps**: 1. Enable batch mode (manually or via RFID) 2. Enter mix of valid and invalid barcodes: ``` ValidBarcode123 InvalidBarcode999 AnotherValidOne456 ``` 3. Submit batch **Expected Result**: - ✅ Valid items show "Returned" status with green indicators - ✅ Invalid barcodes show "Invalid barcode" with red indicators - ✅ Appropriate error messages for each failed item - ✅ Successful returns still process normally --- ### Test 5: Special Circulation Scenarios **Purpose**: Test batch handling of holds, transfers, recalls **Steps**: 1. Return items that have various conditions: - Item with hold for pickup at current location - Item needing transfer to another branch - Overdue item - Item with recall 2. Use batch mode to return multiple items with different statuses **Expected Result**: - ✅ Hold notifications appear in batch results - ✅ Transfer messages displayed appropriately - ✅ All circulation messages preserved per item - ✅ Same behavior as single-item returns --- ### Test 6: Settings Integration **Purpose**: Verify batch mode integrates with existing return settings **Steps**: 1. Enable various return settings (Book drop mode, Forgive fines, etc.) 2. Test both single and batch returns with these settings active 3. Toggle batch mode on/off while other settings enabled **Expected Result**: - ✅ All existing return settings work with batch mode - ✅ Settings apply consistently to batch-processed items - ✅ No conflicts between batch mode and other options --- ## User Experience Questions for Feedback ### RFID Workflow 1. Does the automatic detection and expansion feel natural during RFID scanning? 2. Is the 0.5-second delay appropriate, or would you prefer longer/shorter? 3. Are all scanned barcodes clearly visible before automatic submission? ### Manual Batch Mode 1. Is the settings location for "Enable batch mode" intuitive? 2. Does the textarea expansion/collapse work smoothly? 3. Is the batch results table clear and informative? ### Results Display 1. Are success/failure indicators clear enough? 2. Do you get sufficient detail about each returned item? 3. Are error messages helpful for problem resolution? ### Overall Workflow 1. Does this enhance or complicate your returns process? 2. Would you use RFID batch returns in daily operations? 3. Any missing information or functionality? ## Known Limitations (Proof of Concept) - Bundle items and multi-part confirmations not yet tested in batch mode - Performance with very large batches (50+ items) not yet optimized - Some complex circulation scenarios may need additional testing ## Feedback Needed Please test these scenarios and provide feedback on: - Usability and workflow integration - RFID compatibility with your hardware - Performance with typical batch sizes - Any bugs or unexpected behavior - Suggestions for improvements --- _This is a proof-of-concept implementation seeking librarian feedback before full development._ -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Anni Mäki-Mantila <anni.maki-mantila@turku.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anni.maki-mantila@turku.fi -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |BLOCKED --- Comment #47 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Surely I support this nice initiative! Like it too. I will be working on this a bit more this week. Changing status to reflect that. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #48 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 189487 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189487&action=edit Bug 41001: (QA follow-up): Add 'Confirmation messages with inputs' specific tests cypress run --spec t/cypress/integration/ERM/Dialog_spec.ts Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #50 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 189489 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189489&action=edit Bug 19814: Add preference BatchCheckinDefaults Still WIP. TODO Database revision for pref and authorised values. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #52 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 189490 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189490&action=edit Bug 19814: More template changes Add more AddReturn codes to result loop (like ResFound, BadBarcode etc). Add a class to NotIssued to optionally hide. Open circ settings, enable batch mode when pref enabled. Add additional batch mode settings. Toggle display of additional batch mode settings. Load/save batch mode settings from localStorage. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #54 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- For testing you currently need: insert into authorised_value_categories (category_name,is_system) values ( 'BATCH_CHECKIN_DEFAULTS', 1 ); insert into authorised_values (category, authorised_value, lib, lib_opac, is_system) values ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_ENABLED', 'Enable batch mode', 'Enable batch mode', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_KEEP_SELECTION', 'Keep selection', 'Keep selection', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_IGNORE_NOTISSUED', 'Ignore NOTISSUED message', 'Ignore NOTISSUED message', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_CONFIRM_TRANSFER', 'Confirm transfer', 'Confirm transfer', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_CONFIRM_HOLD', 'Confirm hold', 'Confirm hold', 1 ); -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #56 from Benjamin Daeuber <bdaeuber@cityoffargo.com> --- (In reply to Marcel de Rooy from comment #54)

For testing you currently need:

insert into authorised_value_categories (category_name,is_system) values ( 'BATCH_CHECKIN_DEFAULTS', 1 );

insert into authorised_values (category, authorised_value, lib, lib_opac, is_system) values ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_ENABLED', 'Enable batch mode', 'Enable batch mode', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_KEEP_SELECTION', 'Keep selection', 'Keep selection', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_IGNORE_NOTISSUED', 'Ignore NOTISSUED message', 'Ignore NOTISSUED message', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_CONFIRM_TRANSFER', 'Confirm transfer', 'Confirm transfer', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_CONFIRM_HOLD', 'Confirm hold', 'Confirm hold', 1 );

From this I would gather libraries could toggle on or off trapping holds, receiving messages and confirming transfers? Leaving the option to use the holds queue or items it transfer tools to find those items (same as a library would if using SIP check-in or batch item modification)?

What about making these configurable by the user at the point of check-in as well? I can see a staff person wanting to configure this behavior based on current work levels. For example, we've bunch of items to deal with after a closed day and we need to get them all checked in to free up space and we'll go around later and pick them. On a more normal day we might want a different behavior. Similarly if we're handling items coming in on a shuttle vs. regular checkins. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #58 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Benjamin Daeuber from comment #56)

(In reply to Marcel de Rooy from comment #54)

...

For testing you currently need:

insert into authorised_value_categories (category_name,is_system) values ( 'BATCH_CHECKIN_DEFAULTS', 1 );

insert into authorised_values (category, authorised_value, lib, lib_opac, is_system) values ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_ENABLED', 'Enable batch mode', 'Enable batch mode', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_KEEP_SELECTION', 'Keep selection', 'Keep selection', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_IGNORE_NOTISSUED', 'Ignore NOTISSUED message', 'Ignore NOTISSUED message', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_CONFIRM_TRANSFER', 'Confirm transfer', 'Confirm transfer', 1 ), ( 'BATCH_CHECKIN_DEFAULTS', 'BATCH_CHECKIN_CONFIRM_HOLD', 'Confirm hold', 'Confirm hold', 1 );

From this I would gather libraries could toggle on or off trapping holds, receiving messages and confirming transfers? Leaving the option to use the holds queue or items it transfer tools to find those items (same as a library would if using SIP check-in or batch item modification)?

What about making these configurable by the user at the point of check-in as well? I can see a staff person wanting to configure this behavior based on current work levels. For example, we've bunch of items to deal with after a closed day and we need to get them all checked in to free up space and we'll go around later and pick them. On a more normal day we might want a different behavior. Similarly if we're handling items coming in on a shuttle vs. regular checkins.

Still thinking about this. But please note that we want to add batch checkin here while touching core circulation such as the famous AddReturn function here as little as possible.. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #189488|0 |1 is obsolete| | --- Comment #60 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 189586 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189586&action=edit Bug 19814: Add batch return functionality for RFID workflows This proof-of-concept adds batch return capability to the circulation returns page, designed primarily for RFID pad workflows while maintaining backward compatibility for single scan returns. Key Features: - Automatic RFID batch detection and processing with debouncing - Manual batch mode toggle in checkin settings - Single textarea element that adapts from single-line to multi-line - Batch results display with per-item status and messages Technical Implementation: - Backend auto-detects batch mode via newline presence in barcode input - Debouncing (500ms) prevents premature form submission during scanning for multi-line input - Textarea styling dynamically switches between single-line and multi-line modes - Batch processing reuses existing AddReturn() logic for consistency - All existing circulation rules, messages, and workflows preserved RFID Workflow: 1. RFID pad scans multiple items → deposits newline-delimited barcodes 2. Interface auto-expands to show all scanned items 3. Automatic submission after 0.5s delay 4. Batch results display with status for each item Manual Workflow: 1. Enable "batch mode" in circulation settings 2. Input field expands to textarea for multiple barcodes 3. Submit to see comprehensive batch results This is a proof-of-concept seeking user feedback before full development and refinement. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #189490|0 |1 is obsolete| | --- Comment #62 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 189588 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189588&action=edit Bug 19814: More template changes Add more AddReturn codes to result loop (like ResFound, BadBarcode etc). Add a class to NotIssued to optionally hide. Open circ settings, enable batch mode when pref enabled. Add additional batch mode settings. Toggle display of additional batch mode settings. Load/save batch mode settings from localStorage. Make confirm hold/transfer settings respect system preferences HoldsAutoFill/AutomaticItemReturn. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #189568|0 |1 is obsolete| | --- Comment #64 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 189590 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189590&action=edit Bug 19814: Merge code for cud-affect_reserve and HoldsAutoFill This merges two nearly identical wrappers around a call of ModReserveAffect into a new subroutine. We could reuse this subroutine in the batch checkin loop. Test plan: Verify that everything still works as expected by: - Disable HoldsAutoFill if needed. - Pick item with a hold (for current library). - Check item in via staff main page, checkin tab. - Confirm hold. - Repeat but confirm hold for another pickup library. - Enable HoldsAutoFill. - Repeat both previous checkins. There is no popup now. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #66 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 189592 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189592&action=edit Bug 19814: Polishing js in template When going back to single mode, we should respond to Enter again. Remove enabling the batch mode from the input event. Obsoleting variable isReceivingRFIDInput. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #68 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- For getting this further, I appreciate feedback. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #70 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Jacob and I are back on the case here now, thanks for the sponsorship to help get this prioritised Marcel. I'm just digesting all the feedback again and catching myself back up on the current state. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Elizabeth Hoffman <ehoffman@plumcreeklibrary.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoffman@plumcreeklibrary.n | |et -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #189586|0 |1 is obsolete| | Attachment #189587|0 |1 is obsolete| | Attachment #189588|0 |1 is obsolete| | Attachment #189589|0 |1 is obsolete| | Attachment #189590|0 |1 is obsolete| | Attachment #189591|0 |1 is obsolete| | Attachment #189592|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #72 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203227 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203227&action=edit Bug 19814: Add preference BatchCheckinDefaults Still WIP. TODO Database revision for pref and authorised values. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #74 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203229 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203229&action=edit Bug 19814: Allow to configure debounce interval Test plan: Change value in koha-conf.xml. Say 5000. Restart all. Verify that batch mode now respects this new delay value. (Type a bad barcode, press Enter, and count seconds.) Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #76 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203231 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203231&action=edit Bug 19814: Confirm hold or transfer Test plan: -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #78 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203233 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203233&action=edit Bug 19814: (follow-up) Fix batch mode settings UI bugs Hide sub-settings on load, fix copy-pasted label for=, move inline styles to SCSS, make debounceInterval a number. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #80 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203235 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203235&action=edit Bug 19814: (follow-up) Rename rfid_debounce_interval config Setting is batch-checkin-wide; rename to batch_checkin_debounce_interval and align defaults (500ms). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #82 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203237 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203237&action=edit Bug 19814: (follow-up) Share checkin messages include and sub Extract batch per-item logic into process_batch_checkin_item; share AddReturn message rendering via checkin-messages.inc. Single-item path uses approach (b): filter messages to the complement of errmsgloop codes to avoid duplicate alerts. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #84 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203239 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203239&action=edit Bug 19814: (follow-up) Render NotIssued as info in batch Add status key on batch results; hide whole row when pref BATCH_CHECKIN_IGNORE_NOTISSUED is set, instead of message only. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #86 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203241 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203241&action=edit Bug 19814: (follow-up) Add BatchCheckinDefaults pref and AVs Insert BatchCheckinDefaults syspref and BATCH_CHECKIN_DEFAULTS authorised value category with five entries. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #88 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203243 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203243&action=edit Bug 19814: (follow-up) Move batch confirm to a modal Replaces the per-row Action column with an auto-opening modal that offers Confirm, Skip, and Cancel for parts/bundle confirmation. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #90 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203245 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203245&action=edit Bug 19814: (follow-up) Namespace batch modal click handlers The initial wire-up for the batch confirm modal used plain .on('click', ...) on three buttons. In the current flow the modal is only ever server-rendered once per page load, so this is safe today, but binding without a matching .off() means that if the modal markup ever gets re-rendered mid-session (for example via a future AJAX flow) the handlers would stack, producing duplicate hidden inputs and double form submissions. Use a .batchConfirm event namespace and .off()/.on() so the wire-up is idempotent regardless of how often it runs. Test plan: 1. Scan a batch list containing an item that triggers the confirm modal; click "Confirm all parts present" / "Skip this item" / "Cancel batch" in turn and confirm each still behaves as before. 2. Inspect the form on submit and confirm only a single multiple_confirm (or confirm_items_bundle_return / batch_skip_confirm) hidden input is appended. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #92 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203247 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203247&action=edit Bug 19814: (follow-up) Warn on batch state JSON failures The three eval-guarded encode_json / decode_json calls that round-trip batch checkin results through the hidden batch_completed_results form field previously swallowed any exception silently. A corrupt or oversized payload would just produce an empty completed-results list on the next request with no trace in the logs. Log each failure through Koha::Logger so operators can see why batch state was lost. Test plan: 1. Open a batch checkin that triggers the confirm modal (so a batch_completed_results value is actually round-tripped). 2. Edit the browser DevTools network tab (or use a browser form inspector) to replace the batch_completed_results hidden value with an obviously-invalid string, e.g. "not-json", and submit. 3. Confirm the request still renders (no 500), and that plack-intranet-error.log contains the Koha::Logger warning "Failed to decode batch_completed_results JSON: ...". 4. Normal batch submissions should log nothing new. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #94 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203249 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203249&action=edit Bug 19814: (follow-up) Repair WrongTransfer rows during batch checkin When AddReturn flags a WrongTransfer (item arrived at an unexpected branch en route to its real destination) the single-item post-processing block replaces the existing transfer with a new one tagged replace => 'WrongTransfer' so the audit trail records the correction. The batch loop ran AddReturn but never performed this repair, so batch-scanned items that hit a WrongTransfer left the DB state stale. Extract the repair into repair_wrong_transfer() and call it from both the single-item block and process_batch_checkin_item. Test plan: 1. Set up a transfer where item X should go from library A -> B. 2. Scan item X at library C (single-item) -> new transfer row replaces the old one with reason WrongTransfer. 3. Scan item X at library C in batch mode -> same new transfer row is created (verify in branchtransfers table). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #96 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203251 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203251&action=edit Bug 19814: (follow-up) Seed lib_opac for batch checkin AVs The INSERT for BATCH_CHECKIN_DEFAULTS authorised values only set lib, leaving lib_opac NULL. Staff-only AVs still render fine, but aligning lib_opac matches the pattern used by other system AVs and keeps the admin AV editor from showing an empty OPAC label column when the category is inspected. The category itself is already flagged is_system=1 so it cannot be deleted from the UI. Test plan: 1) Drop the BATCH_CHECKIN_DEFAULTS rows, rerun the atomicupdate, and verify the lib_opac column is populated. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #98 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203253 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203253&action=edit Bug 19814: (follow-up) Surface more checkin messages in batch rows The shared checkin-messages.inc was used in both the single-item path (alongside the rich errmsgloop rendering) and the new batch results rows. In single-item mode the librarian still saw the errmsgloop content, so the include could get away with ignoring several message codes. Batch rows render the include alone, which left lost-item fee refunds, processing fee refunds, return claim resolution, and bundle warnings invisible to the librarian. Add alert-style renderings for: - LostItemFeeRefunded / LostItemFeeCharged / LostItemFeeRestored - LostItemPaymentNotRefunded - ProcessingFeeRefunded - ClaimAutoResolved - ReturnClaims (summary only; full modal still fires in single-item) - InBundle (summary only; full bundle dialog still fires in single-item) The ignore regex is trimmed to genuinely internal codes (Transfer(To|Trigger), WrongTransferItem, WasReturned). Test plan: 1) Enable batch checkin. Check in a lost item that triggers LostItemFeeRefunded and confirm the refund notice appears. 2) Check in an item flagged as a return claim and confirm the "claimed as returned" notice appears in the batch row. 3) Check in an item that belongs to a bundle and confirm the bundle notice appears in the batch row. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #100 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203255 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203255&action=edit Bug 19814: (follow-up) Surface silent batch failures to the librarian - Flag unresolved hold confirmation in the batch row (HoldConfirmFailed) when Koha::Holds->find() returns undef for a ResFound hold -- the item was still returned but the librarian had no way to know the hold wasn't captured. - Surface batch state JSON encode/decode failures with a template flag and banner instead of only logging server-side -- previously completed results and preserved toggles (exempt fines, dropbox, backdate) could be silently dropped with no on-screen indication. - Escape remaining_count in the batch confirm modal (koha-qa.pl missing_filter nit). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #102 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203257 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203257&action=edit Bug 19814: (follow-up) Preserve Checked-in items list across confirm modal @checkins is rebuilt from scratch on every request from hidden checkin_counter/checkin_barcode_N inputs (see the pre-existing single-item needs_confirm modal for the same pattern). The batch confirm modal submits its own separate <form>, which never carried these fields, so the "Checked-in items" table appeared to lose all history for items processed before the pause as soon as the librarian clicked Confirm/Skip. Mirror the existing hidden-field block into the batch confirm form so the list survives the round-trip. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #186375|0 |1 is obsolete| | --- Comment #104 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Comment on attachment 186375 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186375 Testing guidance Replace iiuc by the test plan in the last patch marked DO-NOT-PUSH. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #106 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Feedback after following the test plan from the last patch: Thx for this detailed plan btw with re-seeding etc. Issue in step ## 5. WrongTransfer repair Slot 4 row should show "This item is still on transfer to FFL". (OK) The original CPL→FFL row should be marked cancelled / replaced and a new row CPL→MPL should exist with `comments = 'WrongTransfer'`. (NOK) | branchtransfer_id | itemnumber | daterequested | datesent | frombranch | datearrived | datecancelled | tobranch | comments | reason | cancellation_reason | | 5 | 4 | 2026-08-07 09:38:39 | 2026-08-07 09:38:39 | CPL | NULL | NULL | FFL | BATCHTEST19814 | Manual | NULL | | 6 | 4 | 2026-08-07 09:39:55 | 2026-08-07 09:39:55 | CPL | NULL | NULL | MPL | NULL | Reserve | NULL | | 7 | 8 | 2026-08-07 09:39:56 | 2026-08-07 09:39:56 | CPL | NULL | NULL | MPL | NULL | ReturnToHome | NULL | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #108 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- === Some additional tests run: t/db_dependent/Circulation.t .. ok t/db_dependent/Circulation/issue.t .. ok t/db_dependent/Koha/Biblio.t .. ok t/db_dependent/Koha/Checkouts.t .. ok t/db_dependent/Koha/Hold.t .. ok t/db_dependent/Koha/Holds.t .. ok t/db_dependent/Koha/Items.t .. ok t/db_dependent/Koha/Patron.t .. ok t/db_dependent/Koha/Patrons.t .. ok t/db_dependent/Members/IssueSlip.t .. ok t/db_dependent/Overdues.t .. ok t/db_dependent/Reserves.t .. ok t/db_dependent/Reserves/HoldGroup.t .. ok t/db_dependent/SIP/Message.t .. ok t/db_dependent/SIP/Transaction.t .. ok t/db_dependent/api/v1/biblios.t .. ok t/db_dependent/api/v1/checkouts.t .. ok FAILING (EXTRA) TESTS t/db_dependent/Koha/Item.t # Failed test 'no warnings' # at /usr/share/perl/5.36/Test/Builder.pm line 193. # There were 1 warning(s) # Previous test 12 'Can't recall item if patron has already reserved it' # Use of uninitialized value in numeric ge (>=) at /usr/share/koha/Koha/Item.pm line 2593. # at /usr/share/koha/Koha/Item.pm line 2593. # Koha::Item::can_be_recalled(Koha::Item=HASH(0x560490927580), HASH(0x56049029c2d0)) called at t/db_dependent/Koha/Item.t line 3086 # main::__ANON__() called at /usr/share/perl/5.36/Test/Builder.pm line 374 # eval {...} called at /usr/share/perl/5.36/Test/Builder.pm line 374 # Test::Builder::subtest(Test::Builder=HASH(0x560483110fe8), "Recalls tests", CODE(0x560482f487a0)) called at /usr/share/perl/5.36/Test/More.pm line 809 # Test::More::subtest("Recalls tests", CODE(0x560482f487a0)) called at t/db_dependent/Koha/Item.t line 3204 # # Looks like you failed 1 test of 42. => Seems to be innocent. An uninitialized warn about recalls. This probably warns too without this patch set? CONFIRMED Fails too without. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #109 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203348 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203348&action=edit Bug 19814: (follow-up) Fix no-op WrongTransfer repair repair_wrong_transfer() asked request_transfer() to replace the stale transfer with one to the same to_library/reason as the transfer it was replacing. request_transfer()'s own dedup check runs before the replace logic and matches on frombranch/tobranch/reason, so whenever the item's current holding branch equalled the stale transfer's frombranch (e.g. the item never actually left and was checked in again at the same branch), that check found the stale transfer still live and handed it straight back -- silently skipping the replace. The old row was never cancelled and no new row was created. Cancel the stale transfer explicitly before requesting its replacement, so request_transfer()'s dedup search no longer sees it as live. This is the same bug in both the single-item and batch checkin paths, since both call this shared sub. Test plan: 1. Set up a transfer for item X from library A -> B, then check the item back in at library A itself (its own frombranch) rather than B or a third branch. 2. Before this patch: the A->B transfer row is untouched -- datecancelled/cancellation_reason stay NULL, no new row appears. 3. After this patch: the A->B row gets datecancelled set and cancellation_reason = 'WrongTransfer', and a new row is created recording the item's corrected frombranch. 4. Repeat via batch checkin -- same result. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #111 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Now seeing this as a result of running (only) step 5 again of the test plan including a re-seed: +-------------------+------------+---------------------+---------------------+------------+-------------+---------------------+----------+----------------+--------------+---------------------+ | branchtransfer_id | itemnumber | daterequested | datesent | frombranch | datearrived | datecancelled | tobranch | comments | reason | cancellation_reason | +-------------------+------------+---------------------+---------------------+------------+-------------+---------------------+----------+----------------+--------------+---------------------+ | 129 | 4 | 2026-08-10 14:04:16 | 2026-08-10 14:04:16 | CPL | NULL | 2026-08-10 14:05:36 | FFL | BATCHTEST19814 | Manual | WrongTransfer | | 130 | 4 | 2026-08-10 14:05:36 | NULL | CPL | NULL | NULL | FFL | NULL | Manual | NULL | | 131 | 4 | 2026-08-10 14:05:36 | 2026-08-10 14:05:36 | CPL | NULL | NULL | MPL | NULL | Reserve | NULL | | 132 | 8 | 2026-08-10 14:05:36 | 2026-08-10 14:05:36 | CPL | NULL | NULL | MPL | NULL | ReturnToHome | NULL | +-------------------+------------+---------------------+---------------------+------------+-------------+---------------------+----------+----------------+--------------+---------------------+ But note that I am wondering what we really expect Koha to do here? We are checking in an item at CPL while there is an active transfer to FFL. So this is a wrong situation that should normally not occur. Assuming that we have the item at hand in CPL now (checkin), the transfer is wrong (why recreate it)? Shouldnt we just create a transfer to MPL for the hold (as happens now too)? After step 5, I decided to check in the item at Midway to see what happens. I confirm the hold and The transfer to MPL is marked arrived. I checkout to this patron and check in again. A transfer is automatically created from MPL to CPL (ReturnToHome). Note that the transfer to FFL got marked as arrived at the same time as the fist checkin on Midway, so same time as CPL-MPL transfer. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #114 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Martin Renvoize (ashimema) from comment #113)

That really had me scratching me head.. I think some of it was for audit reasons and is pre-existing functionality.. the other bit I've fixed with a follow-up and is about ModReserve mis-identifying some transfers and marking them complete when really it shouldn't.

Thx for doing so. I retested step 5 now. After that branchtransfers looks like: | 141 | 4 | 2026-08-21 10:35:54 | 2026-08-21 10:35:54 | CPL | NULL | 2026-08-21 10:37:14 | FFL | BATCHTEST19814 | Manual | WrongTransfer | | 142 | 4 | 2026-08-21 10:37:14 | NULL | CPL | NULL | NULL | FFL | NULL | Manual | NULL | | 143 | 4 | 2026-08-21 10:37:14 | 2026-08-21 10:37:14 | CPL | NULL | NULL | MPL | NULL | Reserve | NULL | | 144 | 8 | 2026-08-21 10:37:15 | 2026-08-21 10:37:15 | CPL | NULL | NULL | MPL | NULL | ReturnToHome | NULL | The transfer to FFL is cancelled as we expect. The Reserve transfer from CPL to MPL arrived as expected. But unfortunately, I still see a new manual transfer from CPL to FFL. Not sent, only requested. Should we really create that one? I am not sure. The two follow-ups look good to me btw. Maybe we should just leave this as-is now, since it feels like we want to fix existing 'bugs' that go out of scope? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #203226|0 |1 is obsolete| | Attachment #203227|0 |1 is obsolete| | Attachment #203228|0 |1 is obsolete| | Attachment #203229|0 |1 is obsolete| | Attachment #203230|0 |1 is obsolete| | Attachment #203231|0 |1 is obsolete| | Attachment #203232|0 |1 is obsolete| | Attachment #203233|0 |1 is obsolete| | Attachment #203234|0 |1 is obsolete| | Attachment #203235|0 |1 is obsolete| | Attachment #203236|0 |1 is obsolete| | Attachment #203237|0 |1 is obsolete| | Attachment #203238|0 |1 is obsolete| | Attachment #203239|0 |1 is obsolete| | Attachment #203240|0 |1 is obsolete| | Attachment #203241|0 |1 is obsolete| | Attachment #203242|0 |1 is obsolete| | Attachment #203243|0 |1 is obsolete| | Attachment #203244|0 |1 is obsolete| | Attachment #203245|0 |1 is obsolete| | Attachment #203246|0 |1 is obsolete| | Attachment #203247|0 |1 is obsolete| | Attachment #203248|0 |1 is obsolete| | Attachment #203249|0 |1 is obsolete| | Attachment #203250|0 |1 is obsolete| | Attachment #203251|0 |1 is obsolete| | Attachment #203252|0 |1 is obsolete| | Attachment #203253|0 |1 is obsolete| | Attachment #203254|0 |1 is obsolete| | Attachment #203255|0 |1 is obsolete| | Attachment #203256|0 |1 is obsolete| | Attachment #203257|0 |1 is obsolete| | Attachment #203348|0 |1 is obsolete| | Attachment #203533|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #116 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204013 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204013&action=edit Bug 19814: Add preference BatchCheckinDefaults Still WIP. TODO Database revision for pref and authorised values. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #118 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204015 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204015&action=edit Bug 19814: Allow to configure debounce interval Test plan: Change value in koha-conf.xml. Say 5000. Restart all. Verify that batch mode now respects this new delay value. (Type a bad barcode, press Enter, and count seconds.) Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #120 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204017 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204017&action=edit Bug 19814: Confirm hold or transfer Test plan: Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #122 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204019 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204019&action=edit Bug 19814: (follow-up) Fix batch mode settings UI bugs Hide sub-settings on load, fix copy-pasted label for=, move inline styles to SCSS, make debounceInterval a number. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #124 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204021 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204021&action=edit Bug 19814: (follow-up) Rename rfid_debounce_interval config Setting is batch-checkin-wide; rename to batch_checkin_debounce_interval and align defaults (500ms). Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #126 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204023 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204023&action=edit Bug 19814: (follow-up) Share checkin messages include and sub Extract batch per-item logic into process_batch_checkin_item; share AddReturn message rendering via checkin-messages.inc. Single-item path uses approach (b): filter messages to the complement of errmsgloop codes to avoid duplicate alerts. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #128 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204025 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204025&action=edit Bug 19814: (follow-up) Render NotIssued as info in batch Add status key on batch results; hide whole row when pref BATCH_CHECKIN_IGNORE_NOTISSUED is set, instead of message only. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #130 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204027 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204027&action=edit Bug 19814: (follow-up) Add BatchCheckinDefaults pref and AVs Insert BatchCheckinDefaults syspref and BATCH_CHECKIN_DEFAULTS authorised value category with five entries. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #132 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204029 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204029&action=edit Bug 19814: (follow-up) Move batch confirm to a modal Replaces the per-row Action column with an auto-opening modal that offers Confirm, Skip, and Cancel for parts/bundle confirmation. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #134 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204031 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204031&action=edit Bug 19814: (follow-up) Namespace batch modal click handlers The initial wire-up for the batch confirm modal used plain .on('click', ...) on three buttons. In the current flow the modal is only ever server-rendered once per page load, so this is safe today, but binding without a matching .off() means that if the modal markup ever gets re-rendered mid-session (for example via a future AJAX flow) the handlers would stack, producing duplicate hidden inputs and double form submissions. Use a .batchConfirm event namespace and .off()/.on() so the wire-up is idempotent regardless of how often it runs. Test plan: 1. Scan a batch list containing an item that triggers the confirm modal; click "Confirm all parts present" / "Skip this item" / "Cancel batch" in turn and confirm each still behaves as before. 2. Inspect the form on submit and confirm only a single multiple_confirm (or confirm_items_bundle_return / batch_skip_confirm) hidden input is appended. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #136 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204033 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204033&action=edit Bug 19814: (follow-up) Warn on batch state JSON failures The three eval-guarded encode_json / decode_json calls that round-trip batch checkin results through the hidden batch_completed_results form field previously swallowed any exception silently. A corrupt or oversized payload would just produce an empty completed-results list on the next request with no trace in the logs. Log each failure through Koha::Logger so operators can see why batch state was lost. Test plan: 1. Open a batch checkin that triggers the confirm modal (so a batch_completed_results value is actually round-tripped). 2. Edit the browser DevTools network tab (or use a browser form inspector) to replace the batch_completed_results hidden value with an obviously-invalid string, e.g. "not-json", and submit. 3. Confirm the request still renders (no 500), and that plack-intranet-error.log contains the Koha::Logger warning "Failed to decode batch_completed_results JSON: ...". 4. Normal batch submissions should log nothing new. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #138 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204035 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204035&action=edit Bug 19814: (follow-up) Repair WrongTransfer rows during batch checkin When AddReturn flags a WrongTransfer (item arrived at an unexpected branch en route to its real destination) the single-item post-processing block replaces the existing transfer with a new one tagged replace => 'WrongTransfer' so the audit trail records the correction. The batch loop ran AddReturn but never performed this repair, so batch-scanned items that hit a WrongTransfer left the DB state stale. Extract the repair into repair_wrong_transfer() and call it from both the single-item block and process_batch_checkin_item. Test plan: 1. Set up a transfer where item X should go from library A -> B. 2. Scan item X at library C (single-item) -> new transfer row replaces the old one with reason WrongTransfer. 3. Scan item X at library C in batch mode -> same new transfer row is created (verify in branchtransfers table). Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #140 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204037 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204037&action=edit Bug 19814: (follow-up) Seed lib_opac for batch checkin AVs The INSERT for BATCH_CHECKIN_DEFAULTS authorised values only set lib, leaving lib_opac NULL. Staff-only AVs still render fine, but aligning lib_opac matches the pattern used by other system AVs and keeps the admin AV editor from showing an empty OPAC label column when the category is inspected. The category itself is already flagged is_system=1 so it cannot be deleted from the UI. Test plan: 1) Drop the BATCH_CHECKIN_DEFAULTS rows, rerun the atomicupdate, and verify the lib_opac column is populated. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #142 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204039 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204039&action=edit Bug 19814: (follow-up) Surface more checkin messages in batch rows The shared checkin-messages.inc was used in both the single-item path (alongside the rich errmsgloop rendering) and the new batch results rows. In single-item mode the librarian still saw the errmsgloop content, so the include could get away with ignoring several message codes. Batch rows render the include alone, which left lost-item fee refunds, processing fee refunds, return claim resolution, and bundle warnings invisible to the librarian. Add alert-style renderings for: - LostItemFeeRefunded / LostItemFeeCharged / LostItemFeeRestored - LostItemPaymentNotRefunded - ProcessingFeeRefunded - ClaimAutoResolved - ReturnClaims (summary only; full modal still fires in single-item) - InBundle (summary only; full bundle dialog still fires in single-item) The ignore regex is trimmed to genuinely internal codes (Transfer(To|Trigger), WrongTransferItem, WasReturned). Test plan: 1) Enable batch checkin. Check in a lost item that triggers LostItemFeeRefunded and confirm the refund notice appears. 2) Check in an item flagged as a return claim and confirm the "claimed as returned" notice appears in the batch row. 3) Check in an item that belongs to a bundle and confirm the bundle notice appears in the batch row. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #144 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204041 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204041&action=edit Bug 19814: (follow-up) Surface silent batch failures to the librarian - Flag unresolved hold confirmation in the batch row (HoldConfirmFailed) when Koha::Holds->find() returns undef for a ResFound hold -- the item was still returned but the librarian had no way to know the hold wasn't captured. - Surface batch state JSON encode/decode failures with a template flag and banner instead of only logging server-side -- previously completed results and preserved toggles (exempt fines, dropbox, backdate) could be silently dropped with no on-screen indication. - Escape remaining_count in the batch confirm modal (koha-qa.pl missing_filter nit). Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #146 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204043 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204043&action=edit Bug 19814: (follow-up) Preserve Checked-in items list across confirm modal @checkins is rebuilt from scratch on every request from hidden checkin_counter/checkin_barcode_N inputs (see the pre-existing single-item needs_confirm modal for the same pattern). The batch confirm modal submits its own separate <form>, which never carried these fields, so the "Checked-in items" table appeared to lose all history for items processed before the pause as soon as the librarian clicked Confirm/Skip. Mirror the existing hidden-field block into the batch confirm form so the list survives the round-trip. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 --- Comment #148 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 204045 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204045&action=edit Bug 19814: (follow-up) Only receive in-transit transfers in ModReserveAffect ModReserveAffect() unconditionally called ->receive on whatever Koha::Item->get_transfer returned when filling a hold at its own pickup branch. get_transfer() deliberately falls back to a merely *requested* (never sent) transfer once any in-transit transfer for the item has already been received elsewhere -- this is what lets transfers queue behind each other (stock rotation, manual transfers, WrongTransfer repairs). That fallback made ModReserveAffect stamp datearrived on a completely unrelated, never-dispatched transfer any time a hold's own transfer had already been received earlier in the same checkin (e.g. an in-transit Reserve transfer arriving directly via AddReturn, leaving a queued WrongTransfer-repair request to a third branch as the last remaining "current" transfer). The queued transfer was falsely marked arrived even though it had never been sent. Only an in-transit transfer can meaningfully be said to have arrived; a requested-but-unsent one hasn't gone anywhere and must be left alone for staff to dispatch later. Test plan: 1. prove t/db_dependent/Reserves.t t/db_dependent/Circulation.t t/db_dependent/Koha/Hold.t t/db_dependent/Holds/WaitingReserves.t t/db_dependent/HoldsQueue.t 2. Reproduce via circ/returns.pl: check in an item at a branch where it has an active (sent) transfer to a third branch, so WrongTransfer repair creates a new, unsent replacement request. Separately confirm a hold for the same item that gets its own transfer dispatched and received. Confirming the hold no longer marks the unrelated, unsent WrongTransfer-repair transfer as arrived. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Sebastian Hierl <s.hierl@aarome.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|s.hierl@aarome.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com QA Contact|testopia@bugs.koha-communit |tomascohen@gmail.com |y.org | -- You are receiving this mail because: You are watching all bug changes.