https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27087
--- Comment #3 from David Cook <[email protected]> --- (In reply to Andrew Fuerste-Henry from comment #2) > So maybe a broader move to allow match checks to use a comparison other than > equals? So we'd set a target subfield in the incoming record, a target > subfield in the existing record, and a comparison operator? > I'd say a broader move to allow match points to use comparisons other than equals. (LDR and control fields don't have subfields.) > But the values on the encoding level aren't strictly numeric. "#" is the > "best" value, followed by 1-8, then "u" for unknown and "z" for not > applicable (https://www.loc.gov/marc/bibliographic/bdleader.html). We could > hardcode that hierarchy for encoding level, but it seems likely other bits > of MARC have comparably idiosyncratic sets of values. Should the match check > setup include a mechanism for telling Koha an order of preference for > possible values? Mmm that's an interesting wrinkle. That's a lot more complicated. Perhaps we should look at plugins for record matching rules. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
