dcd1f5d48c
Here we go, next step then. As we did not fix the performance issue when autofiltering the variables (see bug 20975), the only solution we have is to add the filters explicitely. This patch has been autogenerated (using add_html_filters.pl, see next pathces) and add the html filter to all the variables displayed in the template. Exceptions are made (using the new 'raw' TT filter) to the variable we already listed in the previous versions of this patch. To test: - Use t/db_dependent/Koha/Patrons.t to populate your DB with autogenerated data which contain <script> tags - Remove them from borrower_debarments.comments (there are allowed here) update borrower_debarments set comment="html tags possible here"; - From the interface hit page and try to catch alert box. If you find one it means you find a possible XSS. To know where it comes from: * note the exact URL where you found it * note the alert box content * Dump your DB and search for the string in the dump to identify its location (for instance table.field) Next: * Ideally we would like to use the raw filter when it is not necessary to HTML escape the variables (in big loop for instance) * Provide a QA script to catch missing filters (we want html, uri, url or raw, certainly others that I am forgetting now) * Replace the html filters with uri when needed (!) Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
51 lines
2.3 KiB
Text
51 lines
2.3 KiB
Text
[% INCLUDE 'help-top.inc' %]
|
|
|
|
<h1>Record Matching Rules</h1>
|
|
|
|
<p>Record matching rules are used when importing MARC records into Koha.</p>
|
|
|
|
<p>The rules that you set up here will be referenced with you Stage MARC Records for Import.</p>
|
|
|
|
<p>To create a new matching rule:</p>
|
|
|
|
<ul>
|
|
<li>Click 'New Record Matching Rule'
|
|
<ul>
|
|
<li>Choose a unique name and enter it in the 'Matching rule code' field</li>
|
|
<li>'Description' can be anything you want to make it clear to you what rule you're picking</li>
|
|
<li>'Match threshold' - The total number of 'points' a biblio must earn to be considered a 'match'</li>
|
|
<li>Match points are set up to determine what fields to match on</li>
|
|
<li>'Search index' can be found by looking at the ccl.properties file on your system which tells the zebra indexing what data to search for in the MARC data".</li>
|
|
<li>'Score' - The number of 'points' a match on this field is worth. If the sum of each score is greater than the match threshold, the incoming record is a match to the existing record</li>
|
|
<li>Enter the MARC tag you want to match on in the 'Tag' field</li>
|
|
<li>Enter the MARC tag subfield you want to match on in the 'Subfields' field</li>
|
|
<li>'Offset' - For use with control fields, 001-009</li>
|
|
<li>'Length' - For use with control fields, 001-009</li>
|
|
<li>Koha only has one 'Normalization rule' that removes extra characters such as commas and semicolons. The value you enter in this field is irrelevant to the normalization process.</li>
|
|
<li>'Required match checks' - ??</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2>Sample Record Matching Rule: Control Number</h2>
|
|
|
|
<ul>
|
|
<li>Match threshold: 100</li>
|
|
<li>Matchpoints (just the one):</li>
|
|
<li>Search index: Control-number</li>
|
|
<li>Score: 101</li>
|
|
<li>Tag: 001
|
|
<ul>
|
|
<li>this field is for the control number assigned by the organization creating, using, or distributing the record</li>
|
|
</ul>
|
|
</li>
|
|
<li>Subfields: a</li>
|
|
<li>Offset: 0</li>
|
|
<li>Length: 0</li>
|
|
<li>Normalization rule: Control-number</li>
|
|
<li>Required Match checks: none (remove the blank one)</li>
|
|
</ul>
|
|
|
|
<p><strong>See the full documentation for Record Matching Rules in the <a href="http://koha-community.org/manual/[% helpVersion | html %]/en/html/administration.html#record-matching-rules">manual</a> (online).</strong></p>
|
|
|
|
[% INCLUDE 'help-bottom.inc' %]
|