nyuuzyou/wikis huggingface dataset:
Organizational IRC Meeting, 2006, May 29

== Organizational Meeting Agenda for 2006, May 29 ==
=== News and Questions ===
=== Koha Versioning ===
* As things stand we have three branches:
** rel_2_2 - stable, old-style MARC-in-SQL
** dev-week - rel_2_2 codebase with Zebra support
** head - new codebase, new features, but buggy, partial Zebra support
** hdl_auth - for some authorities improvements. (based on 2_2)
* We need to clarify our expectations about what versions will be released and what they should contain
* status of the different versions.
=== Koha API for '3.0' ===
* Don't use 'dbh' or 'zconn' except in Context.pm - JF
* Object-oriented vs. Functions and Koha - JF
* Only export API Functions in modules - JF
* How to provide full MARC support while keeping non-MARC libraries (like HLT) happy? - JF
** Koha table XML DTD? (use DTDs to generate the editor?)
*** Zebra can search XML of Koha tables with three-tier approach (biblio,biblioitems,items) and MARC/MARCXML of MARC with only a two tier approach ... would this work?
*** here's the start of a Koha table DTD: http://liblime.com/public/koha-tables.dtd
* new Record.pm - for dealing with all record-related manipulations committed to HEAD - JF
=== Perl ZOOM Plugin Status ===
=== MARC::* Suite and Koha ===
Category:Organizational_IRC_Meetings
Output order upon closing the basket RFC

==RFC : Output order upon closing the basket==
Currently, when the basket is closed, Koha doesn't do anything, except that one can now follow the order within acquisition. 
Proposition would be that when one clicks on the "close this basket" link, Koha looks at a system preference and either:
* prints out the order using a template, and providing the following informations:
** a header with the library address and the vendor's address and contact information
** a table with on line per ordered document: order number, short biblio description, price, number of ordered items
** a footer/signature for the library
* a CSV file with: order number, short biblio description, price, number of ordered items
* a mail, sent to book seller
The library's choice of either the printed form, the CSV file or the email would be made by the librarian through radiobuttons.
The vendor's record would have a "preferred order mode" radiobutton choice (csv/mail/print) and Koha would preselect the right radiobutton in the order; the librarian can change the mode on a case by case basis, but it's selected according to the preference in the vendor's record.
Category:Acquisitions_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Overdue fines for bib-level recalls

Ensure overdue fines are detected for biblio-level recalls, sponsored by Waikato Institute of Technology.
=== Getting started ===
Ensure you have 2 borrowers (Borrower A and B, and you have login credentials for Borrower B), and an Item A.
Ensure your circulation rules have the following values (or that the following fields are at least set):
* fine amount = 2
* fine charging interval = 1
* recall due date interval (days) = 0
* recall overdue fine amount = 5
=== Test plan ===
#Check out Item A to Borrower A
#Log in to the OPAC as Borrower B
#Place a biblio-level recall on Item A
#Check Borrower A's checkouts, their checkout should now be overdue
#Check Borrower A's account again the next day. They should now have an accruing fine of $5 (or the amount you set for circ rules recall overdue fine amount) applied to their account.
#Check that fines on normal overdues still apply as normal, for the amount set to circ rules fine amount.
=== Other links ===
Go back to main recalls page
Overdues module rewrite RFC

