nyuuzyou/wikis huggingface dataset:
How-to

Category:Shared_resources
Category:Resources
Category:Tips_&_Tricks
Category:Documentation
This is a page from which to link "how-to's" or step-by-step procedures to do specific things in Koha.
Please make sure to write the version number of Koha this particular resource is for.
== Administration ==
== Acquisitions ==
== Authorities ==
====Record Matching Rules for Authority records using MARC 001 field – to overwrite existing records.====
Administration>Record matching rules
+ New matching rule
Matching rule code: (short title, eg. AUTH001)
Description: Authority field 001
Match threshold: 100
Record type: Authority record
Match points:
Match point 1
Search index: Local-Number
Score: 101
Match point components:
Tag: 001
Subfields: [leave blank]
Offset: 0
Length: 0
Normalisation rule: None (this field is not present in 22.11)
Save
Stage MARC records for import and follow the steps to upload the MARC authority file.
Settings:
*Record type: Authority
*Record matching rule: AUTH001 (or whatever it was named)
*Action if matching record found: Replace existing record with incoming record
NOTE: The above won't work for Elasticsearch since since that bug updates local-number indexes to type 'Number' and that field type does not include ci_raw handling which authority searching utilises. The work around is to use 'control-number' for your search index above and ensure it's mapped under 'Authorities' in the Elasticsearch configuration.
== Cataloging ==
== Circulation ==
== Lists ==
== Reports ==
== Search / OPAC ==
== Serials ==
== Tools ==
== Misc ==
Knowledge base by InLibro
How the RM push

Here is the workflow of how the RM pushes a patch. A patch can be pushed when he get the status "passed QA". This status can be given by anyone from the QA team.
Patches are usually pushed in the order they pass QA : 1st QAed, 1st pushed.
 
Create a new branch for your patch(es):
 
*git checkout -b new/bug_NNNN
Apply patches to your new branch: 
*git bz apply NNNN
Check 
*fix updatedatabase & version number if applicable
Test the patch
*test
 Run unit tests. Not all, but those who are relevant (are template valid ? is the code perlcritic compliant ? ...) 
Add RM signature on the patch:
*git commit --amend -s
Push the branch to official repo:
*git push gitmain@git.koha-community.org:koha.git HEAD:new/bug_NNNN
Fetch the repo. That will retrieve a origin/new/bug_NNNN branch i'll use immediately for merging main:
*git fetch
Switch to main:
*git checkout main
Merge the branch
*git merge origin/new/bug_NNNN
and push the branch onto main
*git push gitmain@git.koha-community.org:koha.git HEAD:main
Push fetch the repo again to let git know your local main is synch-ed with official main (not necessary, but handy)
*git fetch
Firefox stuff, open the bug and update status
*open http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=NNNN 
*set status to "patch pushed", add a comment "patch pushed, please test" 
*update version number if applicable (rel_3_6 if the patch should be applied on a 3.6, rel_3_8 if the patch is related to a new features that will be in 3.8 only)
Copyright assignment checking:
*check if author must be added into history.txt
Category:Development
Category:Git
Category:Release_Management
How to add an OPAC screen keyboard

The screen keyboard can be added to Koha's OPAC without changing any files. 
It's done by using system preferences only.
Examples
* http://hfjs.bsz-bw.de
= Bootstrap OPAC =
In the Bootstrap OPAC the icon for the screen keyboard will show next to the cart and lists at the top of the page. When clicked, the table with the 'keyboard' shows in the header of the OPAC. 
== OpacUserJs ==
 
/* Screenkeyboard */
var currTarget = "";
function virtKB(os)
{
 currTarget.value+=os; 
 var v = currTarget.value;
 var r = currTarget.createTextRange();
 r.moveStart('character', v.length);
 r.select();
}
 
$(document).ready(function(){
$(".dropdown:eq(1)").after($("#vk_img").clone().show());
$("input").focus(function(){currTarget = this;});
});
== OpacUserCss ==
 
