nyuuzyou/wikis huggingface dataset:
Community Handover IRC Meeting, 6 April 2010

==Place==
#koha IRC channel (IRC server irc.katipo.co.nz). 
If you are behind a firewall that restricts IRC access -OR- prefer to use a web interface to access the channel, you may use one of the following links:
http://www.mibbit.com/chat/?server=irc.katipo.co.nz&channel=%23koha
==Time==
Tuesday, 6 April 2010 at 19:00 UTC+0 
Conversions to your local time:
* date -d @1270580400 on any GNU system.
* Time and Date.com converter for various local times.
* Wolfram time converter.
==Agenda==
* Welcomes and introductions.
* Report on Subcommittee 
* Report on status of negotiations over assignment of trademarks and domains.
* Possible suggestions on unresolved negotiations.
* Next issues if negotiations have concluded.
* Agree time of next meeting.
== Attendees ==
Apologies: Joann Ransom, Horowhenua Library Trust. (if I make it at all, it will be very late like 8.20am NZ time) 
Attendees to be listed
== Notes ==
to appear
==Transcript==
Log is available at http://stats.workbuffer.org/irclog/koha/2010-04-06#i_419565
Category:Community_Handover_Meetings
Config smtp servers endpoint RFC

== Actions and routes ==
The following table presents the proposed implementation. Work is done on 
Description 	Action	Proposed
List SMTP servers 	GET 	/config/smtp_servers
Add an SMTP server 	POST 	/config/smtp_servers
Get an SMTP server 	GET 	/config/smtp_servers/{smtp_server_id}
Overwrite an SMTP server 	PUT 	/config/smtp_servers/{smtp_server_id}
Delete an SMTP server 	DELETE	/config/smtp_servers/{smtp_server_id}
Partially update an SMTP server	PATCH 	/config/smtp_servers/{smtp_server_id}
== Object definition ==
DB schema 	API 	Description
id 	smtp_server_id	Internal smtp server identifier
name 	name 	Name of the SMTP server
library_id	library_id 	Internal identifier for the library the SMTP server is defined for
host 	host 	The SMTP host name
port 	port 	The SMTP port
timeout 	timeout 	Configured timeout (in seconds) for SMTP connections
ssl 	ssl 	If SSL/TLS should be used (boolean)
user_name 	user_name 	User name for login
password 	password 	Password to be used for login
Category:RFCs
Configure Z39.50/SRU targets

