nyuuzyou/wikis huggingface dataset:
UNIMARC

== Known countries where it's the standard for almost all libraries ==
* France
* Portugal
** https://www.enssib.fr/bibliotheque-numerique/documents/48343-unimarc-in-portugal-diaporama.pdf
*** «UNIMARC in Portugal is[...]adopted in almost Portuguese libraries»
*** «teached in all library schools» 
== Known countries where it seems it's the standard for most libraries ==
* Greece
* Italy
== Current status unknown but had a UNIMARC translation in the past ==
In the past doing an UNIMARC translation had to be done outside the translation platform. Translating SQL and then submitting it via bugzilla. So it had to be an explicit work targeted at the language and doing everything in one go.
It's not like today when the strings are in the translation platform for every language. And UNIMARC terms that exist in MARC 21 should are supposed to get copied there automatically. And the (still numerous) unique UNIMARC strings might get translated without being sure that there is actual UNIMARC use. For the sake of having the translation at 100%
* Poland
* Russia
* Ukraine
list source: https://lists.koha-community.org/pipermail/koha-devel/2010-July/034235.html
Ubuntu

= Welcome! =
This is the starting point on the journey of running Koha on Ubuntu. Decisions will need to be made and this will affect how you install or upgrade Koha. Let's begin!
= Ubuntu =
Version 
The oldest supported Ubuntu version is 16.04 LTS. Ubuntu 16.04 includes MySQL 5.7 which defaults to strict mode. And while it can be turned off, this only masks problems that may exist.
Edition 
Ubuntu has various editions but for the purposes of running Koha, the recommendation is for the server edition. The desktop edition will also work, but is not recommended for a production environment.
Upgrade 
If Ubuntu is already running, and it is prior to Ubuntu 16.04 LTS, please upgrade to Ubuntu 16.04 LTS. Running Koha on earlier versions is not supported due to dependency issues.
Download 
Not all computers support 64-bit. Some virtualization tools may only support 32-bit based on the host operating system. Determine which version is required and download it from the Ubuntu download website.
= Koha =
There are currently two ways to install Koha: packages and source compiling.
In a production system it is recommended that you use the packages install method. It will make administrator's life easier in terms of maintainability.
If you prefer to install from sources (because you maintain some personalizations or because you are developing a patch for Koha) you should stick to install from sources. Using either the official tarball packages or using git to pull the latest Koha source code. 
Category:Installation
Update parts of the staff interface to use AJAX RFC