/* Formatting of the table, change and extend to meet your color scheme if necessary */
#vk td:hover {
	background-color:#7DB713;
}
#vk td, th {
 background-color: #FFFFFF;
 border-bottom: 1px solid #DDDDDD;
 border-left: 1px solid #DDDDDD;
 padding: 3px 5px;
}
/* Show only the icon on smaller screens */
@media only screen and (max-width: 800px) {
.vklabel {
 display: none;
 }
}
== OpacHeader ==
You can create a table with every script and all characters you can think of. 
Remove dir="rtl" from the table tag for left-to-right scripts.
 
 
<a id="listsmenu" class="dropdown-toggle" role="button" data-toggle="dropdown" href="#">
<img src="/opac-tmpl/lib/famfamfam/silk/keyboard.png" /> Hebrew screen keyboard</span>
</span>
</a>
 
 א
 ב
 ג
 ד
 ה
 ו
 ז
 ח
 ט
 
 
 י
 כ
 ך
 ל
 מ
 ם
 נ
 ן
 ס
 
 
 ע
 פ
 ף
 צ
 ץ
 ק
 ר
 ש
 ת
 
 
 "
 ,
 -
 :
 
 ␣
 
 
	X</strong>
 
= Pre-Bootstrap OPAC =
== OpacUserJs ==
 
var target = "";
function screenKb(character)
{
 target.value+=character; 
 var r = target.createTextRange();
 r.moveStart('character', target.value.length);
 r.select();
}
 
$(document).ready(function(){
$("input").focus(function(){target = this;});
});
== OpacUserCss ==
 
#screenKb td:hover {
 background-color:#EFF5FB; 
 }
== OpacHeader ==
You can create a table with every script and all characters you can think of. 
Remove dir="rtl" from the table tag for LTR scripts.
 
 
 <img src="/opac-tmpl/prog/famfamfam/silk/keyboard.png" /> Hebrew Screen Keyboard
 
 א
 ב
 ג
 ד
 ה
 ו
 ז
 ח
 ט
 
 
 י
 כ
 ך
 ל
 מ
 ם
 נ
 ן
 ס
 
 
 ע
 פ
 ף
 צ
 ץ
 ק
 ר
 ש
 ת
 
 
 "
 ,
 -
 :
 
 ␣
 
 
	
 X
 
 
Category:Tips & Tricks
How to delete all records and keep settings

= Delete records while keeping configuration settings =
Deletes data from a Koha instance (library) without deleting the configuration, authorized values etc.
== Introduction ==
When to use? If you need to empty the Koha library of all its data without losing configuration settings and authorized values, e.g. borrower types, locations, libraries, media types... This will mostly be needed when preparing for large data operations like importing or migrating data into Koha from other sources, when one or several test runs have to be performed before the final operation can take place.
Please note: This takes place on database level and has to be done carefully! It is recommended to back up the database first!
== Steps ==
In order to remove
* bibliographic records and/or
* items and/or
* authorities and/or
* borrowers and/or
* current user sessions and/or
* zebraqueue
=== Login to database ===
 sudo su
 mysql -u root
 use your_koha_library;
=== Execute the following commands ===
 SET FOREIGN_KEY_CHECKS=0;
Make sure to set this back from 0 to 1 after truncating all or your particular choice of the tables!
* Biblios and items
 TRUNCATE items; 
 TRUNCATE deleteditems;
 TRUNCATE biblioitems; 
 TRUNCATE biblio; 
 TRUNCATE deletedbiblioitems; 
 TRUNCATE deletedbiblio; 
 TRUNCATE biblio_metadata;
 TRUNCATE deletedbiblio_metadata;
* Authorities
 TRUNCATE auth_header;
* Borrowers
 TRUNCATE borrowers; 
 TRUNCATE deletedborrowers;
* Sessions and queue for zebra indexing
 TRUNCATE sessions;
 TRUNCATE zebraqueue;
* Must be done after any of the TRUNCATE commands
 SET FOREIGN_KEY_CHECKS=1;
In some cases the TRUNCATE commands e.g. for items and biblioitems have to be carried out more than once to really empty the table. The result can be checked by 
 select count(*) from table;