See Koha Open Z39.50 Sources for Koha libraries that have shared their Z39.50 information.
== BNF (Bibliothèque nationale de France) ==
Z39.50
National Library of France
(only tested with UNIMARC)
* Hostname: z3950.bnf.fr
* Port: 2211
* Database: TOUT-ANA1-UTF8
* Userid: Z3950
* Password: Z3950_BNF
* Syntax: UNIMARC
* Encoding: utf8
== Deutsche Nationalbibliothek (DNB) ==
SRU
(Working 16 September 2024)
* Hostname: https://services.dnb.de
* Port: 443
* Database: sru/dnb
* Syntax: MARC21/USMARC
* Encoding: utf8
* Record type: Bibliographic
* Additional SRU options: sru=get,sru_version=1.1,extraArgs=recordSchema=MARC21-xml
* SRU Search fields mapping:
** Title: dnb.tit
** ISBN: dnb.num
** Control number: dnb.idn
** Any: dnb.woe
** Author: dnb.atr
** ISSN: dnb.num
** Subject: dnb.sw
** Dewey: dnb.ddc
** Standard ID: dnb.idn
Documentation: DNB SRU, DNB SRU EN
== K10plus ==
* host: "sru.k10plus.de"
* port: 80
* db: "opac-de-627"
* servername: "K10plus"
* checked: 1
* rank: 1
* syntax: USMARC
* servertype: sru
* encoding: utf8
* recordtype: biblio
* sru_fields: "title=pica.tit,isbn=pica.isb,lccall=pica.lcn,controlnumber=pica.ppn,srchany=pica.all,author=pica.per,issn=pica.iss,subject=pica.sw,dewey=pica.ddc,stdid=pica.num"
Documentation: (only in German :(
Content management RFC

=Summary =
Koha's content blocks are currently dispersed throughout the system in preferences, News blocks and elsewhere. We should have a unified area for managing this content.
== Content management areas==
=== Blocks ===
A page allowing the management of content blocks (OpacNav, OpacNavBottom, etc)
=== Pages ===
A page allowing the management of content pages
=== News ===
A page for the management of articles/news items for publication.
Category:RFCs
Contextual Preferences RFC

= The problem =
The circulation matrix has a column for each kind of rule it keeps track of; this makes adding to the matrix cumbersome and unsustainable. 
System preferences are global, yet many of them should be configurable on a per branch or per patron type level. 
= The solution =
A new table, let's call it contextualpreferences, that can house circulation rules and other kinds of preferences in a key-value based setup. This is infinitely extensible, and makes individual circ rules more granular (a universal hold limit can be set in just one row, instead in a column of every rule in the matrix). 
== Data structure ==
 contextualpreferences data types summary 
Column name 	Data Type 	Allow NULL?	Key?
branchcode 	VARCHAR(10)	yes 	FK to branches
categorycode 	VARCHAR(10)	yes 	FK to categories
itemtype 	VARCHAR(10)	yes 	FK to itemtypes
preference 	VARCHAR(64)	no 	
value 	text 	yes 	
preferencetype	VARCHAR(64)	yes 	
PRIMARY KEY:  (branchcode, categorycode, itemtype, preference) 
== Preference selection ==
NULL values in branchcode, categorycode, and itemtype are the DEFAULT values, and are selected (in the order currently determined by the circulation matrix) most specific to least specific.  NULL/NULL/NULL is the global default combination for any given preference, and should exist in the database for any required values -- test for this
= Implementation Plan =
#build new data table and it's accessor module
#build new administration pages
#migrate in values, replacing old code accessors with new ones
#document, document, document
Category:Architecture,_internals,_and_plumbing_RFCs
Category:Database_RFCs
Cookbook meeting 12 march 2021

= Time =
* 12 march 2021, 14:30 UTC Time and Date.com converter for various local times
= Agenda =
* Introductions
* Review of action point
** caroline will create a template using restructuredtext for the contributions (done, see https://gitlab.com/koha-community/koha-cookbook/-/blob/master/recipetemplate.rst)
** Joubu or ashimema will set up the git repository and the sphinx part (done, see https://gitlab.com/koha-community/koha-cookbook)
** Joubu will create the email address kohacookbook@protonmail.com (done -- it is with an underscore koha_cookbook)
* Project update
** Git is set up
** Recipe template is ready for comments -- comments? suggestions?
** Email inbox is empty and ready for submissions!
** Wiki page created https://wiki.koha-community.org/wiki/Koha_cookbook -- comments? suggestions?
** First recipe is in (my test) https://koha-community.gitlab.io/koha-cookbook/index.html
* Next steps
** Send email to the mailing list to request submissions
** ...
* Misc
* Set time of next meeting
= Minutes =
Minutes (html)
Minutes (text)
Log (html)
Log (text)
= Next meeting =
Cookbook meeting 16 april 2021
Category:Koha cookbook
Cookbook meeting 30 april 2021

= Time =
* 16 april 2021, 14:30 UTC Time and Date.com converter for various local times
POSTPONED to 30 april, 2021 13:30 UTC
= Agenda =
* Introductions
* Review of action point
** caroline will search how to create an index in ReStructuredText
** modify the template to add tags/index terms at the end
** each one of us asks our colleagues for submissions to test the process and have more examples when we ask the community at large
** Add submission info to Readme
* Project update
** ..
* Next steps
** Send email to the mailing list to request submissions
** ...
* Misc
* Set time of next meeting
= Minutes =
* Minutes: http://meetings.koha-community.org/2021/cookbook_meeting_30_april_2021.2021-04-30-13.37.html
* Minutes (text): http://meetings.koha-community.org/2021/cookbook_meeting_30_april_2021.2021-04-30-13.37.txt
* Log: http://meetings.koha-community.org/2021/cookbook_meeting_30_april_2021.2021-04-30-13.37.log.html
= Next meeting =
To be advised
= Previous meeting =
Cookbook meeting 12 March 2021
Category:Koha cookbook
Correcting Search of Polish records

This page explains how to configure Zebra search engine to transliterate Polish special characters into a latin form. 
This only works for a Koha installed with ICU option. 
== How to ==
Goto Zebra configuration directory : etc/zebradb. 
Edit etc/words-icu.xml (and etc/phrases-icu.xml if exists).
After root node icu_chain, add :
 <transliterate rule="{ ą > a "/>
 <transliterate rule="{ Ą > a "/>
 <transliterate rule="{ ć > c "/>
 <transliterate rule="{ Ć > c "/>
 <transliterate rule="{ ę > e "/>
 <transliterate rule="{ Ę > e "/>
 <transliterate rule="{ ł > l "/>
 <transliterate rule="{ Ł > l "/>
 <transliterate rule="{ ń > n "/>
 <transliterate rule="{ Ń > n "/>
 <transliterate rule="{ ó > o "/>
 <transliterate rule="{ Ó > o "/>
 <transliterate rule="{ ś > s "/>
 <transliterate rule="{ Ś > s "/>
 <transliterate rule="{ ź > z "/>
 <transliterate rule="{ Ź > z "/>
 <transliterate rule="{ ż > z "/>
 <transliterate rule="{ Ż > z "/>
 
Reindex all database.
== Result ==
You will be able to find records written in latin or polish, using latin or polish search terms.
Example with author "Miłosz Oskar Wladysław de Lubicz". Performing a search with "Milosz" or "Miłosz" will return records containing "Milosz" or "Miłosz".
----
See also Correcting_Search_of_Arabic_records and ICU_chains_configuration
Category:Translation
Category:Documentation
Category:Installation
Category:Zebra
Create item when ordering RFC

==RFC: Create item when ordering==
Items are currently created by Koha when receiving the item, which might be a problem. For instance, if you order 4 copies, it is the record which, for the opac, is "ordered"; once you receive copy #1, the opac doesn't show the record as ordered anymore, even though 3 copies are still pending.
We suggest to have items created earlier in the acquisition process.
On acqui/neworderempty.pl?booksellerid=X&biblionumber=Y, under Accounting Details we would add a part about "Item" with the following informations to fill in:
* home library (+)
* location (+)
* item type (+)
* item note (for example: pls set aside for Dr. Smith)
* call number
* 2 fields (none mandatory) with lists of authorized values (+) -> here we speculate that these 2 fields will be added to a budget; see Refining the budgets hierarchy and informations RFC
(+) means Koha will fill in those fields with the data from the previous item entered: only the first item created during the session will have to be created from scratch.
Upon saving, Koha saves an item with "ORDERED" status
Note that some libraries are happy with item creation upon reveice. some are happy with item creation after cataloguing (AddItem.pl). So a systempreference will be added to decide when the item will be added. It will be either :
* on order
* on recieve
* manual
Category:Acquisitions_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Create your own APT repository

Creating your own apt repository for publishing your packages will probably make life easier for people maintaining Koha installs.
This instructions let you create your own APT repository on the same machine you are building the packages. The repository can be used directly from this server using a HTTP server in front of this files. This repository could also be published in a separate server using rsync.
These instructions are used for building packages for Ubuntu 12.04 LTS in amd64 architecture. Feel free to adjust this to your needs.
Note: there are references to a GPG Key (B2F3C15F), you should create your own and replace with it. ('gpg --gen-key' can be used to create such a key)
===Dependancies===
You'll need the reprepro package installed on your system
apt-get install reprepro
===Create the repository directory structure===
mkdir -p /srv/repositories/koha/{conf,dists,incoming,indices,logs,pool,project,tmp}
===Create the repository's configuration files===
/srv/repositories/koha/conf/distributions
 Origin: Tomás Cohen Arazi
 Label: UNC Koha Repository
 Codename: precise
 Architectures: amd64 i386 source
 Components: main
 Description: UNC's own Koha repository
 SignWith: B2F3C15F
/srv/repositories/koha/conf/options
 ask-passphrase
 basedir .
===Build your own packages===
Go to your git clone and checkout the desired commit/tag you want to build a package for:
cd /srv/build/koha/src
git checkout origin/3.14.x -b custom_3_14_build
Build:
debian/build-git-snapshot -r /srv/build/koha/debs/ -D precise --noautoversion -v "3.14.06-1indexer"
(See also: Building Debian Packages - The Easy Way.)
Sign the packages:
debsign -kB2F3C15F /srv/build/koha/debs/koha_3.14.06-1indexer_amd64.changes
Populate the repository with the new packages:
cd /srv/build/koha/debs/
reprepro -b /srv/repositories/koha/ include precise koha_3.14.06-1indexer_amd64.changes
===Build Perl dependencies===
Build:
mkdir /srv/build/kohaperldeps
cd /srv/build/kohaperldeps
cpan2deb Koha::Contrib::Tamil
Publish:
reprepro -b /srv/repositories/koha/ includedeb precise libkoha-contrib-tamil-perl_0.031-1_all.deb
===Roll the new stuff to the production repository===
cd /srv/repositories/koha
rsync -avl --delete --rsh=ssh . root@ubuntu.unc.edu.ar:/srv/sites/koha
Note: you might as well mount the remote server directory in /srv/repositories/koha to directly work on it. I wouldn't, just in case.
Category:Debian_Packages
Critical circ bugs

=Bugs needing to be fixed pre 3.18 release=
== OPAC ==
===Waiting for RM===
== LDAP ==
===Needs sign-off/Testing===
== TOOLS ==
=== Needs QA ===
===Waiting for RM===
== CIRCULATION ==
===No Patch===
* Ajax checkout table: no "loading..." popup
===Needs sign off===
===Needs QA===
===Failed===
* Regression: List of previous checkouts should be ordered by due date ascending
* Show waiting hold expiration date for waiting holds on circulation.pl
===Waiting for RM===
===Pushed===
* Allow preventing passwords from being stored locally when using LDAP
* Add ability to delay loading of patron's checkouts in circulation and patron details
* Overdue items won't show as overdue in red in circulation
* Regression: Item lost status doesn't show in list of checkouts
* Patron 'Details' and 'Check out' pages not working properly for staff users which don't have renewal override permissions
* local only logins should still work when ldap authentication is enabled
* Holds tab on checkout screen never stops processing
* Holds Waiting: not showing from check out screen
* Row grouping in checkouts table is alphabetical and layout depends on words chosen in translation
* Columns misplaced in moremember.tt
* Checkouts table default ordering is incorrect
* Patron holds table no longer display date item went in transit
* "Today's checkouts" sort improperly because issuedate lacks seconds.
* Export checkout list does not work anymore
* Regression: Circulation checkouts table no longer shows item type description
* "Always show checkouts immediately" cookie should persist across sessions
* letter.code is considered as a primary key - Consequence is that we can't add different notice templates for various branches if the letter code is harcoded (CHECKIN, HOLD, ...)
* Regression: Table of checkouts no longer preselects overdue items for rewewal
* Unnecessary white space above checkouts table in circulation
* Clicking the "show checkouts" button should return focus to the barcode field
* Regression: Patron print summary doesn't show checkouts
* Calendar with weekly repeating holidays completely broken by DataTables upgrade
* Regression: Override renewal limit option broken with AJAX circ
* Can't make new suggestion with AllowPurchaseSuggestionBranchChoice turned on 
* All overdue items with fines returned via checkouts table will have fines forgiven!
* Items disappear from staff detail page when there is an on-site checkout
Category:Bugs
Crowdfunding

== Crowdfunding, the path for big, boring improvements ==
There seems to be general agreement that by now, Koha could do with some big, boring improvements:
* Getting fully ready for persistance, to be able to run under Plack or something similar.
* Move to more object oriented code and perhaps an ORM, like DBIx::Class.
* Extend unit tests coverage.
There is also agreement that no library wilb probably ever be crazy enough to fund something like this. 
But could there be another way, through crowdfunding? "We need to do some boring fixing, if you or your library could contribute $10/$100/$1000 it would really help" sort of thing. 
Is this something worth seriously considering? Would anyone be willing to take on the task of outlining the scope of such a project, quantifying what is needed, receive the money and do the work (or subcontract it out to others)? 
This meeting should probably not say yes/no to the idea, but maybe yes/no to considering it further? --Magnus 14:05, 6 March 2013 (EST)
+1000 for this idea. I already have started something in France, and need help to go further. I also suggest to add this topic to KohaCon13 --Paul Poulain 03:23, 7 March 2013 (EST)
(Paul, continuing) what I've started in France is a document (in french) explaining to libraries what should be done. It contains exactly what you've written. I've sent this document to Kohala NPO. Until now, it had no effect, (and I haven't tried to go further). But I'm convinced the internal work that should be done now to have a Koha ready for the next 10 years will never be done without proper funding. And no single library will ever fund it too.
I'll add that my feeling is that we're speaking of x00 000USR here (with x>1 !) if we want to do all what could/shoud be done.
Category:RFCs
D&L TECH., JSC

D&L TECH., JSC ( D&L Technology Integration And Consulting Joint Stock Company) was incorporated in 2009, building on 4 successful years of work in softwares in libraries in general, and Koha in particular. We now provide a range of services in Vietnam to libraries: we develop,support open source software for libraries and may also help you with migration processes, staff training and software maintenance.
Category:Support_Companies
DBIC discussion overview

= DBIx::Class discussion overview =
The discussion has been launched on the [mailing list]. 
This page will try to list and summarize the different points of view. 
Context: Currently, we have 2 package directories: C4 (legacy) and Koha (the new one, should be OO only). We need to define what is the most adapted to migrate all the current code from C4 to Koha. 
The Koha community needs to reach a consensus on the following questions. 
== Questions ==
=== 1 - Where should we put the code logic? ===
==== a) Koha::Schema::Result::* ====
ex: Koha::Schema::Result::Borrower::is_debarred
*take full advantage of DIBC
*less complicated 
==== b) Koha::* ====
ex: Koha::Borrower::is_debarred
*more consistent
*represent "things", not tables (1+ tables for 1 class).
*scripts don't need to know or care how the data is stored (eg serialised objects in cache, redis etc)
=== 2 - Should we allow find and searches in pl files? ===
==== a) Yes ====
*easier to code
*fixes provided faster
==== b) No ====
*could be unit tested
*easier to maintain
*easier to reuse
=== 3 - How should we manage ResultSet? ===
I dont understand this question, the Koha:: modules will deal with the db (or cache) and if using the DB will deal with the ResultSet
==== a) into Koha::Schema::ResultSet::* ====
==== b) into Koha::*::Set ====
=== 4 - Does Koha::* class should extend Koha::Schema::Result::* ===
==== a) Yes ====
==== b) No ====
* No, it should use it, where it needs to. To deal with the db, but some Koha objects don't need to touch the db directly.
=== 5 - Does Koha::* class should extend Class::Accessor? ===
==== a) Yes ====
* already used into Koha
==== b) No ====
=== 6 - Have a common class Koha::Object and Koha::Object::Set ===
==== a) Yes ====
*reuse some common stuffs 
==== b) No ====
*poor design
* why create heavy objects when we just need light ones?
* why layer a db abstraction over a db abstraction?
Category:Development
DBIC naming conventions