The current overdues-module is old, fragmented and hard to modify and test.
Most notoriously the overdue_notices.pl with 500 lines of code long nested loop with jump statements.
Also the tools/overduerules.pl has all the CRUD-operations coded into the script, making CRUD operations for overdues very hard to test, or use in other related test cases.
The module needs to be refactored to something more MVC,
and to use the new Koha-features:
Koha::Object, Koha::Cache, DBIx, Cucumber- and Selenium-tests.
I am currently rewriting the module, and it looks like the architecture might stand as follow:
* Koha::Overdues::OverdueRule-object, containing overdueRules (delay, debarred, letterCode, fine, message_transport_types, ...) for each branchcode->borrowerCategory->letterNumber.
* Koha::Overdues::OverdueRulesMap-object, which receives all CRUD-operations for the OverdueRules and also helps in finding the correct OverdueRule for the given scenario, eg. by being given an MessageQueue-object or some parameters, like branchCode, borrowerCategory, letterNumber.
* C4::Overdues::Controller-object, to manage higher level operations, like finding and enqueuing new overdue notifications from Issues, or sending overdue notifications using various message transport types and subclassable PrintProviders to easily integrate to 3rd party printing services.
* C4::Overdues::Finder-object, does the work of finding Issues which could trigger different overdue notifications, and makes sure that letter1 and letter2 and letter3 always have the same delay between them, regardless of failures in message sending, so we wont accidentally send all overdue notices at once when the error in message sending has been resolved.
* C4::Overdues::Builder-object, builds the MessageQueue-objects and MessageQueueItem-objects from the Found overdue Issues, and also deals with migrating data from old message_queue-rows to the new message_queue_items-table.
*Koha::PrintProviderInterface-interface, allows consistent subclassing of various PrintProviders to deal with various ways of sending print-messages from Koha. Eg. sending notifications to be printed to a printing press using a special format using Koha::PrintProvider::Enfo (for Enfo Zender), or just using the old Koha-way with Koha::PrintProvider::Manual. The desired PrintProvider is configurable from the system preferences. PrintProvider also implemets a fine generation mechanism of adding a fine for the borrower based on the OverdueRule.
Category:RFCs
Override sysprefs in Apache config

It is possible to override specific system preferences in the Apache config. This enables things like:
* Multiple OPACs with different CSS
* Multiple OPACs with different default search limits
* Self check out with different users for different libraries
==Examples==
On an installation using the Debian packages, your site specific Apache config file will be located at:
 /etc/apache2/sites-enabled/<instance>.conf
Add something like the following to set up SCO with a given user and password:
 RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckAllowed 1"
 RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckID xyz"
 RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckPass abc"
To limit search to the "MYLIB" library:
 RequestHeader add X-Koha-SetEnv "OPAC_SEARCH_LIMIT branch:MYLIB"
 RequestHeader add X-Koha-SetEnv "OPAC_LIMIT_OVERRIDE 1"
An example for using different self-check users depending on the client IP (with Apache 2.4):
 <If "-R 'CLIENT_OR_NET_IP_HERE'">
 # Koha without Plack
 SetEnv OVERRIDE_SYSPREF_AutoSelfCheckID "xyz"
 SetEnv OVERRIDE_SYSPREF_AutoSelfCheckPass "abc"
 
 # Koha with Plack
 # (commas must be escaped with '\')
 RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckID xyz"
 RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckPass abc"
 </If>
==See also==
* Koha::Middleware::SetEnv
* - Per-virtualhost SetEnvs don't work with Plack (FIXED)
* - Add option to set default branch from Apache
Category:Tips & Tricks
PQF search RFC

==Search on a given MARC field/subfield==
When the library has enabled xpath in record.abs (zebra mode), then the librarian can enter a PQF to query a given MARC subfield.
In Koha 2.2 the possibility to query any MARC subfield was enjoyed by librarians. It can be reintroduced in v3.2, through a specific screen to choose the subfield to query & build the query. The result will be a direct PQF query.
Note : script already written by BibLibre (not added to 3.0)
Category:Abandoned_RFC
Package types

== There are currently 6 Koha Debian package types ==
We recommend installing the 'koha-common' package for production systems, (no other Koha packages are required) 
 
=== koha-common ===
This package includes the Koha software and all required packages, but excludes database packages (mysql/mariadb). 
=== koha-deps ===
This meta-package installs all required non-perl packages for Koha. 
=== koha-perldeps ===
This meta-package installs all required perl packages for Koha. 
Some example senarios for using the 'koha-deps' and 'koha-perldeps' packages would be a Koha 'tarball' install or a Koha 'git' install. 
=== koha (experimental) ===
This package installs Koha using debconf. It depends on 'koha-common'. 
=== koha-core (experimental) ===
This package installs a minimal version of Koha, it's intended to be used for docker type installs. 
It excludes apache, mariadb, zebradb, elasticsearch, rabbitmq and memcached packages to allow for maximum configurability. 
=== koha-full (experimental) ===
This package installs the Koha software and all required packages. 
It depends on apache, mariadb, zebradb, elasticsearch, rabbitmq and memcached packages, and assumes that Koha will be installed on a single system.
PackagesIndexDaemon