e.g.:
 select count(*) from biblioitems;
--> result must be 0
=== Reset Zebra index ===
 zebraidx -c /etc/koha/sites/your_koha_library/zebra-authorities-dom.cfg -g iso2709 -d authorities init
 zebraidx -c /etc/koha/sites/your_koha_library/zebra-biblios-dom.cfg -g iso2709 -d biblios init
== References ==
* https://kohageek.blogspot.com/2017/12/delete-records-in-koha.html
* http://koha.1045719.n5.nabble.com/Step-by-Step-process-to-delete-records-td5761474.html
* http://manual.koha-community.org/3.12/en/resetkohadb.html
* Database tables used in Koha
Category:Tips & Tricks
How to install missing Perl modules on Debian

See Debian for information about Debian packages of Koha and its dependencies.
* Use aptitude to see if a prepackaged version exists
** if the module name is Foo::Bar the packaged version will be called libfoo-bar-perl
** so do 'aptitude search libfoo-bar-perl'
** or just 'aptitude search foo-bar'
* Alternatively, install apt-file and use that:
** To install and set up:
*** apt-get install apt-file
*** apt-file update
** To search: apt-file search Foo/Bar.pm
** This is more handy if you get an error giving an explicit filename that Perl can't find.
** It is also a bit more reliable than the aptitude way for searching, since it does assume package names follow a pattern, or package descriptions contain the Perl module name.
* if found, use apt-get to install it
** 'sudo apt-get install libfoo-bar-perl'
* if not found, install from CPAN
** 'sudo dh-make-perl –install –cpan Foo::Bar'
* if that doesn't work for some reason
** 'sudo cpan Foo::Bar'
Category:Documentation
Category:Installation
How was my Koha installed

So you inhereted a server running Koha, and now you want to upgrade it? Good! The first thing you need to figure out is how Koha was installed on that server, as the details of the upgrade will depend on how it was done. This page intends to 
# help you figure out how the install was done
# point you to the correct upgrade instructions for your installation method
Please note! This page is a work in progress and needs input from more people! 
==Packages==
===Diagnostics===
Try to run this command:
 sudo koha-list
If you get a list of one or more instance names like this, you have a package installation:
 $ sudo koha-list
 koha
If instead you get an error like this, you do not have a package installation:
 $ sudo koha-list
 sudo: koha-list: command not found
Please proceed to check if you have a tarball or Git installation. You can try this script, you will have to change /path/to/koha-conf.xml to the actual path on your system. [TODO: automatize in the script :)]
 kohapath=$(sudo xmlstarlet sel -t -v 'yazgfs/config/intranetdir' /path/to/koha-conf.xml); if [ -d $kohapath/.git ]; then echo "Looks like a git installation."; else echo "Looks like a tarball installation.";fi
===Upgrade instructions===
See: Koha on ubuntu - packages -- Upgrade Instructions
==Tarball==
===Diagnostics===
===Upgrade instructions===
See the appropriate INSTALL.* file that comes with Koha.
==Git==
===Diagnostics===
===Upgrade instructions===
See the appropriate INSTALL.* file that comes with Koha.
==Converting to a package installation==
Package-installations running on Debian or Ubuntu are currently the recommended installation method for Koha. If you have a tarball or Git installation you might want to convert it to a package installation at the same time you do the upgrade. See Moving an installation from a regular install to the Debian packages for details on this.
Category:Installation
Category:Debian_Packages
Category:Installation_alternatives
Htp-to-tt-conversion

There may be a need for people to convert a template to template::toolkit so they can send a patch that will apply cleanly.
To do so checkout a branch based on commit
d4cd05126da3accef83144d8322fcd455d7eba9b
eg
 git checkout -b convert_templates d4cd05126da3accef83144d8322fcd455d7eba9b
Now you have a branch with both sets of templates, you can then
cherry-pick your template change over.
And run 
 ./installer/html-template-to-template-toolkit.pl --koharoot /path/to/the/root
