nyuuzyou/wikis huggingface dataset:
QA Test Tools

== Introduction ==
The QA Test Tools are intended for use by developers before submitting patches, testers and of course the QA team. They will run a series of tests on a given range of commits and output the results with hints on how to fix the problems. Failing the QA Test Tools will usually result in setting the bug to Failed QA until fixed by the developer.
== Use with KTD (koha-testing-docker) ==
When working with KTD, the QA Tests are already set up:
qa
== Use with a KohaDevBox == 
When working with a KohaDevBox installation, the QA Test Tools are already set up:
 vagrant ssh
 sudo koha-shell kohadev
 qa -c 2 -v 2
-c is for the number of commits to run the tests on and can be left out if you are only testing 1 bug (it will default to looking at bug numbers in the commit messages and work backwards until it finds a change)
== Use with a git installation ==
The following instructions assumes a git installation of Koha with koha-deps and koha-perldeps installed and are generally savvy enough to recognize that the instructions are only for a guideline, and not necessarily intended to be cut-and-paste mindlessly. However, boxes have been placed around things you may wish to cut-and-paste. And if there is prompting, the boxes are split apart.
=== Get the source ===
cd
git clone https://gitlab.com/koha-community/qa-test-tools.git
cd qa-test-tools
=== Configure dependencies ===
sudo apt-get install libfile-chdir-perl libgit-repository-perl liblist-compare-perl \
libmoo-perl libperl-critic-perl libsmart-comments-perl dh-make-perl libtest-perl-critic-progressive-perl cpanminus
And to be on the safe side, run the perl-deps file through cpanm.
sudo cat perl-deps | cpanm
Also, you must read the README file in your qa-test-tools git directory. This is where up-to-date information about the tool will be available.
=== Setup configuration files ===
ln -s ~/qa-test-tools/perlcriticrc ~/.perlcriticrc
mkdir ~/bin
ln -s ~/qa-test-tools/koha-qa.pl ~/bin/koha-qa.pl
Next, set up PERL5LIB to include /home/{your user name}/qa-test-tools (remember the delimiter between items is a colon). This can be done in /etc/environment or your .bashrc file (remember to put export in front for the .bashrc). You want it in the same place as you did the configuration for Koha's required PERL5LIB.
Logout and log in for the environment variables to take effect.
=== Test it ===
cd ~/qa-test-tools
prove -v t/Perl.t
This hopefully will not fail. If it does, resolve the problems.
Change into the directory where Koha was cloned for your git installation.
koha-qa.pl -v 2 -c 1
Hopefully it will run and give pretty PASSes or FAILs. Worst case scenario a dependency was missed. If so, find it, install it, and rerun the koha-qa.pl script.
=== Documentation ===
Type koha-qa.pl without any options to get a list of available options, or
perldoc ~/qa-test-tools/koha-qa.pl
Category:Development
Category:Quality_Assurance_Testing
Category:Installation
QA team meeting 2013-09-03

=== Place ===
The #koha IRC channel (IRC server irc.oftc.net).
=== Time ===
3rd September 2013 at 19:00 UTC
Conversions to your local time: 
* Time and Date.com converter for various local times.
=== Agenda ===
* Introductions (please use "#info" in front of your introduction to have it show up in the automatic minutes) 
* Agenda 
** Additions, comments, priorities?
* Dates and deadlines
* QA priorities
** Prefer bugs over enhancements, get bug queue down to 0
** How to handle regressions?
** Who can QA patches for
*** LDAP: 9299
*** UNIMARC: 10331, 10218, 10564, 10324, more in 'needs sign off'
*** SIP2: 10445, 7560, 9288
** Oldest enhancements are not QA in priority
* Passing QA
** Policy for requiring unit tests
** More generally: What are conditions for a patch to pass QA (no complain from qa tools, new module in Koha, unit tests for new module/method/routine, etc)?
* Ideas to improve throughput 
** GBSD participation
** QA sprints on specific topics, modules, big patches
* Adding new modules
** New module cannot be proposed while DBIx is not integrated into Koha (even if it improves code and adds unit tests, see bug 10363)?
=== Apologies ===
===Next meeting===
===Minutes===
* Minutes: http://meetings.koha-community.org/2013/qa_team_meeting.2013-09-03-19.06.html
* Minutes (text): http://meetings.koha-community.org/2013/qa_team_meeting.2013-09-03-19.06.txt
* Log: http://meetings.koha-community.org/2013/qa_team_meeting.2013-09-03-19.06.log.html
Category:QA Team Meetings
Category:IRC_Meetings
Category:Developers_IRC_Meetings
REST API: Checking username and password

