https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- 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=41901 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff 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=41901 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197179 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197179&action=edit Bug 41901: Allow duplicate check when adding authority via API POST /api/v1/authorities currently offers only the heading-based C4::AuthoritiesMarc::FindDuplicateAuthority check, and the only escape hatch is the `x-koha-override` header. Koha already ships configurable record matching rules (see Administration > Record matching rules) and C4::Matcher already supports `record_type = authority`. This patch lets an API caller opt into one of those rules when creating an authority by sending its numeric id in a new `x-koha-matchrule` header. Behaviour: * If no `x-koha-matchrule` header is sent the existing heading-based duplicate check is used. Existing clients are unaffected. * If `x-koha-matchrule: <id>` is sent: * non-existent id -> 400 `matching_rule_not_found` * matcher not record_type=authority -> 400 `invalid_matching_rule_type` * matcher returns matches -> 409 `duplicate`; the response body additionally contains a `matches: [{authid, score}, ...]` array listing every hit returned by the matcher * matcher returns nothing -> record is created (201) * `x-koha-override: any|duplicate` continues to bypass all duplicate checks, including the matcher. A non-integer header value is rejected by the OpenAPI schema validator before the controller runs. Test plan: 1) Apply the patch series. 2) Run `prove t/db_dependent/api/v1/authorities.t` => all subtests pass. 3) Log in to the staff interface as a user with the 'manage_matching_rules' subpermission and go to Administration > Record matching rules > New record matching rule: a) Set Matching rule code e.g. `AUTH_HEADING` b) Set Description e.g. `Authority heading match` c) Set Record type to `authority` d) Set Threshold to e.g. `1000` e) Add a match point: * Search index: `Heading-Main` (or your authorities index) * Score: `1000` * Tag: `110` (or the heading tag used by your authority type) * Subfields: `a` f) Save. Note the numeric matching rule id in the edit URL (`admin/matching-rules.pl?op=edit_matching_rule&matcher_id=N`). 4) Export an existing authority record as MARCXML (for example from the authority details page). Save it as `duplicate.xml`. 5) From the command line, POST the record back to Koha using the new header (replace <N>, credentials and host): curl -u <user>:<pass> -X POST \ -H 'Content-Type: application/marcxml+xml' \ -H 'x-authority-type: CORPO_NAME' \ -H 'x-koha-matchrule: <N>' \ --data-binary @duplicate.xml \ http://<your-koha>/api/v1/authorities => Expect HTTP 409. The JSON response body contains `error_code: "duplicate"` and a `matches` array listing the authid(s) that were found along with their score. 6) Edit `duplicate.xml` so the main heading is something that is not already in the catalogue. POST it again with the same header. => Expect HTTP 201 and a `Location` header pointing to the new authority. 7) Re-run the POST from step 5 but additionally send `-H 'x-koha-override: duplicate'`. => Expect HTTP 201 (override bypasses the matcher). 8) Send a POST with `x-koha-matchrule: 999999`. => Expect HTTP 400 with `error_code: "matching_rule_not_found"`. 9) Create a second matching rule with Record type `biblio` and note its id. POST with `x-koha-matchrule` set to that id. => Expect HTTP 400 with `error_code: "invalid_matching_rule_type"`. 10) POST with `x-koha-matchrule: abc`. => Expect HTTP 400 from the OpenAPI schema validator. 11) POST without `x-koha-matchrule`. => Expect the existing heading-based duplicate check to run exactly as before (409 for a known duplicate, 201 otherwise). 12) Sign off. -- You are receiving this mail because: You are watching all bug changes.

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 --- Comment #4 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197323 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197323&action=edit Bug 41901: Unit tests Extends the existing `post() tests` subtest in t/db_dependent/api/v1/authorities.t with coverage for the new `x-koha-matchrule` header that selects a Koha record matching rule (`C4::Matcher`, record_type=authority) for duplicate detection when creating authorities via POST /api/v1/authorities. The new cases exercise: * non-integer id (rejected by the OpenAPI schema validator) * unknown matcher id -> 400 `matching_rule_not_found` * biblio matcher id -> 400 `invalid_matching_rule_type` * valid authority matcher returning duplicates -> 409 with a `matches` array of `{authid, score}` objects * valid authority matcher returning no duplicates -> 201 * matcher combined with `x-koha-override: duplicate` -> 201 (override wins, matcher is skipped) `C4::Matcher` is mocked deterministically to avoid relying on the authority search engine in the test database. These tests fail without the controller/spec changes introduced in the follow-up commit. Test plan: 1) Apply only this patch and run `prove t/db_dependent/api/v1/authorities.t`. => Failures are expected in the `post() tests` subtest for the `x-koha-matchrule` cases. 2) Apply the next patch in the series and re-run the tests. => All subtests pass. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 --- Comment #6 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197325 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197325&action=edit Bug 41901: (follow-up) Fix perlcritic violation in unit tests Remove explicit "return undef" in favour of bare "return" to satisfy Perl::Critic (PBP p.199). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197323|0 |1 is obsolete| | Attachment #197324|0 |1 is obsolete| | Attachment #197325|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=41901 --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197397 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197397&action=edit Bug 41901: Allow duplicate check when adding authority via API POST /api/v1/authorities currently offers only the heading-based C4::AuthoritiesMarc::FindDuplicateAuthority check, and the only escape hatch is the `x-koha-override` header. Koha already ships configurable record matching rules (see Administration > Record matching rules) and C4::Matcher already supports `record_type = authority`. This patch lets an API caller opt into one of those rules when creating an authority by sending its numeric id in a new `x-koha-matchrule` header. Behaviour: * If no `x-koha-matchrule` header is sent the existing heading-based duplicate check is used. Existing clients are unaffected. * If `x-koha-matchrule: <id>` is sent: * non-existent id -> 400 `matching_rule_not_found` * matcher not record_type=authority -> 400 `invalid_matching_rule_type` * matcher returns matches -> 409 `duplicate`; the response body additionally contains a `matches: [{authid, score}, ...]` array listing every hit returned by the matcher * matcher returns nothing -> record is created (201) * `x-koha-override: any|duplicate` continues to bypass all duplicate checks, including the matcher. A non-integer header value is rejected by the OpenAPI schema validator before the controller runs. Test plan: 1) Apply the patch series. 2) Run `prove t/db_dependent/api/v1/authorities.t` => all subtests pass. 3) Log in to the staff interface as a user with the 'manage_matching_rules' subpermission and go to Administration > Record matching rules > New record matching rule: a) Set Matching rule code e.g. `AUTH_HEADING` b) Set Description e.g. `Authority heading match` c) Set Record type to `authority` d) Set Threshold to e.g. `1000` e) Add a match point: * Search index: `Heading-Main` (or your authorities index) * Score: `1000` * Tag: `110` (or the heading tag used by your authority type) * Subfields: `a` f) Save. Note the numeric matching rule id in the edit URL (`admin/matching-rules.pl?op=edit_matching_rule&matcher_id=N`). 4) Export an existing authority record as MARCXML (for example from the authority details page). Save it as `duplicate.xml`. 5) From the command line, POST the record back to Koha using the new header (replace <N>, credentials and host): curl -u <user>:<pass> -X POST \ -H 'Content-Type: application/marcxml+xml' \ -H 'x-authority-type: CORPO_NAME' \ -H 'x-koha-matchrule: <N>' \ --data-binary @duplicate.xml \ http://<your-koha>/api/v1/authorities => Expect HTTP 409. The JSON response body contains `error_code: "duplicate"` and a `matches` array listing the authid(s) that were found along with their score. 6) Edit `duplicate.xml` so the main heading is something that is not already in the catalogue. POST it again with the same header. => Expect HTTP 201 and a `Location` header pointing to the new authority. 7) Re-run the POST from step 5 but additionally send `-H 'x-koha-override: duplicate'`. => Expect HTTP 201 (override bypasses the matcher). 8) Send a POST with `x-koha-matchrule: 999999`. => Expect HTTP 400 with `error_code: "matching_rule_not_found"`. 9) Create a second matching rule with Record type `biblio` and note its id. POST with `x-koha-matchrule` set to that id. => Expect HTTP 400 with `error_code: "invalid_matching_rule_type"`. 10) POST with `x-koha-matchrule: abc`. => Expect HTTP 400 from the OpenAPI schema validator. 11) POST without `x-koha-matchrule`. => Expect the existing heading-based duplicate check to run exactly as before (409 for a known duplicate, 201 otherwise). 12) Sign off. Sponsored-by: The Church of Jesus Christ of Latter Day Saints <https://history.churchofjesuschrist.org/> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Comma delimited|The Church of Jesus Christ | list of Sponsors|of Latter Day Saints | |<https://history.churchofje | |suschrist.org/> | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197396|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=41901 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197398|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=41901 --- Comment #11 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 197539 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197539&action=edit Bug 41901: Allow duplicate check when adding authority via API POST /api/v1/authorities currently offers only the heading-based C4::AuthoritiesMarc::FindDuplicateAuthority check, and the only escape hatch is the `x-koha-override` header. Koha already ships configurable record matching rules (see Administration > Record matching rules) and C4::Matcher already supports `record_type = authority`. This patch lets an API caller opt into one of those rules when creating an authority by sending its numeric id in a new `x-koha-matchrule` header. Behaviour: * If no `x-koha-matchrule` header is sent the existing heading-based duplicate check is used. Existing clients are unaffected. * If `x-koha-matchrule: <id>` is sent: * non-existent id -> 400 `matching_rule_not_found` * matcher not record_type=authority -> 400 `invalid_matching_rule_type` * matcher returns matches -> 409 `duplicate`; the response body additionally contains a `matches: [{authid, score}, ...]` array listing every hit returned by the matcher * matcher returns nothing -> record is created (201) * `x-koha-override: any|duplicate` continues to bypass all duplicate checks, including the matcher. A non-integer header value is rejected by the OpenAPI schema validator before the controller runs. Test plan: 1) Apply the patch series. 2) Run `prove t/db_dependent/api/v1/authorities.t` => all subtests pass. 3) Log in to the staff interface as a user with the 'manage_matching_rules' subpermission and go to Administration > Record matching rules > New record matching rule: a) Set Matching rule code e.g. `AUTH_HEADING` b) Set Description e.g. `Authority heading match` c) Set Record type to `authority` d) Set Threshold to e.g. `1000` e) Add a match point: * Search index: `Heading-Main` (or your authorities index) * Score: `1000` * Tag: `110` (or the heading tag used by your authority type) * Subfields: `a` f) Save. Note the numeric matching rule id in the edit URL (`admin/matching-rules.pl?op=edit_matching_rule&matcher_id=N`). 4) Export an existing authority record as MARCXML (for example from the authority details page). Save it as `duplicate.xml`. 5) From the command line, POST the record back to Koha using the new header (replace <N>, credentials and host): curl -u <user>:<pass> -X POST \ -H 'Content-Type: application/marcxml+xml' \ -H 'x-authority-type: CORPO_NAME' \ -H 'x-koha-matchrule: <N>' \ --data-binary @duplicate.xml \ http://<your-koha>/api/v1/authorities => Expect HTTP 409. The JSON response body contains `error_code: "duplicate"` and a `matches` array listing the authid(s) that were found along with their score. 6) Edit `duplicate.xml` so the main heading is something that is not already in the catalogue. POST it again with the same header. => Expect HTTP 201 and a `Location` header pointing to the new authority. 7) Re-run the POST from step 5 but additionally send `-H 'x-koha-override: duplicate'`. => Expect HTTP 201 (override bypasses the matcher). 8) Send a POST with `x-koha-matchrule: 999999`. => Expect HTTP 400 with `error_code: "matching_rule_not_found"`. 9) Create a second matching rule with Record type `biblio` and note its id. POST with `x-koha-matchrule` set to that id. => Expect HTTP 400 with `error_code: "invalid_matching_rule_type"`. 10) POST with `x-koha-matchrule: abc`. => Expect HTTP 400 from the OpenAPI schema validator. 11) POST without `x-koha-matchrule`. => Expect the existing heading-based duplicate check to run exactly as before (409 for a known duplicate, 201 otherwise). 12) Sign off. Signed-off-by: Brian J. Barr <brian.barr@churchofjesuschrist.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Sponsorship status|Sponsored |--- QA Contact|testopia@bugs.koha-communit |andrew@bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197538|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=41901 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197540|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=41901 --- Comment #14 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 197542 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197542&action=edit Bug 41901: Allow duplicate check when adding authority via API POST /api/v1/authorities currently offers only the heading-based C4::AuthoritiesMarc::FindDuplicateAuthority check, and the only escape hatch is the `x-koha-override` header. Koha already ships configurable record matching rules (see Administration > Record matching rules) and C4::Matcher already supports `record_type = authority`. This patch lets an API caller opt into one of those rules when creating an authority by sending its numeric id in a new `x-koha-matchrule` header. Behaviour: * If no `x-koha-matchrule` header is sent the existing heading-based duplicate check is used. Existing clients are unaffected. * If `x-koha-matchrule: <id>` is sent: * non-existent id -> 400 `matching_rule_not_found` * matcher not record_type=authority -> 400 `invalid_matching_rule_type` * matcher returns matches -> 409 `duplicate`; the response body additionally contains a `matches: [{authid, score}, ...]` array listing every hit returned by the matcher * matcher returns nothing -> record is created (201) * `x-koha-override: any|duplicate` continues to bypass all duplicate checks, including the matcher. A non-integer header value is rejected by the OpenAPI schema validator before the controller runs. Test plan: 1) Apply the patch series. 2) Run `prove t/db_dependent/api/v1/authorities.t` => all subtests pass. 3) Log in to the staff interface as a user with the 'manage_matching_rules' subpermission and go to Administration > Record matching rules > New record matching rule: a) Set Matching rule code e.g. `AUTH_HEADING` b) Set Description e.g. `Authority heading match` c) Set Record type to `authority` d) Set Threshold to e.g. `1000` e) Add a match point: * Search index: `Heading-Main` (or your authorities index) * Score: `1000` * Tag: `110` (or the heading tag used by your authority type) * Subfields: `a` f) Save. Note the numeric matching rule id in the edit URL (`admin/matching-rules.pl?op=edit_matching_rule&matcher_id=N`). 4) Export an existing authority record as MARCXML (for example from the authority details page). Save it as `duplicate.xml`. 5) From the command line, POST the record back to Koha using the new header (replace <N>, credentials and host): curl -u <user>:<pass> -X POST \ -H 'Content-Type: application/marcxml+xml' \ -H 'x-authority-type: CORPO_NAME' \ -H 'x-koha-matchrule: <N>' \ --data-binary @duplicate.xml \ http://<your-koha>/api/v1/authorities => Expect HTTP 409. The JSON response body contains `error_code: "duplicate"` and a `matches` array listing the authid(s) that were found along with their score. 6) Edit `duplicate.xml` so the main heading is something that is not already in the catalogue. POST it again with the same header. => Expect HTTP 201 and a `Location` header pointing to the new authority. 7) Re-run the POST from step 5 but additionally send `-H 'x-koha-override: duplicate'`. => Expect HTTP 201 (override bypasses the matcher). 8) Send a POST with `x-koha-matchrule: 999999`. => Expect HTTP 400 with `error_code: "matching_rule_not_found"`. 9) Create a second matching rule with Record type `biblio` and note its id. POST with `x-koha-matchrule` set to that id. => Expect HTTP 400 with `error_code: "invalid_matching_rule_type"`. 10) POST with `x-koha-matchrule: abc`. => Expect HTTP 400 from the OpenAPI schema validator. 11) POST without `x-koha-matchrule`. => Expect the existing heading-based duplicate check to run exactly as before (409 for a known duplicate, 201 otherwise). 12) Sign off. Signed-off-by: Brian J. Barr <brian.barr@churchofjesuschrist.org> Signed-off-by: Andrew Fuerste Henry <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=41901 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |26.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41901 Jacob O'Mara <jacob.omara@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|26.05.00 |26.05.00,25.11.05 released in| | Status|Pushed to main |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=41901 Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wainuiwitikapark@catalyst.n | |et.nz Status|Pushed to stable |Needs documenting --- Comment #18 from Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> --- Enhancement - not backporting to 25.05 -- You are receiving this mail because: You are watching all bug changes.