= Using the Zebra Indexing Daemon with the Packages (3.18 onwards) =
As of version 3.18, the setting of Zebra indexing daemon is simpler:
On 18.11 onwards (at least) the index daemon is enabled by default (USE_INDEXER_DAEMON="yes").
* Edit /etc/cron.d/koha-common and comment out the koha-rebuild-zebra line
* Edit /etc/default/koha-common and change this line: 
 USE_INDEXER_DAEMON="no" to USE_INDEXER_DAEMON="yes"
* Run: sudo service koha-common restart
* Now the daemon should be running.
Note: Above instructions will apply to all instances. If you need to stop one instance's indexer, please take a look at the koha-indexer command (man koha-indexer)
== Older than Koha 3.18 ==
If you want to use a indexing daemon in older versions, there are a few small changes to make. This feature is currently experimental (October 2012), so we would appreciate people testing it and reporting any bugs found.
* Run: sudo apt-get install libkoha-contrib-tamil-perl
* Edit /etc/cron.d/koha-common and comment out the koha-rebuild-zebra line
* Edit /etc/init.d/koha-common and uncomment the references to koha-start-indexer, koha-stop-indexer, and koha-restart-index
* Run: sudo service koha-common restart
* Now the daemon should be running.
Category:Debian_Packages
Paid support providers list RFC

== Background ==
=== The purpose of the list ===
=== The listing criteria ===
=== The current issues ===
== Options ==
* Option 1: 
* Option 2:
* Option 3:
=== Option 1: ===
Overview
Advantages
Disadvantages
=== Option 2: ===
Overview
Advantages
Disadvantages
=== Option 3: ===
Overview
Advantages
Disadvantages
== Recommendations for General IRC meeting ==
== Links to discussions ==
Category:RFCs
Partial resources RFC

There are use cases in which a resource information needs to be publicly accesible, but some bits restricteed to users with specific permissions.
We implement a whitelisting approach for this cases. Publicly accesible attributes are marked with a local attribute 'x-public', which is used in the authentication chain.
Following the principle of Least Surprise, the endpoint will return the publicly accessible portion of the objects by default (so it will be the expected behaviour for API consumers). 
Consumers that require protected attributes will be rejected if they don't have enough permissions.
Category:RFCs
Patron Reading record management RFC

== Patron reading record management ==
Add a feature to let the patron manage it's reading record himself.
The laws in some countries requires that the library cleans the reading record after some time. This new feature will let the user himself decide what to do with the reading record. by default, the behaviour will be unchanged (clean borrower history after some time).
this feature will be activated (or not) through a systempreference
An option will be added on OPAC to let the patron request "keep my reading record forever" (a checkbox). If the user uncheck it, the reading record will be cleaned later, by the cleanborrowers script. If the user uncheck it, the already deleted issues won't reappear, of course.
An option will be added on OPAC to let the patron request "clean my reding record immediatly". That will clean (after a confirmation) the reading record for issues that can be removed (ie : not current issues) and the patron chooses (through a checkbox list, on the left)
The librarian won't be able to set the "keep my record forever" himself, and it won't be checked by default.
The librarian will be able to see the flag.
Technical notes :
# add a field (keepreading) to members page & display it in members/moremembers.pl
# modify opac-readingrec.pl to let the user change the status of this flag.
# add a opac-emptyreadingrec.pl to remove the reading history. (ask for 2 confirmations before doing it, as it will be un-cancelable once it's done)
# modify tools/cleanborrowers.pl to deal with this flag
Category:Members/Patrons_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Patron self-managing privacy RFC

In Koha 3.0, the reading history are kept according to local laws. It's enough for most libraries, but some want their patron to be able to deal with it directly. We will add a feature where the patron will be able to :
* Ask Koha to keep his reading history forever
* Ask Koha NOT to keep anything
* Ask Koha to keep things according to local rules
The option will also let the patron immediately anonymize his reading history. Everything will be activable or not through a syspref.
Is this a duplicate of Patron Reading record management RFC?
Category:Members/Patrons_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Patrons extended attributes endpoint RFC