Small example that uses the validateUserAndPassword operation. 
* Authenticates to the REST API using Basic Auth
* Checks the username and password for the "koha" user
Settings: 
* RESTBasicAuth = Enable
 use Modern::Perl;
 use LWP::UserAgent;
 use HTTP::Request::Common;
 use JSON;
 use Data::Dumper;
 $Data::Dumper::Sortkeys = 1;
 
 my $domain = 'localhost:8080';
 my $username = 'koha';
 my $password = 'koha';
 
 my %data = ( 
 'userid' => 'koha',
 'password' => 'koha',
 );
 
 my $ua = LWP::UserAgent->new();
 my $request = HTTP::Request::Common::POST(
 "http://$domain/api/v1/auth/password/validation", 
 Content_Type => 'application/json', 
 Content => to_json( \%data )
 );
 
 $request->authorization_basic( $username, $password );
 
 say Dumper $request;
 
 my $response = $ua->request($request);
 say $response->as_string();
Expected output:
 $VAR1 = bless( {
 '_content' => '{"password":"koha","userid":"koha"}',
 '_headers' => bless( {
 'authorization' => 'Basic a29oYTprb2hh',
 'content-length' => 35,
 'content-type' => 'application/json'
 }, 'HTTP::Headers' ),
 '_method' => 'POST',
 '_uri' => bless( do{\(my $o = 'http://localhost:8080/api/v1/auth/password/validation')}, 'URI::http' )
 }, 'HTTP::Request' );
 
 HTTP/1.1 201 Created
 Connection: close
 Date: Fri, 05 Apr 2024 12:45:30 GMT
 Server: Apache/2.4.56 (Debian)
 Vary: User-Agent
 Content-Length: 50
 Content-Type: application/json;charset=UTF-8
 Client-Date: Fri, 05 Apr 2024 12:45:30 GMT
 Client-Peer: 127.0.0.1:8080
 Client-Response-Num: 1
 
 {"cardnumber":"42","patron_id":51,"userid":"koha"}
Category:Documentation
REST API Debug

= Troubleshooting Koha's REST API functionality =
Koha currently depends on specific versions of the following 3 perl packages
 Mojolicious 
 JSON::Validator 
 Mojolicious::Plugin::OpenAPI
If you install Koha using the debian packages you should not have any problems
If you install perl packages manually using CPAN, you *may* install incompatible versions of these packages; specifically for 21.11 versions, and older
more info on bug 30194 
==== Before you start, you can verify that the API is functional ====
 $ sudo apt update
 $ sudo apt install -y jq curl pmtools
 $ curl -s http://my.koha.instance.net/api/v1/ | jq .info.title,.swagger
 "Koha REST API"
 "2.0"
If you do not get the results above, try the following steps
==== Check koha-common is installed ok ====
 $ dpkg -s koha-common | grep Status
 Status: install ok installed
==== Check 3 API packages are installed ok ====
 $ dpkg -s libmojolicious-perl libjson-validator-perl libmojolicious-plugin-openapi-perl | grep Status
 Status: install ok installed
 Status: install ok installed
 Status: install ok installed