There are 4 rules to DBIC naming:
# All words separated by underscores in both tables and columns
# All table names should be plural
# Primary key is 'id'
# Foreign key is named after the table pointed to, only singular.
You are also highly encouraged not to use abbreviations.
For example, if we changed the aqinvoices table so that it used the DBIC conventions, the original
 
aqinvoices (
 invoiceid , -- ID of the invoice, primary key
 invoicenumber , -- Name of invoice
 booksellerid , -- foreign key to aqbooksellers
 shipmentdate , -- date of shipment
 billingdate , -- date of billing
 closedate , -- invoice close date, NULL means the invoice is open
 shipmentcost , -- shipment cost
 shipmentcost_budgetid , -- foreign key to aqbudgets, link the shipment cost to a budget
)
Note that the constraint for shipmentcost_budgetid shows that it is simply a foreign key on aqbudgets:
 CONSTRAINT aqinvoices_fk_shipmentcost_budgetid FOREIGN KEY (shipmentcost_budgetid) REFERENCES aqbudgets (budget_id) 
Would look like this, using the DBIC naming conventions:
 
invoices (
 id , -- Primary key
 name ,
 bookseller , -- Foreign key for booksellers table
 shipment_date ,
 billing_date ,
 close_date ,
 shipment_cost ,
 budget -- Foreign key for budgets table
)
DBMS configuration