This RFC should be the basis for bug 23666 and related bug reports that could need to be filed.
== Actions and routes ==
GET /patrons/:patron_id/extended_attributes
POST /patrons/:patron_id/extended_attributes
PUT /patrons/:patron_id/extended_attributes <- to overwrite them all
DELETE /patrons/:patron_id/extended_attributes/:extended_attribute_id
The following table presents the current implementation, and the proposed changes.
Description 	Action	Path
List patron's extended attributes 	GET 	/patrons/{patron_id}/extended_attributes
Add an extended attribute to a patron 	POST 	/patrons/{patron_id}/extended_attributes
Overwrite the patron's extended attributes	PUT 	/patrons/{patron_id}/extended_attributes
Delete an extended attribute 	DELETE	/patrons/{patron_id}/extended_attributes/{extended_attribute_id}
== Extended attribute object ==
DB schema 	API
code 	type
attribute 	value
borrowernumber	REMOVED
Category:RFCs
Patrons holds endpoint RFC

This RFC proposes a route to retrieve patron's holds. This is implemented on bug 27366.
The route itself is very simple, as all the object definitions are inherited from the existing /holds
== Actions and routes ==
The following table presents the current implementation, and the proposed changes.
Description	Action	Proposed path
List holds 	GET 	/patron/{patron_id}/holds
== Hold object definition ==
The object definition is the one from the /holds route
Category:RFCs
Patrons messaging preferences endpoint RFC

This RFC should be the basis for bug 17505 and related bug reports that could need to be filed.
== Actions and routes ==
The following table presents the current implementation, and the proposed changes.
Description 	Action	Current path	Proposed path
List preferences for patron	GET 	 	/patrons/{patron_id}/messaging_preferences
Overwrite preferences 	PUT 	 	/patrons/{patron_id}/messaging_preferences
== Patron object definition ==
DB schema 	Josef Moravec 	tcohen
borrowernumber 	patron_id 	REMOVED
message_attribute_id 	message_type [1] 	message_attribute_id (I agree with the idea of a readable alias, but not really required)
days_in_advance 	days_in_advance 	days_in_advance
digest 	digest 	digest
borrower_message_preferences_id	patron_message_preferences_id 	
message_transport_type 	transport_type [2] 	
system_preferences 	messaging_preferences_status [3]	
=== Notes ===
[1] Should by some kind of string identifier - maybe value from message_attributes.message_name
[2] list of defined transports from borrower_message_transport_preferences
[3] if don't enabled by syspref, get error 405 Method Not Allowed
== Comments ==
Some thoughts:
* If we only support GET and PUT here, how will you deactivate message preferences? With an empty list of message types? 
* What if there don't exist any entries for the patron in the tables yet - How will we receive the correct list of message types to update?
--Kfischer 08:12, 30 March 2018 (EDT)
In response to Katrin:
* We should add DELETE for disabling
* There should be a separate endpoint, with the list of options
--Tomas
Thinking about it, I think they should really be endpoints for each 'type', as in /patron/{patron_id}/messaging_preferences/{message_type}, 
Category:RFCs
Patrons password endpoint RFC

This RFC should be the basis for making an endpoint for changing patron's password. This is implemented on bug 17006
== Actions and routes ==
The following table presents proposed implementation.
Description 	Action	Proposed
Update password	POST 	/patrons/{patron_id}/password
== Request body ==
Attributes	Description
password 	New password (plain text)
password_2	Repeated new password (plain text)
Category:RFCs
Payments Process

= Acquisitions - Payments Process =
Many Academic libraries in India follow a payments process.
== Process Overview ==
1. Request payment to a vendor by selecting a set of orders that have been invoiced and accessioned. A unique payment request number is generated
2. Print the payment request form and send to accounts
3. Receive copy of payment voucher sent to vendor along with the cheque
4. Update payment status by entering the cheque no. against the payment request
== Payment Request Number ==
The unique payment request number is used to link information on the ILS to paper files and registers. The number can be auto-generated by the ILS or staff can enter the number manually. 
== Payment Request Use Cases ==
Following use cases must be supported:
Add, edit or delete payment request records
Add, edit or delete orders within payment request records
Update payment status for each order
== Information Retrieval Use Cases==
Use cases that must be supported are:
Find payment requests related to a purchase order
Find purchase orders related to an payment request
Find titles related to a payment request
Find payment requests for a vendor
== System Preference ==
A system preference will control whether payment process will be active or not.
== Modifications to Koha's Order Process ==
The payment process will be added at the end of the current Koha order life cycle. Once an order is invoiced and accessioned, the order can be included in a payment request form.
== Open Questions ==
Do we need any new permissions to control who can perform the payment tasks? 
* paul_p (BibLibre) = I think yes
Do we need granular permissions to control access to steps within the payment process? 
* paul_p (BibLibre) = I think no
What are the commonly used formats for the payment request number? 
Format of the approval request form (for printing)
paul_p (BibLibre) note = we are working to rewrite all money related displays using more properly Format::Locale::Number, that's a path you could also follow
Category:Acquisitions_RFCs
Category:Koha_3.4_RFCs
PazPar to search external Z39 50 on OPAC