==== Check 3 API package's path is correct ====
this is where the Debian package's files are located
 $ pmpath Mojolicious JSON::Validator Mojolicious::Plugin::OpenAPI
 /usr/share/perl5/Mojolicious.pm
 /usr/share/perl5/JSON/Validator.pm
 /usr/share/perl5/Mojolicious/Plugin/OpenAPI.pm
==== Check 3 API packages are not installed via CPAN ====
 $ pmpath Mojolicious JSON::Validator Mojolicious::Plugin::OpenAPI | grep '/usr/local/share/perl' | wc -l
 0
If your above result is not 0, consider deleting your CPAN directory (take a backup, caveat emptor, etc)
 $ sudo rm -rf /usr/local/share/perl
==== Check 3 API package's versions are compatible ====
the versions required for 22.05 are...
 $ pmvers Mojolicious JSON::Validator Mojolicious::Plugin::OpenAPI
 Mojolicious: 9.22 (needs to be 9.22 or higher)
 JSON::Validator: 5.08 (needs to be 5.08 or higher)
 Mojolicious::Plugin::OpenAPI: 5.05 (needs to be 5.05)
the versions required for 21.11 and below are...
 $ pmvers Mojolicious JSON::Validator Mojolicious::Plugin::OpenAPI
 Mojolicious: 8.12 (needs to be 8.12 or higher)
 JSON::Validator: 3.14 (needs to be 3.14 and less than 4.00)
 Mojolicious::Plugin::OpenAPI: 2.16 (needs to be 2.16 and less than 3.00)
Now you have completed these steps, repeat step 1.1 to verify the API again
RFC Meetings

==QA session for BibLibre Branches==
(Voluntary Chair) Katrin Fischer? Colin Campbell? Jesse Weaver?
(Time and Date) 16 December?
==C4:Search==
(Voluntary Chair)
(Time and Date) 20 December?
==Packaging==
(Voluntary Chair)
(Time and Date) 27 December?
==Circulation==
(Voluntary Chair) Galen Charlton?
(Time and Date) 3 January?
==Performance Work (Memoize and Memcached)==
(Voluntary Chair) 
(Time and Date) 5 January?
==More Performance Work (Javascript/Plack)==
(Voluntary Chair) 
(Time and Date) 6 January?
==Data Persistence==
(Voluntary Chair) 
(Time and Date) 10 January?
==Ajax==
(Voluntary Chair) 
(Time and Date) 12 January?
==mod_perl==
(Voluntary Chair) Galen Charlton?
(Time and Date) 13 January?
==Template Toolkit==
(Voluntary Chair) 
(Time and Date) 17 January?
==Database Abstraction==
(Voluntary Chair)
(Time and Date) 19 January?
Category:IRC_Meetings
RFCs for Koha 3.4

