If we are adding new records there is no need to check the holds queue, the records can't have holds yet
Created attachment 176186 [details] [review] Bug 37564: Prevent bulkmarcimport from generating holds queue jobs We shouldn't need to update the holds queue for such command line imports.
Created attachment 176188 [details] [review] Bug 37564:[23.11.x] Prevent bulkmarcimport from generating holds queue jobs We shouldn't need to update the holds queue for such command line imports.
Here is the test plan I was trying to follow: - RealTimeHoldsQueue = Enable - Delete any background jobs: DELETE FROM background_jobs; - Check the number of holds queue jobs in the database: SELECT COUNT(*) FROM background_jobs WHERE type = 'update_holds_queue_for_biblios'; - Export a record with items as XML from Koha - Delete the exported record from Koha - Import the record, using bulkmarcimport.pl - Check the jobs in the database, there should be one per item imported - Delete the imported record - Delete all background jobs - Apply the patch - Import the record again - Check the number of holds queue jobs in the database again But when I do the import I end up with this in the database: MariaDB [koha_kohadev]> SELECT * FROM biblio_metadata WHERE biblionumber = 441\G *************************** 1. row *************************** id: 439 biblionumber: 441 format: marcxml schema: MARC21 metadata: <?xml version="1.0" encoding="UTF-8"?> <record xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd" xmlns="http://www.loc.gov/MARC21/slim"> <leader>00080 a2200049 4500</leader> <controlfield tag="005">20250109090642.0</controlfield> <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">441</subfield> <subfield code="d">441</subfield> </datafield> </record> timestamp: 2025-01-09 09:06:42 record_source_id: NULL 1 row in set (0.000 sec) ...and I don't have the time to investigate that right now.