This will convert all the templates, if you want to just convert 1 use -f eg
 ./installer/html-template-to-template-toolkit.pl --koharoot /path/to/the/root -f koha-tmpl/opac-tmpl/prog/en/modules/ilsdi.tmpl
So for me
 ./installer/html-template-to-template-toolkit.pl -c --koharoot 
 /home/chrisc/git/koha/ -f koha-tmpl/opac-tmpl/prog/en/modules/ilsdi.tmpl
Then that file will be in the koha-tt dir and you will now have a
converted file.
Category:Obsolete
Htp to tt conversion

There may be a need for people to convert a template to template::toolkit so they can send a patch that will apply cleanly.
To do so checkout a branch based on commit
d4cd05126da3accef83144d8322fcd455d7eba9b
eg
 git checkout -b convert_templates d4cd05126da3accef83144d8322fcd455d7eba9b
Now you have a branch with both sets of templates, you can then
cherry-pick your template change over.
And run 
 ./installer/html-template-to-template-toolkit.pl --koharoot /path/to/the/root
This will convert all the templates, if you want to just convert 1 use -f eg
 ./installer/html-template-to-template-toolkit.pl --koharoot /path/to/the/root -f koha-tmpl/opac-tmpl/prog/en/modules/ilsdi.tmpl
So for me
 ./installer/html-template-to-template-toolkit.pl -c --koharoot 
 /home/chrisc/git/koha/ -f koha-tmpl/opac-tmpl/prog/en/modules/ilsdi.tmpl
Then that file will be in the koha-tt dir and you will now have a
converted file.
Category:Development
ICU chains configuration

==Overview==
To get searching with non-latin languages (such as Russian, Chinese and Arabic) working correctly in Koha you need to setup and configure ICU (International Components for Unicode) chains.
==Install and configure ICU chains==
To enable and configure ICU:
1. Install the yaz-icu package:
 sudo apt-get install yaz-icu
2. In the staff interface go to More > Administration > Global system preferences > Searching. 
3. Change the UseICUStyleQuotes system preference to Using.
4. Change the QueryFuzzy system preference to Don't try.
5. Change the QueryStemming system preference to Don't try.
6. Edit /etc/koha/zebradb/etc/default.idx
 Change or add the bolded lines:
 
 # Traditional word index
 # Used if completenss is 'incomplete field' (@attr 6=1) and
 # structure is word/phrase/word-list/free-form-text/document-text
 index w
 completeness 0
 position 1
 alwaysmatches 1
 firstinfield 1
 icuchain words-icu.xml
 
 # Phrase index
 # Used if completeness is 'complete {sub}field' (@attr 6=2, @attr 6=1)
 # and structure is word/phrase/word-list/free-form-text/document-text
 index p
 completeness 1
 firstinfield 1
 icuchain phrases-icu.xml 
If the Koha instance is on a shared server and you only want to use ICU for this particular instance, this functionality was added in 
7. Depending on the language you are searching, you may need to modify words-icu.xml or phrases-icu.xml - these are in the same directory as /etc/koha/zebradb/etc/default.idx. The ICU Chains Library covers the modifications required for several languages - you are encouraged to add more.
8. Restart Zebra and rebuild the search index.
 If you are using packages (the recommended way to install Koha), run:
 
 sudo koha-zebra --restart {yourinstancename}
 sudo koha-rebuild-zebra -f {yourinstancename}
 If you are using a git or tarball installation (not recommended for normal use) run these two commands (you will need to change the file paths to where they are on your system):
 
 /etc/init.d/koha-zebra-daemon restart
 /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -w 
 
 You may have to run these commands first: 
 
 sudo bash
 export PERL5LIB=/usr/share/koha/lib
 export KOHA_CONF=/etc/koha/sites/iesh/koha-conf.xml
Category:i18n
Category:Translation
Category:Documentation
Category:Installation
Category:Zebra
ICU do not undiacritic

This page explains how to configure Zebra search engine, with ICU option, to not undiacritic some characters.
== How to ==
Goto Zebra configuration directory : etc/zebradb. 
Edit etc/words-icu.xml (and etc/phrases-icu.xml if exists).
This line defines the action of separating the diacritic and the letter (for example "ê" => "^e") :
<transform rule="NFD"/>
 