== RFCs for Koha 3.4 ==
This page contains RFCs for version 3.4 of Koha. All RFCs for major new features for Koha 3.4 should be posted to koha-devel and copied here. As work progresses, bugs should be linked here. 
=== Architecture ===
==== Memoize and Memcached ====
Some work has already been done using these technologies to increase the performance of Koha by caching the results of much used subroutines. 
==== mod_perl ====
The easiest and most effective performance boost for Koha is to make it mod_perl2 safe so that if users want to use mod_perl2 it can be used. Making Koha 3.4 safe for use with mod_perl2 is a major goal.
Supporting Apache::PerlRun is certainly doable, but support for Apache::Registry will take rather more code cleanup. Which are you proposing for 3.4? --- //Galen Charlton 2010/02/10 06:34//
==== C4::Search ====
For the most part this module does it job, but it is overly complicated and hard to maintain and change. Refactoring this a major goal.
==== Circulation performance ====
=== XML out of circulation code ===
One of the big bottlenecks in circulation at present is the constant parsing and writing of XML. Shifting the data needed for circ out of the xml columns and shifting the processing of xml out of the circulation code will speed it up immensely.
Henri Damien Laurent has done some work in this area, I will be drawing heavily on his ideas.
It's more general than getting XML out of the circulation code as such - the issue is, more broadly, embedding item data in the bib MARC and MARCXML. Getting it out will also improve performance during cataloging, particularly in the case of serials. It will also resolve an issue where OPAC and staff bib details display fails if a bib has more than a few hundred items attached to it. --- //Galen Charlton 2010/02/10 06:30//
=== AJAX ===
Adding AJAX support that fails gracefully is another good potential performance boost
==== Packaging ====
Finishing the debian packaging for 3.4 is a major goal. If packages can be created for other distributions that would be great also
==== Template Toolkit ====
HTML::Template::Pro has served us well for few years but we are running into limitations with it. Template::Toolkit is under much more active development, is more feature rich and allows for much easier to maintain and translate templates
This is a major goal for 3.4
If this is not achieved, we really should apply some patch to change the default HTML::Template::Pro escaping, as in http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3652
Work is well underway on this Template_toolkit_test
==== Database Abstraction ====
I would like 3.4 to be installable on both mysql and postgresql with equal ease
=== Performance and memory Encumbrance ===
* Translation Process : Installer and Javascript libraries improvements
=== Features ===
Described in http://wiki.koha-community.org/wiki/Category:Koha_3.4_RFCs
Category:Koha_3.4_RFCs
Receipt Printing Fonts

Avast ye swabbies! Freshly pirated from Wizzyrea, there's all ye needs know about hackin' yer receipt printer! Yarrr, font be a cruel mistress.
There is a lot you could do to the fonts/receipts, a decent primer on font styling in CSS is available here: http://www.w3schools.com/css/css_font.asp. If you are using Koha 3.4+, there is the IntranetUserCSS preference that you can use 
 #receipt {
 font: 15px, arial, sans-serif; /*editing to your whim, of course*/
 }
to style your receipt fonts.
Category:Documentation
Category:Tips_&_Tricks
Recovering from a corrupted zebra index

Occasionally you may run into an issue where your Zebra server begins segfaulting due to a corrupted index. In many cases, this will require a full reindex to recover from, but there are things we can do to make the process less painful, especially for catalogs of any significant size (1 hour+ for a full reindexing).
Zebra keeps the indexes in files. This means that you can take snapshots of the indexes to back them up. 
If you have no backups of your Zebra index, your only recourse is a full (hours long, in many cases) reindex where you stand. Your catalog will be down for the duration.
The Koha debian packages do this for you as part of the package backup procedure. Koha users with manual installs will need to 
# locate their zebra indexes
# write a shell script to take a nightly backup
# put that in their crontab
We recommend keeping 5 sets, just in case.
In the event of a corrupted index killing your Zebra, *assuming you have backups,* the general procedure is as follows:
# go get your backup index files and have them ready (for the packages, those are kept on the machine at /var/spool/koha/instancename/instancename-date.tar.gz. Unzip them, files/directories you need will be in the var/lib/koha/instancename/biblios directory)
# stop your zebrasrv/down your catalog (for the packages that's koha-disable instancename)
# locate and delete your corrupt zebra indexes (for the packages this will be /var/lib/koha/instancename/biblios). Be sure to double check the permissions/owners on the indexes. You'll need to re-do them on the backups - it's best to write it down!
# copy the backup files into their place
# re-do, if necessary, permissions and owner/group on the index files
# bring up your catalog (with the packages, that's koha-enable instancename)
This will bring your indexes back to a working state, sans any additions done in the interval between the index backup and the restore. The business of the library can continue normally at this time.
To recover fully, run a full reindex to catch the inevitable newly cataloged items between when the snapshot was taken and the failure occurred. Do this after hours.
Category:Zebra
Category:Tips_&_Tricks
Refining the budgets hierarchy and informations RFC