The configuration of you Database Management System (DBMS) may need to be modified, depending on the versions of Koha you are using.
Since Ubuntu 16.04 (and others recent distros) the default configuration of the DBMS became more stricter
Since MySQL 5.7 and MariaDB 10.2.4, the default value for SQL modes is
MySQL: 
 ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
MariaDB:
 NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO
= Since Koha 18.05.00, 17.11.05 or 17.05.11 =
Since Koha 18.05 (17.11.05 and 17.05.11) and bug 20229, it is no longer needed to modify the configuration.
= Prior to Koha 18.05 =
Most of the versions of Koha (3.x, 16.05 to 17.11) are not compatible with this default configuration.
To bypasss the problem you can edit the configuration file (certainly /etc/mysql/my.cnf or /etc/mysql/mysql.conf.d/mysqld.cnf) and force the SQL modes Koha supports:
 [mysqld]
 sql_mode=IGNORE_SPACE,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
After save the changes and restart mysql.
= See also =
bug 17258
MariaDB sql-mode
MySQL sql-mode
DB Documentation for 3.4 Proposal

The role is coordinated with Documentation Manager. Is a role to help developers to keep dev and documentation about tables/index/relation in sync.
This role is connect with my previous work on documentation of MySQL tables, indexes and links between tables. I think we need some one that every time a new table, a new index, a new coloum ask to the developer to describe the new situation.
In fact I ask the moral authority to ask questions about the topic and to request an answer. We can't insert comment od description into .sql file because for 3.4 we want to use an SQL abstraction level. The SQL abstraction level is mandatory to support Koha on MySQL and Postegres.
I will document the information in a xml file, with a specific ad public avaible syntax. The syntax doesn't came from myself but it is the syntax of SchemaSpy.
With this xml will bw possible to create in an automatic way web pages about SQL structure.
Category:3.4
DB Revisions Table

* 3.03.00.005 :Bug 5417 new itemBarcodeInputFilter for libsuite8 style barcodes
* 3.03.00.006 :Bug 5423 Deleted Patrons are no longer saved in table deletedborrowers
* 3.03.00.007 :Bug 5464 Add extra fields to suggestion
* 3.03.00.008 :Bug 1997 New ref OPACNoresults
* 3.03.00.009 :Bug 3381 Add an IntranetUserCSS system preference
* 3.03.00.010 :Bug 5040 "Distance" misspelled in default framework
This page is no longer used for tracking DBversion. Please submit patches with XXX instead of the final three-digit number and let the Release manager assign them. Pages that point to this table probably need updating.
Category:Koha_Versions
Category:3.4