You can configure some characters not being undiacritic.
For example "å" :
<transform rule="[^å] NFD"/>
Reindex full.
Then searching with a will not match strings with å and searching with å will not match strings with a.
----
See also Correcting_Search_of_Polish_records and ICU_chains_configuration
Category:Translation
Category:Documentation
Category:Installation
Category:Zebra
ILS-DI

ILS-DI is self-documenting, so in an installation where it is enabled, you can get some information about it at the URL:
 http://koha-opac.example.org/cgi-bin/koha/ilsdi.pl
Because ILS-DI gives access to all your data (items, patrons...), it should be restricted by allowing IP in the admin interface and/or by disabling services via the server. 
For Apache, these rules can be added to restrict public access only to the first and second levels of ILS-DI:
 <IfModule mod_rewrite.c>
 # Rewrite Rules
 RewriteEngine On
 # Restricted ILS-DI Access
 RewriteCond %{QUERY_STRING} !(^($|(\??|(.*&))service=(Describe|GetAvailability|GetRecords|GetAuthorityRecords|AuthenticatePatron|HoldTitle)))
 RewriteRule ^/cgi-bin/koha/ilsdi\.pl$ - [R=403,L]
 </IfModule>
Because an IP can be easily spoofed, the second way is recommended.
Note: If you ever experience a 403 error when issuing an ILS-DI query, check the "service" parameter being passed against the list in the Apache snippet above, it may be that the method in the request isn't allowlisted in the Apache snippet.
Category:Documentation
Identity Provider Setup with ADFS