== RFC: refining the budgets hierarchy and informations ==
We want to change the structure of budgets by:
* merging the notions of fund and budget into a single notion of budget and 
* allowing for a hierarchy of budgets
On page admin/aqbudget.pl, the new form to enter budgets would sport a few more fields; current fields would be kept; they are: 
* Budget code
* Budget full name
* Start date
* End date
* initial budget amount
* branch (optional)
We would add the following fields: 
* a dropdown for "parent budget", which is a list of existing budgets, in a hierarchy, with root as a default. 
An example would be:
* root
** novels
*** novels in english
*** novels in french
** dvd
** etc
We would also add:
* an "encumbrance alert" text box. If the budget is of, say, $1000 and this parameter is 10%, Koha outputs an alert as soon as someone tries to save an order that will leave less than $100 available in the budget. If the value is 0% Koha will let the available amount go down to 0 but not run into negatives: encumbrances+spent = $1010 will not be allowed. If the value is empty, Koha will do nothing.
* an "expenditure alert" text box. Same thing as above, for spent amounts.
* a note field
* 2 authorized values fields, to be used for reports and statistics
Koha will also give the list of librarians who have the right permissions for budget_invoice and/or budget_encumbrance (see Managing permissions on acquisition module): one can select logins in the list, or "select all" (default) to link them to this particular budget.
Category:Acquisitions_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Refining the management of funds & budgets RFC

==RFC: refining the management of funds & budgets ==
 
Once we have a budget hierarchy in place (see Refining the budgets hierarchy and informations RFC), we should be able to better management the budgets themselves, i.e. the amounts.
Currently a budget is created with an amount attached to it. One can have encumbrances and invoices on this budget. But to change the amount on the budget (say add $1,000 to the initial $10,000) one can only go change the initial amount. We'd rather add a "manual credit" of $1,000 and have Koha record it as such rather than change the initial amount.
Proposition for this RFC is as follow.
The page admin/aqbudget.pl?op=add_form&aqbudgetid=X is changed.
Top of the page presents "budget informations": name of the budget, date of beginning, date of end, library. With an "edit" button to change these informations.
Then a table presenting all the financial operations that happened on the budget, ordered by date.
With tabs.
Tab #1 - budget operations, with columns:
* transaction number #n
* type of transaction: credit / debit
* vendor : either taken from the vendor list, or empty
* amount
* date of the transaction
* a note field
That could look like that:
credit :: <empty> :: 10,000 :: 2008/01/01 ::: initial budget
debit :: TAYLOR :: -245 :: 2008/01/03 :: invoice #987
credit :: TAYLOR :: 50 :: 2009/01/09 :: reimbursement #759
etc.
Tab#2 - Create manual operation
Based on members/maninvoice.pl and members/mancredit.pl one could add or substract amounts to the budget manually.
Form fields to fill in would be:
* dropdown: credit/debit
* dropdown: vendor or empty
* amount
* note field
* date (hidden field)
Category:Acquisitions_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Release Announcements

