[Bug 32054] New: GetImportRecordMatches returns the wrong match when passed 'best only'
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 Bug ID: 32054 Summary: GetImportRecordMatches returns the wrong match when passed 'best only' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs@lists.koha-community.org Reporter: nick@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org The routine orders by score/biblionumber desc - it limits to the first match when 'best only' is passed. With bug 22785 we introduced a 'chosen' field to allow the best, or no match, be chosen We need to honor this when getting the matches This causes order imports to choose the wrong match -- 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=32054 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- 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=32054 --- Comment #1 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 142838 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=142838&action=edit Bug 32054: Add get_import_record_matches object method and use it Thispatch adds the new method and alters addorderiso2907.pl to use this rather than GetRecordImportMatches To test: 1 - Import the attached record several times 2 - Set up a matching rule: TitleAuthor threshold: 100 Matchpoint: search index: title, score: 100, tag: 245$a search index: author, score: 100, tag:100$a 3 - Edit one of the imported records to have a different author 4 - Stage the file again. and match using the matchpoint above 5 - Note that matches are found and listed on batch management, with the lowest scored match last 6 - Choose that match 7 - In acquisitions, add to a basket from the staged file 8 - Check the box for the record 9 - Note the match lists the biblionumber for the highest scoring match, not the chosen one 10 - Add an order and note it is for the wrong biblio 11 - Appy patch 12 - Restart_all 13 - Stage the file again and choose a lower scoring match 14 - Confirm when adding to basket this match is preserved 15 - Complete order and verify correct biblio ordered 16 - Stage again, select no match 17 - Confirm no match listed when adding to basket, and choose 'Do not look for matching records' while adding 18 - Confirm order is created on a new biblio -- 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=32054 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |nick@bywatersolutions.com |ity.org | -- 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=32054 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #2 from David Nind <david@davidnind.com> --- I'm happy to try and test, however there is no attached record (step 1 of the test plan). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #3 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 142896 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=142896&action=edit Sample biblio from sample database -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #142838|0 |1 is obsolete| | --- Comment #4 from David Nind <david@davidnind.com> --- Created attachment 143293 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=143293&action=edit Bug 32054: Add get_import_record_matches object method and use it Thispatch adds the new method and alters addorderiso2907.pl to use this rather than GetRecordImportMatches To test: 1 - Import the attached record several times 2 - Set up a matching rule: TitleAuthor threshold: 100 Matchpoint: search index: title, score: 100, tag: 245$a search index: author, score: 100, tag:100$a 3 - Edit one of the imported records to have a different author 4 - Stage the file again. and match using the matchpoint above 5 - Note that matches are found and listed on batch management, with the lowest scored match last 6 - Choose that match 7 - In acquisitions, add to a basket from the staged file 8 - Check the box for the record 9 - Note the match lists the biblionumber for the highest scoring match, not the chosen one 10 - Add an order and note it is for the wrong biblio 11 - Appy patch 12 - Restart_all 13 - Stage the file again and choose a lower scoring match 14 - Confirm when adding to basket this match is preserved 15 - Complete order and verify correct biblio ordered 16 - Stage again, select no match 17 - Confirm no match listed when adding to basket, and choose 'Do not look for matching records' while adding 18 - Confirm order is created on a new biblio Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #5 from David Nind <david@davidnind.com> --- I think I tested this correctly - this is the first time I've used matching rules and adding to an order from a staged record. Mainly found the options for steps 14-15, and the duplicate record message and choices, a bit confusing. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |32437 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32437 [Bug 32437] When adding to a basket form a staged file and matching the imported records are ignored when set to overwrite -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #6 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- This patch leaves us with one actual remaining call of GetImportRecordMatches: C4/ImportBatch.pm: GetImportRecordMatches C4/ImportBatch.pm:=head2 GetImportRecordMatches C4/ImportBatch.pm: my $results = GetImportRecordMatches($import_record_id, $best_only); C4/ImportBatch.pm:sub GetImportRecordMatches { tools/batch_records_ajax.pl:use C4::ImportBatch qw( GetImportBatch GetImportRecordsRange GetImportRecordMatches ); tools/batch_records_ajax.pl: my $matches = GetImportRecordMatches( $record->{'import_record_id'} ); The last one is the only real one. koha-tmpl/intranet-tmpl/prog/en/modules/tools/manage-marc-import.tt: "sAjaxSource": 'batch_records_ajax.pl', -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #7 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Having issues with the background jobs here. The staged file job is stuck on New status. Restarted stuff etc. No change at all. Logs dont make me wiser. Please confirm if it still works.. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #8 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Marcel de Rooy from comment #7)
Having issues with the background jobs here. The staged file job is stuck on New status. Restarted stuff etc. No change at all. Logs dont make me wiser. Please confirm if it still works..
I am able to stage and import without issue -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #9 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Nick Clemens from comment #8)
(In reply to Marcel de Rooy from comment #7)
Having issues with the background jobs here. The staged file job is stuck on New status. Restarted stuff etc. No change at all. Logs dont make me wiser. Please confirm if it still works..
I am able to stage and import without issue
Resolved that now ;) background_jobs.. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #10 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- We could go ahead but we could also try here to remove the last occurrence. What do you think? See comment6. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |m.de.rooy@rijksmuseum.nl |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #11 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Marcel de Rooy from comment #10)
We could go ahead but we could also try here to remove the last occurrence. What do you think? See comment6.
The real fix there is to remove that script and use API to build the datatables - we could update it to remove the use, but it feels like it would be double work. Either way, I think that should be on its own report -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #143293|0 |1 is obsolete| | --- Comment #12 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 145360 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145360&action=edit Bug 32054: Add get_import_record_matches object method and use it Thispatch adds the new method and alters addorderiso2907.pl to use this rather than GetRecordImportMatches To test: 1 - Import the attached record several times 2 - Set up a matching rule: TitleAuthor threshold: 100 Matchpoint: search index: title, score: 100, tag: 245$a search index: author, score: 100, tag:100$a 3 - Edit one of the imported records to have a different author 4 - Stage the file again. and match using the matchpoint above 5 - Note that matches are found and listed on batch management, with the lowest scored match last 6 - Choose that match 7 - In acquisitions, add to a basket from the staged file 8 - Check the box for the record 9 - Note the match lists the biblionumber for the highest scoring match, not the chosen one 10 - Add an order and note it is for the wrong biblio 11 - Appy patch 12 - Restart_all 13 - Stage the file again and choose a lower scoring match 14 - Confirm when adding to basket this match is preserved 15 - Complete order and verify correct biblio ordered 16 - Stage again, select no match 17 - Confirm no match listed when adding to basket, and choose 'Do not look for matching records' while adding 18 - Confirm order is created on a new biblio Signed-off-by: David Nind <david@davidnind.com> 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=32054 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |23.05.00 released in| | Status|Passed QA |Pushed to master -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #13 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Nice work everyone! Pushed to 23.05.x for the next release -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 Jacob O'Mara <jacob.omara@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|23.05.00 |23.05.00,22.11.02 released in| | Status|Pushed to master |Pushed to stable -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #14 from Jacob O'Mara <jacob.omara@ptfs-europe.com> --- Nice work, thanks everyone! Pushed to 22.11.x for the next release. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32054 --- Comment #15 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 147184 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147184&action=edit Bug 30254: [22.05.x] Don't charge overdue fines unless some fine exists We need to determine if a book was lost by a patron, the clues we have are previous charges. If we don't find any, we shouldn't charge a new fine To test: 1 - set Lost item fee refund on return policy to "Refund lost item charge and charge new overdue fine", turn on FinesMode, make sure your circ rules charge fines 2 - have an itemtype / patron combo that charges an overdue fine 3 - check item out (with a due date in the future) and then right back in again 4 - confirm patron doesn't have a fine because the item was not late 5 - set the item to Lost 6 - in the database, edit the date_due of your checkout to a date in the past 7 - check the item in, it is marked found 8 - confirm your patron now has a fine 9 - Apply patch 10 - Repeat with a new item and patron 11 - Confirm no charges Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Bug 30254: Unit tests Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Bug 30254: (QA follow-up) Remove warn from tests Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org