Bug 42018 - Inconsistent behavior for null values for fields selected in PatronDuplicateMatchingAddFields
Summary: Inconsistent behavior for null values for fields selected in PatronDuplicateM...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 25.11
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-03-06 21:57 UTC by Sara Brown
Modified: 2026-03-06 21:57 UTC (History)
2 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Crowdfunding committed: 0
Crowdfunding contact:
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sara Brown 2026-03-06 21:57:15 UTC
PatronDuplicateMatchingAddFields behaves differently for null values depending on whether the null values are in the existing patron record or the record being created.

To replicate:
-Set PatronDuplicateMatchingAddFields to surname, firstname, email

Scenario 1:
-Create patron A with a first name and surname, but null email
-Create patron B with a first name and surname matching patron A, but a value in email -----> NOT FLAGGED as duplicate

Scenario 2:
-Create patron A with a first name, surname, and email
-Create patron B with a first name and surname matching patron A, but null email -----> FLAGGED as duplicate

It seems that the two scenarios should behave the same way, or that there should be documentation of the different behavior in the manual.

This applies to 40082 but is also true for duplicate matching in the staff interface.