nyuuzyou/wikis huggingface dataset:
Documentation meeting 6 June 2023

=== Place ===
Jitsi Meet - meeting link
* We are using an (open source) video conference platform instead of the #koha IRC channel for this meeting. You don't have to turn your camera on if you prefer not to be seen; but if you are able to use a mic it should make our conversations a lot easier!
* To join the meeting, click on the meeting link. If you are on a desktop computer, it will open in a browser window; no need to install anything. To join on a mobile device, you will need to download the Jitsi Meet app (from Google Play; from Apple Store). Do let us know in the #koha IRC channel if you are having any trouble joining.
=== Time ===
* 6 June 2023, 14:00 UTC Time and Date.com converter for various local times
== Agenda with notes from the meeting ==
=== Attending ===
* Marie-Luce Laflamme, inlibro, Québec, Canada
* Aude Charillon, PTFS Europe, UK
=== Apologies ===
Please list your name here if you would like to attend, but cannot make this meeting
* Caroline
=== Updates ===
* Review of action points
Everything from 9 May meeting was actioned.
* What the team has been working on
** Congratulations to Marie-Luce on her first contribution to the Koha Manual!
** Congratulations to Lucy on merging her first request on the Manual!
** Big thanks to Caroline for all her contributions (too numerous to list them all here ^^)
** Aude has replaced screenshots from the 22.11 UI in the ILL chapter.
=== Documentation workflow: issues and ideas ===
*Content development guidelines
** Could the documentation workflow include updating/adding of the 'Help' links to the manual within Koha? See Bug 33790 - Fix and add various links to the manual (Example)
*** This was raised by Katrin, who didn't make it to the meeting. We felt we needed more information from Katrin to understand what she meant.
*** ACTION: Aude to check with Katrin by next meeting.
** Writing values for system preferences - see Bug 29063
*** ACTION: Docs Team to comment.
*** We can discuss this further at the next meeting if needed.
=== Anything else ===
* Hybrid meetings
** Marie-Luce suggested continuing to use Jitsi Meet for the meeting discussion but to also use the Meetbot commands in the IRC channel to help us build minutes automatically.
** ACTION: team to try this for the next meeting.
=== Reminders ===
* Find bugs to document
** Bugzilla search for Keywords=Manual, Component=Documentation
** Bugs marked with Needs documenting status
* Koha Doc automated screenshots
** Meeting organised to get an update from David Nind about his automated screenshots project (Bug 29716), understand whether it would be easy enough for the Docs team to use in the future and see how we can all help him move it forward.
** The meeting has been scheduled for Thursday 29 June 2023 at 11:00 UTC. It will be held on Jitsi Meet.
** Anyone who is in interested in the topic can join directly using the Jitsi Meet link. Do contact Aude if you prefer receiving a calendar invite.
=== Next meeting ===
Wednesday 12 July at 14:00 UTC (meeting page to follow)
Category:Documentation_IRC_Meetings
Category:Documentation_IRC_Meetings_2023
Draft:CSV made with template toolkit