== Introduction ==
Many websites, software directories and code repositories mention Koha and include specific information, for example last updated, version number, description.
In addition, release announcements are posted to various websites and services, for example Twitter, Facebook, mailing lists, etc.
This page records a list of known places where:
* information about Koha is recorded, 
* release announcements are posted.
Koha community members generally update these sites after a new release. You may need to be quick though to get in first....
== Known places where information about Koha is recorded ==
Website 	Koha page 	Process 	Comments 	Latest Announcement
cnet 	http://download.cnet.com/Koha/3000-2131_4-75445804.html?tag=bc	Register on website and 'Report a problem' 	Currently offers download for the fork, Report sent 26 Aug by Chris Cormack 	
Foss4lib 	http://foss4lib.org/package/koha 	Register and add a new release and announcement 	Anyone can create an account, update the details and make a release and news annoucement. Great directory of free software for libraries - includes software details, releases and announcements.	3.8.4
Freecode (previously know as freshmeat.net)	http://freecode.com/projects/koha 	Create an account and post a release announcement. 	Owner can edit project details. Project owner recorded as ranginui. 	3.8.4
Free Software Foundation 	http://directory.fsf.org/wiki/Koha 	Can't updated directly - log a bug report with updated details.	Bug report posted on 27 May (David Nind) 	
Launchpad 	https://launchpad.net/koha 	Not known 	Shows latest release for download. 	3.8.4
Open Hub (formerly Ohloh) 	https://www.openhub.net/p/koha 	Watches changes in the Git repo. 	Shows lots of stats. 	Keeps current with the Git repo.
Savannah 	http://savannah.nongnu.org/projects/koha 	Notice advises that the project now lives at koha-community.org	 	
Sourceforge 	http://sourceforge.net/projects/koha/ 	Notice advises that the project now lives at koha-community.org	 	
Wikipedia 	http://en.wikipedia.org/wiki/Koha_(software) 	Create an account and edit 	 	3.8.4
== Known places where release announcements are posted ==
Website 	Web page link 	Comments
Facebook 	http://www.facebook.com/kohails 	Updated by Nicole Engard
Koha mailing list - general	http://lists.katipo.co.nz/mailman/listinfo/koha	Posted by release manager
Koha website 	http://koha-community.org/ 	News item posted by release manager
Library Technology Guides 	http://www.librarytechnology.org/ 	Library technology related news items - update by Marshall Breeding, including Twitter (https://twitter.com/#!/mbreeding). Notify by email or through the LTG message form (login required).
Open Network Libraries 	http://onl.org.nz 	Latest announcement was for 3.4.4
Liswire 	http://liswire.com/content/submit-press-release	Register and post a release
Twitter 	https://twitter.com/#!/kohails 	Updated by Nicole Engard
Category:Release_Management
Release Maintainer for 3.2 Proposall

== Release Maintainer for 3.2 Proposal ==
===Overview===
3.2 represents a significant advancement in the number and quality of features offered by Koha. With the valuable investment of both time and money in this growth by members of the community, the responsibility and stewardship of vigilant maintenance devolves upon the community. With that in mind, I propose the following:
* that the 3.2 Release Maintainer become the point of convergence of the several maintenance efforts outlined below.
* that regular consultation and coordination with the current Release Manager and Translation Manager be an integral part of the work of the Release Maintainer.
* that a regular schedule of maintenance releases be published and maintained.
* that after the next two subsequent stable releases of Koha, the developers meet and decide on an end-of-support (EOS) date for 3.2. By announcing and maintaining both a schedule of maintenance and, eventually, an EOS date, Koha support vendors, their customers, and the user community at large will be able to better plan their maintenance and migration schedules.
===Proposed Schedule of Maintenance Releases===
====From 3.2.stable to 3.4.stable====
Release once every 30 days or as bug fixes are available whichever is longer.
====From 3.4.stable to X.X.stable====
Release once very 90 days or as bug fixes are available whichever is longer.
====After X.X.stable====
Meet with developer's to decide on an EOS date.
Release twice more: once mid-way to EOS and once at EOS.
===Needed Areas of Maintenance===
====Back-porting Bug Fixes====
With this growth will come the undesirable but inevitable appearance of bugs. The fixes for such bugs should be applied to the current development HEAD and back-ported to the 3.2 codebase.
====Maintaining and Expanding Translations====
The ever increasing exposure and usage of Koha across the world will lead to the need of updating and expanding the languages into which Koha is translated. This expansion should be part of the maintenance process in order to help enlarge the user base of Koha. 
====Minor Enhancement of the Current Set of Features====
Undoubtedly there will appear from time to time enhancements of the current 3.2 feature set which it will be desirable to implement into the 3.2 code base. While it is not the purpose of 3.2 to morph into a semi-3.4 release, there should be some room for improvement. The regular maintenance release of 3.2 should include such items as appropriate.
Category:3.4