== AJAX in the Staff Interface ==
NOTE: relevant patches are available at http://arwen.metavore.com/~jpw/ajaxcirc/.
Currently, in the svc/ directory and tagging tools, there are some cautious forays into using AJAX. However, many more areas of the staff (and possibly patron) interface could be improved using AJAX and well-structured web services.
Towards this end, LibLime has implemented an AJAX-enabled circulation screen and added click-to-edit for cells of existing values on the smart-rules page, for possible inclusion in 3.2.
Both of these use new web services.
AJAX Circulation uses /svc/checkouts:
* POST /svc/checkouts/ (with data, creates a new checkout)
* POST /svc/checkouts/<issueid> (renews or returns checkouts, based on POSTed data (POST returned=1 > /svc/checkouts/<issueid> returns a checkout, for example)
issueid is a new column on the issues and old_issues table that is a simple auto_increment integer. One feature of this webservice is that renewals and checkins can happen on multiple items at once, by doing, for example, POST /svc/checkouts/64|90|32 (where 64, 90 and 32 are the issues in question). This is perhaps not the REST-approved way to do it, but it was the least complex way of implementing required functionality.
The improved smart-rules page is somewhat simpler; POST key=<column from `issuingrules`>&value=<new value> > /svc/admin/issuingrules/<branch>;<categorycode>;<itemtype> updates a part of an issuing rule.
Both of these services are based on two new modules, C4::Output::JSONStream and C4::Service.
C4::Output::JSONStream implements a simple, HTML::Template-ish way of creating JSON objects:
my $response = new C4::Output::JSONStream;
$response->param( foo => 'blah' );
$response->output() == "{'foo':'blah'}";
C4::Service bundles this and some utility functions, to make creation of JSON-based webservices simple:
my ( $query, $response ) = C4::Service->init( circulation => 1 ) # Required permissions
my ( $borrowernumber ) = C4::Service->require_params( 'borrowernumber' ) # Returns 'borrowernumber' from the query if present, returns 400 Bad Request and an error message if not
C4::Service->return_error( 'impossible', 'too_many', blah => 'boo!' ); # Returns 400 Bad Request, and { 'type': 'impossible', 'error': 'too_many', 'blah': 'boo!' }
 
C4::Service->return_success( $response );
It also has a simple regex-based dispatch mechanism, and support for multiple responses (207 Multi-status).
Category:Abandoned_RFC
Updating borrowers.lastseen

Note: The descriptions below are based on the code in the main branch as of 2018-05-07. 
==Database field and syspref==
In the "borrowers" table, there is a field called "lastseen". The comment for this field reads: 
 last time a patron has been seen (connected at the OPAC or staff interface)
In order to use this field, the syspref "TrackLastPatronActivity" must be switched on. The description for this is:
 [Do|Don't] track last patron activity. Everytime a patron will connect, the borrowers.lastseen will be updated with the current time.
The database field and syspref were introduced in " - When automatically deleting expired borrowers, make sure they didn't log in recently". It looks like the original intent was only to track logins, not circulation events.
==Koha::Patron::track_login()==
This is the subroutine that does the actual update:
 474 =head3 track_login
 475 
 476 $patron->track_login;
 477 $patron->track_login({ force => 1 });
 478 
 479 Tracks a (successful) login attempt.
 480 The preference TrackLastPatronActivity must be enabled. Or you
 481 should pass the force parameter.
 482 
 483 =cut
 484 
 485 sub track_login {
 486 my ( $self, $params ) = @_;
 487 return if
 488 !$params->{force} &&
 489 !C4::Context->preference('TrackLastPatronActivity');
 490 $self->lastseen( dt_from_string() )->store;
 491 }
==Login==
C4::Auth::checkauth() calls Koha::Patron::track_login().
This gets called on every page load.
==SIP2==
===Patron info===
In C4::SIP::Sip::MsgType::handle_patron_info() there is a call to C4::SIP::ILS::Patron::update_lastseen(), which again calls Koha::Patron::track_login(). 
This was added in 18.05: - Update borrower last seen from SIP
==REST API==
Can external services use the REST API for authenticating patrons now? If so, this should also update borrowers.lastseen. 
==ILS-DI==
ILS-DI can be used by third parties to authenticate patrons who want to use external services. This should also update borrowers.lastseen.
==Extend borrowers.lastseen to circ events?==
Libraries wanting to be compliant with GDPR will want to delete patrons who have not been "active" in the last X months, or similar. Being active might mean at least two things:
* Checking out books etc
* Using the library facilities in other ways, like logging into services the library subscribes to
The last part is covered by borrowers.lastseen, both for logging into the OPAC and for logging in to services via SIP2. But if borrowing history is anonymized (which it will surely be for a GDPR-compliant library), a patron could borrow lots of books and not leave a trace of it after anonymization. 
The question then is, would it make sense to extend the use of borrowers.lastseen to also track circ events? If so, we would need to catch events from:
* Circulation in the staff client
* Processing .koc files
* Self Checkout
* Circ actions via SIP2
==Relevant bugs==
* - TrackLastPatronActivity is a performance killer
Category:GDPR
Upgrade jQuery to 1.3.2 RFC

== Upgrade to jQuery 1.3.2 ==
From email sent by John Beppu <john.beppu@liblime.com>:
Currently, Koha uses jQuery 1.2.3. I would like to get it upgraded to the current release which is 1.3.2.
The significant changes that the 1.3 series brings can be found here:
http://docs.jquery.com/Release:jQuery_1.3
The 1.3 series brings many performance improvements and few new features, but a few things had to be deprecated along the way. The one that seems to cause the most problems for upgraders is the of the XPath attribute selector syntax, but luckily, it's also easy to fix.
----
Note by Joe Atzberger:
One important thing will be to check our plugins for 1.3 compatibility. Right now that seems to include:
* ajaxfileupload.js
* jquery.checkboxes.pack.js
* jquery.dimensions-min.js
* jquery.dropshadow-min.js
* jquery.hotkeys.js
* jquery.hoverIntent.minified.js
* jquery.tablesorter.min.js
* jquery.treeview.pack.js
* ui.tabs.js
Category:Abandoned_RFC
Upgrade to AGPL 3 for Koha 3.4 - 150 word advocacy

This page is reserved only for an 150 word summary advocating AGPL 3, invoked with an or later version option, for Koha 3.4. The summary is part of a ballot process for inclusion in a ballot on the question of upgrading the Koha copyright license.
Please use the Upgrade to AGPL 3 for Koha 3.4 - Advocacy wiki page for more detailed advocacy linked from the summary.
Please use the Koha AGPL 3 option wiki page or the Koha mailing list for open comment.
==Upgrade to the GNU Affero General Public License version 3 (AGPL 3), invoked with an or later version option, as the copyright license for Koha 3.4 - advocacy==
==Summary (150 words at most)==
* AGPL 3 text is identical to GPL 3 except for the reciprocal section 13. Thus AGPL 3 has all the advantages included within GPL 3 with a vital addition.
* Section 13 ensures that any user of the software remotely over the network, the typical case for Koha, has the right to download the complete source code for the particular modified version being used. Users avoid vendor lock-in over software.
* Code from other AGPL 3 projects could be used to enhance Koha in addition to the compatibility provided by GPL 3.
* Compliance mistakes are protected by the 30 day cure provision allowing first time violators to have their rights automatically restored. Advice from the Software Freedom Law Center suggests a means for a copyright holder to reinstate the first time protection to reassure a party believed to have innocently violated the license.
See http://wiki.koha-community.org/wiki/Upgrade_to_AGPL_3_for_Koha_3.4_-_Advocacy for more detail.
Category:Koha_copyright_license
Upgrade to GPL 3 for Koha 3.4 - 150 word advocacy

This page is reserved only for an 150 word summary advocating GPL 3, invoked with an or later version option, for Koha 3.4. The summary is part of a ballot process for inclusion in a ballot on the question of upgrading the Koha copyright license.
Please use the Upgrade to GPL 3 for Koha 3.4 - Advocacy wiki page for more detailed advocacy linked from the summary.
Please use the Koha GPL 3 option wiki page or the Koha mailing list for open comment.
==Upgrade to the GNU General Public License version 3 (GPL 3), invoked with an or later version option, as the copyright license for Koha 3.4 - advocacy==
==Summary (150 words at most)==
* A lengthy open, even if imperfect, comment period for multiple drafts before the license was finalised.
* Substantially the same copyleft license as GPL 2 with protection for users over issues identified subsequent to the 1991 publication of GPL 2 and greater clarity of language.
* Greater international legal compatibility for terminology and aspects of software copyright law.
* Greater compatibility with other free software licenses allowing more code from other projects to enhance Koha. Compatibility includes GPL 2, invoked with an or later version option; code from newer projects using GPL 3 and LGPL3; and greater compatibility with other non-GPL free software licenses.
* Attribution rights for contributing authors even when not copyright holders.
* Other protections including greater protection from aggressive use of patents, controlled by modifiers and conveyors of the software, covering some aspect of the software functionality.
* Still upgradable.
See http://wiki.koha-community.org/wiki/Upgrade_to_GPL_3_for_Koha_3.4_-_Advocacy for more detail.
Category:Koha_copyright_license
Use LDAPS RFC

== Allow Koha to use LDAPS as well as LDAP ==
Sponsored by no-one yet and developed by Chris, expected for/deadline: 2010-12-10
See also Bug 5406 - please vote for it there if you want to encourage it. Sponsor/developer status is also tracked on the bug: it should match what is displayed here.
== Description ==
When we are connecting across the internet to LDAP servers, we should be using
LDAPS if at all possible.
I propose adding another variable to the LDAP config and changing
C4::Auth_with_ldap to be able to do LDAP or LDAPS
Net::LDAPS is functionally equivalent to Net::LDAP so will require minimal code
changes.
I propose to use a conditional require so a new mandatory dependency is not added
==Published Code==
No code published yet.
Category:RFCs
Category:Authentication_RFCs
Category:RFCs_not_targeted_at_a_particular_Koha_version
Useful scripts

= Useful scripts =
This page describes some of the useful scripts found in $KOHACLONE/misc
See also Appendix I to the Koha 3.2 manual for information about the cronjobs in $KOHACLONE/misc/cronjobs: http://koha-community.org/documentation/3-2-manual/?ch=a9984
== commit_biblios_file.pl ==
commit_biblios_file.pl: import a batch of staged MARC records into database. 
Use this batch job to complete the import of a batch of MARC records that was staged either by the batch job stage_biblios_file.pl or by the Koha Tools option "Stage MARC Records for Import". 
Parameters: 
 --batch-number <#> number of the record batch
 to import
 --list-batches print a list of record batches
 available to commit
 --help or -h show this message.
 
== link_bibs_to_authorities.pl ==
link_bibs_to_authorities.pl: link headings in bib records to authorities. 
This batch job checks each bib record in the Koha database and attempts to link each of its headings to the matching authority record. (NB: this script is not very reliable -Jcamins) 
Parameters: 
 --verbose print the number of headings changed
 for each bib
 --test only test the authority linking
 and report the results; do not
 change the bib records.
 --help or -h show this message.
== stage_biblios_file.pl ==
stage_biblios_file.pl: stage MARC bib file into reservoir. 
Use this batch job to load a file of MARC bibliographic records (with optional item information) into the Koha reservoir. 
After running this program to stage your file, you can use either the batch job commit_biblios_file.pl or the Koha Tools option "Manage Staged MARC Records" to load the records into the main Koha database. 
Parameters: 
 --file <file_name> name of input MARC bib file
 --match-bibs <match_id> use this option to match bibs
 in the file with bibs already in 
 the database for future overlay.
 If <match_id> isn't defined, a default 
 MARC21 ISBN & title match rule will be applied.
 --add-items use this option to specify that
 item data is embedded in the MARC
 bibs and should be parsed.
 --no-replace overlay action for bib record: default is to 
 replace extant bib with the imported record.
 --comment <comment> optional comment to describe
 the record batch; if the comment
 has spaces in it, surround the
 comment with quotation marks.
 --help or -h show this message.
Category:Documentation
Category:Documentation
Using GitHub Actions to build and release plugins

Using GitHub actions too automate your plugins is easy! 
== Enable GitHub Actions for your plugin ==
#Browse to your GitHub plugin repo on GitHub 
#Click "Settings" ( in the upper right area, it has a gear icon ) 
#Click "Actions" ( in the left sidebar ) 
#Select the option "Enable local and third party Actions for this repository"
== Add unit tests ==
#Copy the basic unit test file to t/00-load.t in the root directory of your plugin's git repository 
#Add more unit tests as needed 
#Add the file to your report using "git add" 
#Commit the addition with "git commit"
== Add the workflow file ==
#Copy the GitHub Actions workflow file to .github/workflows/main.yml in the root directory of your plugin's git repository. 
#Add the file to your report using "git add" 
#Commit the addition with "git commit" 
#Push the change to your main branch with "git push"
== Check your CI run ==
#Browse to your plugin on GitHub 
#Click the "Actions" tab at the top 
#Notice a CI run for the new push, click on it
 
Each workflow will test your plugin against main, stable and oldstable version of Koha. If they all pass, the workflow will build and release your plugin! 
NOTE: This basic unit test only tests if your plugin's Perl module can be loaded. It will fail if, for example, you use a module that no longer exists. It will not catch the use of subroutines that no longer exist without more unit tests.
Category:Plugins
Using Portable Firefox as a Koha Client

Note: For an alternative without separate Firefox installation see Setting_up_slip_printer_to_print_silently
Sometimes it is necessary to have a separate install of Firefox for the purposes of receipt printing. When configured to print silently and automatically, normal, "installed" Firefox doesn't allow you to change the target printer: everything goes to the receipt printer. This annoys some people.
To get around this, one can use Portable Firefox as a duplicate, "Koha only" browser, leaving your normal, "installed" Firefox in a state where it can have completely separate bookmarks, it's full printing faculties intact, and a different home page.
Here is how to set it up:
Download and configure portable Firefox (before the first run)
# Download Portable Firefox
# "Install" it, make sure to note where the folder is installed, pick somewhere visible if you can (say, the Desktop)
# Edit the file "FirefoxPortable.ini" file in the Portable Firefox folder. You will without fail want to add the following (to allow multiple instances of Firefox to run -- this way you can run your locally installed Firefox and your Portable Firefox side by side):
 AllowMultipleInstances=true
The entire contents of the FirefoxPortable.ini we have used is as follows:
 [FirefoxPortable]
 FirefoxDirectory=App\firefox
 ProfileDirectory=Data\profile
 SettingsDirectory=Data\settings
 PluginsDirectory=Data\plugins
 FirefoxExecutable=firefox.exe 
 AdditionalParameters=
 LocalHomepage=
 DisableSplashScreen=true
 AllowMultipleInstances=true
 DisableIntelligentStart=false
 SkipCompregFix=false
 RunLocally=false
Configure Portable Firefox
# Fire up portable Firefox, set the home page and bookmarks to your liking. We like to add links to our project website, our web chat help client, bookmarks to commonly used Koha pages (cataloging, circulation). They are all separate from your normally installed Firefox.
# Configure the receipt printer in Portable Firefox. You can follow the instructions at Configure Automatic Receipt Printing, but in this case *we don't care that it restricts the printers* because it only affects Portable Firefox. Nice!
# Zip up the folder and unzip in the location of your choice on any computer you want to have your newly forged Koha Client Portable Firefox on.
You may be concerned about keeping your Portable Firefox up to date: It's no harder than keeping regular Firefox up to date -- just use the built in updating utility like you would with regular Firefox. (I add this because I thought at first that I would have to build and deploy an all new package every time a new version came out. Thankfully, that turned out to be untrue.)
Category:Tips_&_Tricks
Using Travis CI to build and release plugins

=  Building and deploying plugins using Travis CI =
Using Travis CI to automate your plugins is easy! Follow these steps: 
#You will need to copy the following files from the Kitchen Sink plugin, if you are using the Kitchen Sink as the base for your plugin, proceed to step 2!	 
##.travis.yml 
##deploy.sh 
##gulpfile.js 
##increment_version.js 
##package-lock.json 
##package.json 
#Edit those files and replace all references to the Kitchen Sink plugin and GitHub repository with your own 
#Set the current and previous version in package.json to the version set in your plugin pm file. 
#In your pm file 
##Replace the actual version with "{VERSION}", like so: our $VERSION = "{VERSION}"; 
##Change the date_updated to "1900-01-01", like so: date_updated => "1900-01-01", 
#Commit the new files and changes to your module file, but don't push to your GitHub repo just yet 
#Browse to https://github.com/settings/tokens and create a new GitHub token with the scope of 'repo' 
##Save the resultant token for later in these instructions 
#Browse to https://travis-ci.org/ and connect your GitHub account to Travis CI 
#In Travis CI 
##Locate the "Search all repositories" search box in the upper left, type in the name of your Github Repo 
##Choose to "Activate repository" for Travis CI 
##Once, activated, choose "Settings" under "More options" in the upper right 
###Turn on "Build only if .travis.yml is present" 
###Create a new environment variable named "GITHUB_TOKEN" 
###Paste the GitHub token value into the "Value" field 
###Ensure "Display value in build log" is off. It should be off by default 
###Click the 'Add' button to save the environment variable
#Push the new commit you made in your plugin to your GitHub repo 
#Wait a bit, within a minute or so you should see a build kick off on https://travis-ci.org/ 
#Once it has completed, check the releases page for your plugin on GitHub, you should now see a shiny new release!
If at any time, you want to push a commit to your repo without trigging a new release, just follow the instructions here: https://docs.travis-ci.com/user/customizing-the-build/#Skipping-a-build
Category:Plugins
Using Travis CI to build and release simple plugins

= Building and deploying simple plugins using Travis CI =
There's a generic build mechanism described in another guide. This guide only works for REST API plugins and other plugins that don't serve static files to the user.
This mechanism uses the [CI built-in GitHub release system].
# Browse to https://travis-ci.org/ and connect your GitHub account to Travis CI.
# Set up Travis releases using the command line [client]: `travis setup releases`
## This will create a .travis.yml with an encrypted secret. Copy the file to a safe place.
# You will need to copy the following files from the REST DI plugin (replace .travis.yml created by the above step with this version):
## .travis.yml 
## build.sh 
# Edit .travis.yml and change the secret to your own (from the file created by `travis setup releases`).
# Edit build.sh and change PM_FILE and RELEASE_FILE to those matching your plugin.
# In your pm file:
## Replace the actual version with "{VERSION}", like so: our $VERSION = "{VERSION}"; 
## Change the date_updated to "1900-01-01", like so: date_updated => "1900-01-01", 
# Commit the new files and changes to your module file.
# Tag the latest commit with a version tag such as v1.0.0: `git tag -a v1.0.0 -m "Release v1.0.0"`
# Push the commits and tags to GitHub (adjust as necessary): `git push --tags origin main`
# Wait a bit, within a minute or so you should see a build kick off on https://travis-ci.org/ 
# Once it has completed, check the releases page for your plugin on GitHub, you should now see a shiny new release!
Note that by default only the main branch is released. Adjust .travis.yml as necessary.
Any commit that isn't tagged will be built but not released. Thus it's safe to commit and push changes without accidentally creating a release.
Category:Plugins