== TODO ==
Fix formatting, many things should be on two lines
== Content ==
There are several things to test when and most of the time we break
something when we try to fix something else.
You have to test different CSV export, not only one. There are not all
processed the same way. For instance acqui/csv/basket.tt does not
contain any strings to translate and the translate script will copy the
original file as it.
But reports/csv/orders_by_budget.tt will not! Indeed it contains "TOTAL"
which will be translated. The generated tt file for the translated
language will remove all the carriage returns! That's why we cannot rely
on TT for newlines (contrary to bug 16914 assumption).
There are two possible methods:
1/ Fix the translate script
=> Hum... nope
2/ Remove all carriage returns and make them explicit by including an
file that only contains 1 carriage return
This second method is implemented in this patch.
How it works: Use the PRE_CHOMP "[%-" and POST_CHOMP "-%]"
(http://www.template-toolkit.org/docs/manual/Config.html#section_PRE_CHOMP_POST_CHOMP)
to remove all the newlines that could be added by TT in the original
(en) files. Then include the new_line.inc to add a new line.
That way original and translated files will behave the same way.
The BLOCK in the csv_headers avoid to have the newlines added, in any
cases. For instance: by default we will have an empty line at the end of
the headers, but the translated headers will not have it.
Test plan:
At least 2 signoffs will be needed, please test carefully!
You will need to generate CSV with at least 2 entries!
Test with the non-translated interface (en) and with the language you
want. To test with a translated language you will *have to*:
- cd misc/translator
- perl translate update LANG
- manually edit the po file, remove the fuzzy tags, correctly translate
the string (do not forget the additional %s in the headers)
- perl translate install LANG
=== Source ===
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19928#c5
Draft:FAQ

== Koha Basics ==
=== What is Koha? ===
----
:Koha is an integrated library system (ILS) and was the first open source ILS. Koha was created in 1999 by Katipo Communications for the Horowhenua Library Trust in New Zealand. The first installation went live in January of 2000.
=== How much does it cost? ===
----
 
:Koha is open source which means it can be downloaded and used without charge and its code can be freely modified.
=== Where can I get Koha? ===
----
:Koha can be downloaded from the official Koha website here.
EAN reading RFC

==== Comment: convert internally to ISBN-13 everywhere? ====
This was sent in (to mjr) by a librarian. I think it is also suggesting standardising internally on ISBN-13.
In most cases the new 13-digit ISBN is directly equivalent to the
13-digit EAN, and many libraries will be routinely adding the 13-digit
number to biblios as part of the ISBN statement (020) or as part of the
OTHER STANDARD IDENTIFIER field (024).
You cannot routinely take an EAN or 13-digit ISBN and convert it to a
10-digit ISBN for searching purposes - some EANs or 13-digit ISBNs have
no 10-digit equivalent. So it makes little sense to try to read an EAN
and convert it to 10 digits for searching purposes, especially since
many books published in the last 4 years have no 10-digit ISBN anyway.
But you can ALWAYS take a 10-digit ISBN and convert it to a 13-digit
number. It would therefore make much more sense to develop a batch routine to examine each and every biblio for a valid ISBN, and to create and add the 13-digit equivalent to the biblio as part of the permanent record, either as an ISBN (020) or as an EAN (024) (and you can use subfield 2 to identify that an EAN is machine-calculated). Then the number is there in the catalogue to be found whenever a barcode number is read.
It would probably be as well to make an on-the-fly conversion routine available as part of the Add MARC Record process too, but much of the processing would be the same.
In a large database, the batch job involves a serious amount of processing, but the conversion task only ever has to be done once per biblio. Converting a scanned EAN for searching purposes has to be done every time a 13-digit number is entered, and over years that could be considerably more processing.
Category:RFCs
Category:Acquisitions_RFCs
Category:Searching_RFCs
ERM

=  Koha Electronic Resources Module (ERM) =
Koha currently has no support for electronic resources management. 
Although an open source project cannot "own" the content distributed by journal providers, we can integrate with third-party knowledgebases and discovery services (such as EDS, Summon etc.). 
There are many advantages of having the electronic information in the same system as the print, including the ability to report across both sets of data.  
The proposal is to create a new ERM module which is broken down into a number of sub-components: - 
*Agreements 
*eHoldings 
*Licences 
*Usage Statistics
== Agreements ==
Agreements describe what you can access (compared to licences, which describe what you can do with them). We will have a number of tables which link together the agreement itself to agreement periods, users, lines, and licences. This consolidates all the information which, historically, was often kept in spreadsheets, filing cabinets etc.! 
== eHoldings ==
Will be able to integrate with a number of knowledgebases, starting with the EBSCO knowledgebase (which can be connected to via their HoldingsIQ tool).  
Other databases can be added after that, popular ones include GOKb (USA/Global), bacon (France) and KB+ (UK) 
We can also add support for KBART files.  
In Koha we (ideally) only want to store titles that are part of our holdings (that is, selected). So, eHoldings module should be able to search the entire KB but flag which titles/packages are held (and therefore in our local db). It should be possible to select both Packages and individual Titles.  
== Licences ==
Will be able to store information about the licence as well as hold licence files themselves (in PDF, DOC etc.). It will be possible to import ONIX-PL files 
== Acquisitions ==
All of the above ties into the acquisitions module by way of the vendor record. In the world of electronic resources, "vendors" is not necessarily a good description as they are really "Organisations" divided into bodies such as "platforms", "consortiums", "vendors", "libraries", "providers", "publishers" etc. Renaming the Koha Acquisitions modules to "Organisations" may be a step too far for now but we can add a search filter to filter out actual print vendors from the rest.  
Ordering of e-resources is done via the current acquisitions ordering processes. 
== Usage Statistics ==
Support for both SUSHI and COUNTER.  
We could potentially integrate with services like EBSCO's Usage Consolidation service 
== Reporting ==
How do we report across e and print holdings? Common questions are about comparing usage of print and e resources. We need a way to link the biblionumber of the print edition to the eresource record in Koha eRM. 
== A-Z Title Index ==
From the information stored above in the eHoldings table it could also be possible to add an OPAC A-Z Journals Listing.  
== Workflow Management ==
This is probably the topic of a larger Koha module that could be applied to modules other than ERM. 
Category:Development
Elasticsearch installation

== Elasticsearch installation ==
We should be working towards ES on by default - meaning all the necessary dependencies are packaged with Koha.
Things mostly work out of the box with Kohadevbox and is the recommended starting point:https://github.com/digibib/kohadevbox
For any installation beyond that I have simply cribbed from the ansible instructions to determine versions/dependencies.
This page is really a stub to give a place to start
For general status: Elasticsearch status
Category:Elasticsearch
Elasticsearch status

== Elasticsearch status ==
This page is really just a goal at an overview of where the Elasticsearch in Koha project stands. Anyone should feel free to edit or update
In general Elastic is functional in Koha - once setup and running you can search your catalog and access titles and indexes are updated as items/titles are added.
There are some differences/issues to be aware of, and in reality we need more users/testers to identify differences and so we can decide which are bugs and which should just be considered a feature of ES.
This page should be for the functionality, for installation/dependencies:
Elasticsearch installation
== Map to 18.05 ==
* Spreadsheet document
== Major bugs ==
=== Known issues ===
* Sorting options work only if sorting is enabled in the mappings - we currently ship a standard list of sorting options- this should be based on the mappings
** - Pushed to 17.11
** - Pushed to 20.11
* Autotruncate needs tuning
** - Pushed to 17.05
* Authorities issues
** - link_bibs_to_authorities.pl doesn't work with Elasticsearch - Pushed to 19.05
** - Elasticsearch: Auth-finder.pl must use search_auth_compat - Pushed to 17.11
** - Elasticsearch - Authority mappings for UNIMARC - Pushed to 17.11
** - Elasticsearch - Update default authority mappings - Puhsed to 18.05
* Default mappings must be set relatable to zebra
** - Pushed to 18.11.04+
* Search keywords in general search aren't processed
** This maybe an advantage, 'not this' doesn't exclude the word 'this', this is a a change. These do work from the advanced search dropdown
* Searching for non-roman characters '食'
* Standardize return of records (sometimes we get MARC::Records and sometimes marcxml)
** - Advanced editor - Rancor - searching broken under Elasticsearch - Pushed to 17.11
=== Enhancements ===
* Relevancy/weighting is different from Zebra - expected but should be customizable
** - Pushed to 18.11
* Mapping configuration doesn't currently allow to add fields
** - Elasticsearch - Ability to add search fields from UI - Patch does not apply
* Add ES config to about page
** - Pushed to 18.05
* Elasticsearch based SRU server
** folded into - Pushed to 19.11
Category:Elasticsearch
Encoding and Character Sets in Koha

=== MySQL ===
At a bare minimum, for MySQL make sure you have the following in the [mysqld] section of your /etc/mysql/my.cnf: 
 init-connect = 'SET NAMES utf8'
 character-set-server=utf8
 collation-server=utf8_general_ci
 character_set_client=utf8
Then restart mysql with: /etc/init.d/mysql restart
See also: MySQL 5.1 Reference Manual :: 9.1 Character Set Support for information about choosing different collations (which will affect how some things are sorted in Koha).
=== Apache ===
For Apache make sure you have these lines in your /etc/apache2/httpd.conf (or for ubuntu in /etc/apache2/conf.d/charset ): 
AddCharset UTF-8 .utf8 
AddDefaultCharset utf-8 
Then restart apache with: /etc/init.d/apache2 restart
=== Locale ===
Your locale should be set to UTF-8. This step is very important for a UNICODE compliant system. 
Run the Locale command and it should show you using UTF-8: 
$ locale
LANG=en_PH.UTF-8
LANGUAGE=
LC_CTYPE="en_PH.UTF-8"
LC_NUMERIC="en_PH.UTF-8"
LC_TIME="en_PH.UTF-8"
LC_COLLATE="en_PH.UTF-8"
LC_MONETARY="en_PH.UTF-8"
LC_MESSAGES="en_PH.UTF-8"
LC_PAPER="en_PH.UTF-8"
LC_NAME="en_PH.UTF-8"
LC_ADDRESS="en_PH.UTF-8"
LC_TELEPHONE="en_PH.UTF-8"
LC_MEASUREMENT="en_PH.UTF-8"
LC_IDENTIFICATION="en_PH.UTF-8"
LC_ALL=
 
If so, there is nothing more to do. 
If it is not set to something UTF-8, determine what locales are installed: 
$ locale -a
 
Select one (note that utf8 becomes UTF-8) and use it: 
$ sudo update-locale LANG=en_US.UTF-8
Log out and log back in to see the locale change reflected when you use the locale command. 
Recheck that your locale ends in UTF-8 now. 
$ locale
Category:Documentation
Category:Installation
Category:Tips_&_Tricks
Enhance Suggestions Workflow RFC

==RFC: enhance suggestions workflow in staff interface==
On the suggestion/acceptorreject.pl page, bellow the pending tab, above each of the columns (Accept / Reject / Delete) we put a tickbox with Accept All / Reject All / Delete All
On the suggestion/acceptorreject.pl page we should filter by suggested by field. We currently provide for ordering only, not filtering. Proposition is that the names of the people who suggested are clickable, which acts as a filter and limits the suggestions to those made by this person.
On suggestion/acceptorreject.pl, “accepted” tab, we should add a dropdown with the list of active budgets in a new column called “propose budget”. Defaults to empty (no budget chosen). When a budget is selected it just puts the budget code in a text field in the suggestion, nothing fancy: we just need this information to allow librarian, in acquisitions, to be able to filter suggestions by proposed budget: see below.
On acqui/newordersuggestion.pl there's a new column in the table entitled “proposed budget”. Proposed budget can be edited the same way we currently edit the “reason”, i.e. title by title or for all titles.
On acqui/newordersuggestion.pl one should be able to sort according to each column, and filter (suggested by / accepted by / proposed budget) just like on suggestion/acceptorreject.pl
When the librarian clicks on “order” she goes to acqui/neworderempty.pl with the Fund field already filled.
Category:Acquisitions_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Enhancements to debarred patron

(Biblibre - sponsored by Université Lyon 3)
In 3.2 when a patron is manually flagged using gonenoaddress, lost or debarred, it's just managed as a toggle choice.
Enhancements proposed are:
* add a comment field to the current 3 choices: e.g. debarred_comment
* change debarred field from tinyint to timestamp: entered through the UI
If timestamp == null, patron has never been debarred
If timestamp >= NOW(), patron is debarred
If timestamp ⇐ NOW(), patron not debarred anymore
Category:Circulation_RFCs
Category:Members/Patrons_RFCs
Category:Koha_3.4_RFCs
Examples of DBIC in Koha

Examples of DBIx::Class (aka DBIC) being used in Koha. Feel free to add more! 
==Pushed to main==
===Where it all started===
 - Add the use of DBIx::Class
===Koha::Schema::Result::Item::effective_itemtype===
Adds a new sub called effective_itemtype to Koha/Schema/Result/Item.pm
Tests in t/db_dependent/Items.t
===circ/renew.pl===
A new "page" circ/renew.pl in the Intranet that only uses DBIC, not DBI. 
===Patron lists===
Scripts in the patron_lists directory do not use DBIC, but the new module in Koha/List/Patron.pm does. 
Tests in t/db_dependent/PatronLists.t.
===admin/z3950servers.pl===
This script was refactored to use DBIC by . 
===Misc===
Smaller bugs that introduce usage of DBIC. 
* - can't set patron privacy by default
==In progress==
=== - Discharge management===
I (Jonathan) tried something on .
=== - Delete biblios on Leader 05 =d===
Uses DBIC to find the biblios that should be deleted.
Category:Development
External Integration

== Integrating Other Software With Koha ==
=== Discovery Software ===
==== VuFind ====
VuFind is discovery software written by Vilanova University. It interacts with the ILS through a driver, which has its own configuration file. The Master branch contains Koha.php, which uses raw access to Koha's database table. The driver is bare bones, and there's a lot of data that shows as 'Unknown'. PTFS-Europe has also created a fork that uses ILSDI in the 'KohaRest' driver. See VuFind KohaRest
=== External notifications ===
==== i-tiva ====
Misspelled itva.
From illion Digital Tech Solutions (formerly Talking Tech)
See syspref TalkingTechItivaPhoneNotification for very basic info
===== testing =====
To test the Koha part, in this case, the notification of a waiting hold.
* enable syspref TalkingTechItivaPhoneNotification
* Tools > Notices & slips => edit the one with code HOLD
* fill the "Phone ( Itiva )" notice
* enable phone notifications for a patron
* place a hold and check-in an item
* run ./misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl --output=/tmp/itiva.csv --type=RESERVE
* the .csv should contain the data to be sent to i-tiva
* these instruction don't go further than that, feel free to complete
=== See also ===
* APIs and protocols supported by Koha: OAI-PMH
* REST api RFCs
* Using the Koha REST API
Integration
Fast Add capability RFC

== Fast add capability ==
(Overlaps with Brief records and record maintenance RFC)
When staff is checking out an item to a customer that does not exist in the database, they need the ability to temporarily create a biblio and item, so that it can be checked out to the customer.
=== Key Features ===
* A template with just a few bib fields that allows a Circulation staff member the ability to add an item and a bib, even if they do not have access to the Cataloging module itself.
* Template should have the ability to have certain default fields in order to allow for faster processing.
Category:Cataloguing_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Final Foundation Vote

== Results ==
258 responses for this survey (159 full responses, 99 responses not completely filled out) 
* Raw results in csv - File:Foundation-pt2.csv.zip
* PDF of charts and results - 
* Another PDF - 
== Call for Participation ==
The final survey is up and should be answered by the 25th of Oct when it will no longer accept answers.
* English: http://opensource.web2learning.net/limesurvey/index.php?sid=88794&lang=en
* French: http://opensource.web2learning.net/limesurvey/index.php?sid=88794&lang=fr
No one used the PDF last time - so if you need a PDF, just ask and I'll generate one.
Thanks
Nicole C. Engard
PS. Please forward around to whoever you think would be interested in having a say.
Category:Koha_Foundation
Fine tuning of circulation policies RFC

In Koha 3.0, “events” that cause a problem in circulation results in, either “issue forbidden” or “issue needs confirmation”. However, the result is hardcoded : for example book being reserved results in “needs confirmation”, and item notforloan results in “issue impossible”. Some libraries want a fine tuning possibilities for all rule.
So, BibLibre plans to add the feature through systempreferences. For each issuing constraint, a system preference will let the library decide wether a confirmation is asked or the issue is forbidden.
Note that some contraint already have such a syspref, like the maxoutstanding.
Category:Circulation_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Fines Tab

More informations will be logged (librarian who made the transaction, dates and hours of the transaction and payment modes).
The fines tab will be redesigned to allow partial payment and to give the informations above.
Payment modes will be recorded in the database so that reports can be done through the report module.
Category:Transaction Logs RFCs
Category:Members/Patrons_RFCs
Category:Koha_3.4_RFCs
Fix recall due date calculation to use relevant checkout

Fix the recall due date calculation to be based on the circulation rule of the relevant checkout borrower and item type, sponsored by Waikato Institute of Technology.
=== Getting started ===
Borrower A, of patron category A.
Borrower B, of patron category A.
Borrower C, of patron category B.
Record A with an Item A, of item type A.
Record B (note, a different record) with an Item B, of item type B.
A circulation rule for patron category A/item type A. Ensure the recall due date interval is 3.
A circulation rule for All/All. Ensure the recall due date interval is 7.
=== Test plan ===
==== Using patron category/item type specific circulation rule ====
#Check out Item A to Borrower A
#Log in to the OPAC as Borrower B
#Place a biblio-level recall on Item A
#Confirm the recalled item is due in 3 days and the due date has been calculated correctly.
#Cancel the recall
#Place an item-level recall on Item A
#Confirm the recalled item is due in 3 days and the due date has been calculated correctly.
==== Unspecified patron category, use All/All circulation rule ====
#Cancel the recall
#Check in Item A
#Check out Item A to Borrower C
#Log in to the OPAC as Borrower B
#Place a biblio-level recall on Item A
#Confirm the recalled item is due in 7 days and the due date has been calculated correctly.
#Cancel the recall
#Place an item-level recall on Item A
#Confirm the recalled item is due in 7 days and the due date has been calculated correctly.
==== Unspecified item type, use All/All circulation rule ====
#Cancel the recall
#Check out Item B to Borrower A
#Log in to the OPAC as Borrower B
#Place a biblio-level recall on Item B
#Confirm the recalled item is due in 7 days and the due date has been calculated correctly.
#Cancel the recall
#Place an item-level recall on Item B
#Confirm the recalled item is due in 7 days and the due date has been calculated correctly.
=== Other links ===
Go back to main recalls page