Category:Authentication
Example Setup of Identity Provider using OIDC via ADFS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Example setup of creating an Identity Provider (ADFS) using OIDC within Koha Administration. This setup is bare-bones and only allows for authentication through ADFS for OPAC / Staff Interface.
- Open ADFS Management Console, Select Application Groups, and choose to 'Add Application Group...'
- Give the new application group a name and optionally a description, then under Template: choose 'Server Application'
- Click next and copy the client identifier to a notepad for later
- Under Redirect URI, enter the OPAC URL and Staff Access URL (Ex: https://library.example.com and https://library-intra.example.com)
- Click next, and on the Application Credentials Screen, choose the Generate a Shared Secret checkbox and copy to the notepad the generated secret
- Double check all items on the summary screen and then click next again, and then close
Now, login as an Administrator to the Staff Interface, Go to Administration > Identity Providers, and choose to add a New Identity Provider
- Enter an Identification Code (EX: ADFS), and then a description that will be shown to end-users (EX: Domain Credentials or Network User)
- For protocol, choose from the dropdown 'OIDC'
- Under Advanced Configuration, choose the 'Add default OIDC configuration' and in the text box enter the client ID in the specified field, Shared Secret in the Client Secret Field, and for "well_known_url" enter the ADFS OIDC Endpoint (It should be enabled on the ADFS Management Console, EX: https://adfs.example.com/adfs/.well-known/openid-configuration)
- Next under Mapping, choose 'Add default OIDC mapping' but in my test case then needed to change the email mapping from "email":"email" to "email":"upn" (But based on your Active Directory Config may need to mess with these mappings)
- For Matchpoint, choose Email
- Now under Domain Configuration, for Domain in this case I put in * to allow all to login via ADFS, then the rest of the options here should be self-explanatory, just ensure for user logins you enable Allow OPAC and Allow Staff.
- In this example though, I turned Auto-Register & Update on Login both to No, since although the Email/UPN is passed during authentication, the users First Name and Surname are not even after changing the fields (Again you may need to fiddle with this as well)
- Now click submit, the Identity Provider will be added and you will be required to restart/reboot your Koha Instance to get it to initalize correctly.
(This is bare-bones documentation on setup)
Illrequests endpoint RFC

This RFC is a proposal to make some changes to this endpoint, to match the generally accepted criteria. No bug report has been filled for implementing it.
== Actions and routes ==
The following table presents the current implementation, and the proposed changes.
Description 	Action	Current path 	Proposed path
List ILL requests 	GET 	/illrequests 	/ill_requests
Add ILL request 	POST 	NOT IMPLEMENTED	/ill_requests
Get an ILL request 	GET 	NOT IMPLEMENTED	/ill_requests/{ill_request_id}
Overwrite an ILL request 	PUT 	NOT IMPLEMENTED	/ill_requests/{ill_request_id}
Cancel an ILL request 	DELETE	NOT IMPLEMENTED	/ill_requests/{ill_request_id}
Partially update an ILL request	PATCH 	NOT IMPLEMENTED	/ill_requests/{ill_request_id}
== ILL request object definition ==
DB schema 	Current API 	josef_moravec
illrequest_id 	illrequest_id 	ill_request_id
borrowernumber	borrowernumber	patron_id
biblio_id 	biblio_id 	
branchcode 	branchcode 	library_id
status 	status 	
placed 	placed 	date_placed
replied 	replied 	date_replied
updated 	updated 	timestamp
completed 	completed 	date_completed
medium 	medium 	
accessurl 	accessurl 	access_url
cost 	cost 	
notesopac 	notesopac 	opac_notes
notesstaff 	notesstaff 	staff_notes
orderid 	orderid 	order_id
backend 	backend 	
=== Discussion ===
+1 --Kfischer 17:05, 2 November 2019 (EDT)
Category:RFCs
Import/Export All System Preferences RFC

== Import/Export All System Preferences ==
For 3.2, Howard County Library would like to propose adding the option to allow system administrators to import and export all system preferences.
=== Benefits ===
* Allows system administrators to easily backup and restore configurations without needing to know SQL
* Easily moving from one Koha installation to the next
* Allows the community to easily share and troubleshoot each others configurations
=== Technical Notes ===
* Two links would be added under Koha Administration, one for exporting and one for importing system preferences
* System preferences would be exported in multiple XML files (global_system_preferences.xml, libraries.xml, funds.xml, etc...) or downloaded as one zip file containing several xml files. Storing these preferences as XML files would also make them easy to read and understand.
Category:Abandoned_RFC
Import MARC to Koha

There are few different ways in which you can import MARC record in Koha.
== marcbulkimport ==
Simplest is from http://perldoc.koha-community.org/misc/migration_tools/bulkmarcimport.html which enables you to import MARC file from command-line.
== Incremental MARC import ==
Some of the time, you need to push new MARC records into Koha one-by-one. Example of such requirement is synchronization of your catalogue with external information source like digital archive.
Basically, you want users to enter data somewhere else, and let that system push MARC records into Koha for search and display with optional link back to master data in 856$u
== /svc/ HTTP API ==
Another way is to import records in MARCXML format which specification can be found at http://www.loc.gov/standards/marcxml/ using Koha /svc/ HTTP API exposed under Koha internet URL.
Category:Obsolete
Import batch profiles endpoint RFC

== Bugs ==
* Ability to create 'matching profiles' when importing records (Failed QA)
== Actions and routes ==
General proposed routes. 
Description 	Action	Proposed path
List import batch profiles 	GET 	/import_batch_profiles
Create an import batch profile 	POST 	/import_batch_profiles
Overwrite an import batch profile	PUT 	/import_batch_profiles/{profile_id}
Delete an import batch profile 	DELETE	/import_batch_profiles/{profile_id}
== Import batch profile object definition ==
DB schema 	Proposed API 	Details
id 	id_profile 	Internal profile identifier
name 	name 	name of this profile
matcher_id 	matcher_id 	the id of the match rule used (matchpoints.matcher_id)
template_id 	template_id 	the id of the marc modification template
overlay_action	overlay_action	how to handle duplicate records
nomatch_action	nomatch_action	how to handle records where no match is found
item_action 	item_action 	what to do with item records
parse_items 	parse_items 	should items be parsed
record_type 	record_type 	type of record in the batch
encoding 	encoding 	file encoding
format 	format 	marc format
comments 	comments 	any comments added when the file was uploaded}
Category:RFCs