https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43637 Bug ID: 43637 Summary: Refactor patron image upload into a reusable engine class and background job Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com Target Milestone: --- This patch extracts tools/picture-upload.pl's inline patron image import logic (previously coupled to CGI globals) into a reusable, CGI-free Koha::Patron::Image::Import engine class, and adds a Koha::BackgroundJob::PatronImageImport background job for batch/zip uploads. Single-image upload - including the "Patron photo" modal and webcam capture embedded on every patron's own record page - stays fully synchronous, since that instant "upload and see it now" UX is this tool's most common real-world use and doesn't benefit from being async. Batch/zip upload alone moves to the same two-step AJAX-upload plus background-job pattern tools/import_borrowers.pl already established. Both modes gain a configurable matchpoint (card number, username, or a patron attribute type), replacing the previous hardcoded card-number-only lookup. Batch mode also supports filename-stem matching for zips with no idlink.txt/datalink.txt mapping file - each image is matched by its own filename (minus extension) against the chosen matchpoint directly. Along the way this replaces the original tool's shelled-out unzip and naive path-traversal check with a real Archive::Zip-based extraction and zip-slip guard, and fixes a resize-math bug where oversized images were scaled against stale 140x200 literals instead of the tool's own documented and threshold-checked 200x300 maximum. This is a precursor to a separate, not-yet-filed bug for scheduled/automated patron image import via file transports (mirroring Koha's existing scheduled patron import feature) - that work depends on the engine class this patch introduces, but scheduling itself is out of scope here. Test plan: 1. Apply the whole patchset, update the database if prompted, restart_all. 2. Open any patron's record, use the "Patron photo" modal to upload a file, and confirm it appears immediately (no job, no delay) - then delete it the same way. If a webcam is available, confirm the "Take patron photo" capture flow also still works. 3. Go to Tools > Upload patron images, select "Image file", choose a matchpoint (try username, and a patron attribute type if Extended patron attributes is enabled), type a matching identifier, upload a file, and confirm immediate success. 4. Prepare a zip containing two images and an idlink.txt mapping file using your chosen matchpoint's values, upload it via "Zip file" mode, and confirm you land on a "job enqueued" page; follow its link to view the job and confirm it shows imported/error counts and a progress bar that advances while the job runs. 5. Prepare a second zip with loose images named <identifier>.<ext> and no mapping file; upload it and confirm each is matched by its own filename. 6. Prepare a zip whose idlink.txt has a row pointing outside the archive (e.g. "BADCARD,../../etc/passwd"); upload it and confirm the job's error report shows that row failed safely, with no file touched outside the archive. 7. Prepare a zip whose idlink.txt has one good row and one row using an unrecognized delimiter; confirm the good row imports and the bad row is reported as an error, not silently dropped. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.