== Minimal howto ==
The idea is to use Pazpar2 of IndexData but we find the installation is quite difficult. 
Now the suggestion is: 
*If you want a more easy config on Koha server, install PazPar2 in a dedicated server, not the server where is installed Koha.
*If you use the same server of koha, add Indexdata repo to your repo.
*Update the system
*Install pazpar2
** ATTENTION, this operation update also YAZ and Zebra. Now (March 2017) this OK but in the past it creates bug and problems.
*Setup PazPar2 with your z39.50 targets
*To do it use the IndexData's documentation
*Create a new page on Opac with an Ajax call to the PazPar2 server starting from this instructions
*Insert links to the new page using javascript in system prefence OPACUserJS
Perltidy

== Official perltidy style ==
Koha has an official perltidy style that should always be used (see the Coding Guidelines: PERL1:Perltidy). 
You can find the Koha perltidy configuration file, .perltidyrc, in the root directory of the Koha repository. 
It was added on 2023-06-08 by bug 30002.
== Setup==
From the root of the Koha repository, specify the perltidy configuration file to use:
$ perltidy -pro=/home/path/to/.perltidyrc
==Transition and best practices==
===Only perltidy modified code===
For historical Koha code: only perltidy the specific code block that you are modifying...and no more! (um.. unless it's really really fugly :p)
In other words, please don't perltidy entire files or send patches that contain perltidy changes to code other than the code-block being modified.
If you really do need to perltidy entire files, then these should be submitted as a separate patch in the bug (the same as when fixing indentation - see the Coding Guidelines: Indentation).
===It will be a slow transition===
We are currently taking a gently/slowly approach as the Koha codebase transitions to the official perltidy style.
== Using perltidy in your editor==
The Brief Perltidy Tutorial has a section on using perltidy on selected text.
===Visual Studio Code (VSCode)===
If you are using VSCode for Koha development, you are most likely using the Perl extension.
This extension allows you to tidy code using perltidy.
====Configuration====
To configure VSCode to use perltidy:
# Go to File > Preferences > Settings.
# Search for perltidy and you will be presented with the Perl:Perltidy and Perl:Perltidy Args options.
# Make sure Perl:Perltidy points to a valid executable (usually just perltidy is good enough, but you might need to adjust for different operating systems).
# For Perl:Perltidy Args, edit settings.json and make sure it looks like:
 "perl.perltidyArgs": [
 "-pro=/home/path/to/.perltidyrc"
 ]
==== Usage====
Select a code region and use Ctrl+k Ctrl+f.
===Geany ===
====Configuration ====
To configure Geany to use perltidy:
#Go to Edit > Format > Send Selection to > Set Custom Commands
#Set a custom command to use perltidy by clicking Add, then:
#*Command: perltidy --pro=/home/path/to/.perltidyrc
#*Label: perltidy
==== Usage ====
# Select part of your file or script
# Now you can perltidy using the menu or the keyboard shortcut:
#* Edit > Format > Send Selection to > perltidy
#* Use the keyboard shortcut assigned to the entry. Example Ctrl+1.
===VIM===
====Configuration====
To configure VIM to use perltidy, add the following line to your .vimrc:
vmap <F8> :!perltidy -q<CR>
===== Koha testing docker =====
You do not need to configure VIM to use perltidy, it is already configured in KTD.
====Usage====
Switch to visual mode (Ctrl+v), select a block, then press F8. 
===== Koha testing docker =====
Switch to visual mode (Ctrl+v), select a block, then type :Tidy.
Category:Development