nyuuzyou/wikis huggingface dataset:
Backing up Koha

mysqldump is a command line utility that can be used to dump data in the Koha database to a text file. 
The examples assume a Koha database called koha and a Koha database user called kohaadmin.
==Complete dump==
To get all the data, use: 
mysqldump -u kohaadmin -p koha > mydatadump.sql
* -u specifies the user to log in to MySQL as, in this case kohaadmin
* -p makes mysqldump prompt for the password
* koha is the name of the database
There are certain tables in the Koha database you may not want or need to dump, like sessions and zebraqueue. These can be excluded with the --ignore-table option. Note that the option must be repeated for each table, and the table name must be given as databasename.tablename: 
mysqldump -u kohaadmin -p --ignore-table koha.sessions --ignore-table koha.zebraqueue koha > mydatadump.sql
Note: If you choose to not dump the sessions table, be aware that loading the resulting dump into an empty db will probably result in errors like this:
Can't call method "delete" on an undefined value at /usr/share/koha/lib/C4/Auth.pm line 717.
To avoid this, restore the dump over a fresh db or omit '--ignore-table koha.sessions'
==Load data from mysqldump into a database==
mysql -u kohaadmin -p koha < mydatadump.sql
==A specific MARC framework==
This might not be necessary since currently Koha support to export/import frameworks throw stuff-client.
Assuming you have created a MARC framework called Yourcode you can dump all the relevant data into a file with this command: 
mysqldump -u kohaadmin -p koha marc_subfield_structure marc_tag_structure biblio_framework --where "frameworkcode='Yourcode'" --no-create-info > myframework.sql
==Installations running off the Debian packages==
For installations that were created with the Debian packages, there are scripts for doing backup and restore, specifically:
* koha-restore
* koha-dump
* koha-run-backups
See Commands provided by the Debian packages for details.
==Links==
* 4.5.4. mysqldump — A Database Backup Program - from the MySQL 5.1 Reference Manual
Category:Obsolete
Category:Documentation
Category:Tips_&_Tricks
Basket filling improvements RFC

== Basket filling improvements ==
in Koha 3.0, an acquisition basket can just be filled with new biblios, existing biblios or existing suggestions.
Some important improvements will be done :
* z3950 search & filling
* reservoir import in acquistion
* "price unknown"
* order line moving
=== z3950 search and filling ===
The values entered by the librarian in Koha 3.0 result in a small biblio being created in the catalogue. Then, the biblio has to be completed in MARC editor.
With this improvement, the biblio can be retrieved from z3950 servers directly in acquisition module, and will result in a complete biblio in the MARC record.
=== Reservoir import in acquisition ===
Some vendors provide iso2709 files. This proposed feature will let the librarian transfer a reservoir import in the basket. There will now be 4 ways to fill a biblio (empty biblio, existing biblio, suggestion, and the new reservoir import)
in basket.pl, a new link "from reservoir" will be added in "Add order" section. When the user clicks on it, a popup lets him choose the reservoir he wants to import. Then the list of biblios in the reservoir is displayed (without paging : all biblios displayed), the user can choose each biblio one by one, or click on "select all", then validate the choice. The selected biblios will be added to the basket.
=== price unknown ===
Sometimes, the library is not sure of the price, and needs to check the price with the vendor. On each line, the library will have a checkbox "price unknown". The checkbox can be checked when there is a price or when there is none.
If clicked, 2 things happen:
* The basket can't be closed anymore. A basket can be closed only if there is no unsure price.
* the screen (a new one) "prices unknown list" will display the list of all orders with prices unknown for a given behaviour (all baskets merged). The librarian can then enter "edit mode" where he can modify the price and uncheck the "price unknown".
Reminder : a price can be entered and the "price unknown" can be checked at the same time. If the price is unknown, it's logic to have price=0 and "price unknown" checked, although it's not mandatory (the library can enter price=0 and not check the "price unknown" box; it can also entre price=xx.xx and check the box)
=== Order line moving ===
It will be possible to move a line from a basket to another. This will be possible on an open basket, or on a closed one. The move can be done to another basket of the same bookseller or from another bookseller. The destination basket must be open.
The move can be done from basket.pl line.
=== Audience ===
The audience will be entered in neworderempty.pl, with other pricing informations (see Buying analysis RFC
Category:Acquisitions_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Benchmark for 3.8

== Benchmarking 3.8 ==
The following table shows the benchmark of staff interface, made with an updated version (dec, 2nd) of the script in misc/load_testing. Please do not edit this page to show your benchmark results, as they will heavily depend on your server. Those tests will be run on the same database and server every time I (Paul, RM for 3.8) push a patch that should/can improve performances. The testing server is my laptop, a Lenovo, with dual core CPU, Ubuntu and default mySQL&apache setup. The test database has 20000 biblios, 21000 items, 3700 patrons. 
 benchmark (pages computed by sec, more is better) 
Master commit 	memcache	mainpage	catalogue detail	catalogue search	member search	member search (letter)	circulation (checkout)	circulation (checkin)	all
c3abbedebedd34948b664a4d2a6b34dc4863802d, Bug 5945: email not searchable in patron search 	ON 	0.843 	0.665 	0.475 	0.727 	0.755 	0.556 	0.602 	1.643
c3abbedebedd34948b664a4d2a6b34dc4863802d, Bug 5945: email not searchable in patron search 	OFF 	0.821 	0.645 	0.484 	0.709 	0.741 	0.619 	0.621 	1.641
22dca58cbad64841fb12a6e48afa50500c1a5c60 Bug 6193 Use memcached cache koha-conf.xml configuration variables	ON 	0.855 	0.664 	0.408 	0.723 	0.765 	0.591 	0.613 	1.632
Template Toolkit caching (bug 7511) 	ON 	0.924 	0.708 	0.423 	0.902 	0.894 	0.713 	0.701 	1.937
De-nesting C4 packages, 1st commits 	OFF 	0.864 	0.695 	0.519 	0.832 	0.829 	0.721 	0.65 	1.869
De-nesting C4 packages, 1st commits 	ON 	0.986 	0.74 	0.45 	0.943 	0.942 	0.797 	0.703 	2.031
 
 
 
 benchmark (ms, less is better) 
Master commit 	memcache	mainpage	catalogue detail	catalogue search	member search	member search (letter)	circulation (checkout)	circulation (checkin)	all
c3abbedebedd34948b664a4d2a6b34dc4863802d, Bug 5945: email not searchable in patron search 	ON 	23709 	30049 	42049 	27487 	52924 	35922 	33168 	109547
c3abbedebedd34948b664a4d2a6b34dc4863802d, Bug 5945: email not searchable in patron search 	OFF 	24344 	30984 	41301 	28188 	53973 	32307 	32185 	109626
22dca58cbad64841fb12a6e48afa50500c1a5c60 Bug 6193 Use memcached cache koha-conf.xml configuration variables	ON 	23391 	30105 	48962 	27651 	52269 	33797 	32626 	110231
Template toolkit caching (Bug 7511) 	ON 	21634 	28248 	47178 	22154 	44700 	28025 	28525 	92889
De-nesting C4 packages, 1st commits 	OFF 	23130 	28754 	38494 	24027 	48234 	27735 	30762 	96270
De-nesting C4 packages, 1st commits 	ON 	20282 	27001 	44371 	21202 	42450 	25078 	28411 	88596
Category:Development
Category:Performance_RFCs
Berlin Hackfest 2016

=About=
Koha Hackfest in Berlin 25–27 May 2016 (right before Kohacon 2016).
Size of the location is limited. Please let me know if you want to come.
==Date==
Wednesday, 25 May to Friday, 27 May 2016 @ Büro 2.0
Direct flights to Thessaloniki are available on Saturday and Sunday.
==Location==
Büro 2.0 Open Source Co-Working Space, Weigandufer 45, 12059 Berlin (Neukölln).
Next S-Bahn station: S Sonnenallee
Next bus stop (M41) Hertzbergplatz
==Program==
Depends on participants. If you would like to work on something specific or offer a workshop, get in touch.
===Workshop: Catmandu===
Catmandu is a data toolkit. Koha is going to use some of their modules in the Elasticsearch implementation.
Date: tba.
==Contact==
* IRC : drojf
* EMAIL: mirko @ abunchofthings dot net
==Accomodation==
There are a lot of Hotels and Hostels in Berlin. The hackfest location is in Neukölln, a district close to that is Kreuzberg.
==Flights from Berlin to Thessaloniki==
There are a few non-stop flights from Berlin to Thessaloniki that weekend. The easyjet flights appear to be better in terms of cancellation, you can also add more and/or heavier luggage. There are a lot more non-direct, more expensive options available. I (Mirko) will be on the Saturday afternoon flight.
Sat, 28 May 2016	06:00--09:25	(02h25)	airberlin	TXL	79 € (incl. 23 kg luggage)	more expensive options; 244 € with free cancellation
Sat, 28 May 2016	16:50--20:20	(02h30)	easyjet 	SXF	78 € (incl. 20 kg luggage)	more options possible (more luggage, cancellation option +10€)
Sun, 29 May 2016	06:00--09:30	(02h30)	easyjet 	SXF	86 € (incl. 20 kg luggage)	more options possible (more luggage, cancellation option +10€)
(checked December 2015)
Category:Koha
Category:Community
Category:Conferences
Category:Koha_Conferences
Category:Hackfests
Better VAT RFC

--------
For your information, bellow, this is a list of what we have in koha pages and where the datas are stocked in the database
(field display on the interface = database field)
On neworderempty.pl :
* Vendor price = listprice
* Replacement cost = rrp (rrp is for recommanded retail price)
* Budgeted cost = ecost (rrp - discount)
* Total = ecost x quantity
* Actual cost = ecost or unitprice if you change it manually
On parcel.pl :
* "pending order":
* Unit cost = ecost
* Order cost (order total = ecost * quantity)
* "Already Received"
* Est cost = ecost
* Actual cost = unitprice
On orderreceive.pl :
* Replacement cost = rrp
* Budgeted cost = ecost
* Actual cost = unitprice
Category:RFCs
Category:Acquisitions_RFCs
BibLibre

BibLibre was incorporated in 2007, building on 5 successful years of work as free-lance consultants in open source softwares in libraries in general, and Koha in particular.
Koha was created in 2000 as the first Open Source Integrated Library System: our early involvement with the project gave us an extended knowledge of librarianship and the needs of librarians in the age of omnipresent internet and open data.
Building on this expertise, we now provide a range of services to libraries: we develop, host, support open source software for libraries and may also help you with migration processes, staff training and software maintenance.
Category:Support_Companies
Biblibre circ rules testing

Rules testing
#certify rules are created and saved correctly
#certify that circulation periods are computed correctly 
#certify that fines are calculated correctly
#certify that holds rules are applied correctly to items
#certify that renewals are completed and restricted properly
#certify that rental charges are applied correctly
#certify that rules can be deleted and no longer apply
Database Consistency Checks
#certify that rules are migrated correctly from older versions - document proper upgrade procedure or fail QA if not.
#certify all database changes are added to kohastructure for new installations
#certify all database changes are applied correctly updating from existing installation
#certify transformation for existing issuingrules are done correctly
System Preference knobs to twiddle (test with it both ways)
*Independent branches on or off
*CircControl
*Homeorholdingbranch
*homeorholdingbranchreturn
*issuinginprocess
*renewalperiodbase
*ReservesControlBranch* 
Translatability
Interface
*consistent use of elements (pull down list, checkboxes, look&feel compared to other parts of Koha)
*consistent use of 'Koha vocabulary' (reserves vs. holds, AE/BE, typos)
Documentation
(test plan for http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5872)
http://drupal.biblibre.com/
Category:Wikipedia_cleanup
Biblio-level recalls bugs fixes

Sponsored by Waikato Institute of Technology.
Additional issuing rule checks are required when:
* A biblio-level recall is placed and we decide which checkout to send the recall notice to
* An item is being returned and we decide whether that item can fulfil a recall request
Currently these checks are not being executed. This is a problem for the following reasons:
* When a biblio-level recall is placed, we send a 'return item' notice to the checkout on that biblio with the closest due date. That item type of that checkout may not be allowed to be recalled, but we don't check for this.
* When an item is returned and there is a recall on that biblio's item, we fulfil the recall request. However, the item type of that return may not be allowed to be recalled, and we do not check for this.
This patch implements these checks so that only items that are allowed to be recalled can fulfil a biblio-level request and be selected for receiving a recall notice.
=== Getting started ===
We need three borrowers - Borrower A, Borrower B, and Borrower C. Borrower A should be YOU, as this is the borrower you will log into the OPAC as.
Ensure all three borrowers have email OR sms (or both) messaging notifications enabled for the two recalls notices (members/memberentry.pl)
We need a biblio - Biblio A - with two items - Item A and Item B. These items must have different item types - Itemtype A (corresponding to Item A) and Itemtype B (corresponding to Item B).
=== Test plan ===
#Edit the circulation rules (admin/smartrules.pl). Make a rule for Itemtype A and ensure all of the appropriate recalls fields are filled out. Ensure 'recalls allowed' has a number more than 0.
#Make a rule for Itemtype B and ensure 'recalls allowed' is 0.
#Check out Item A to Borrower B and check out Item B to Borrower C.
#In another tab, log into the OPAC as Borrower A and place a biblio-level recall on Biblio A.
#In the staff intranet, check Borrower B's notices (members/notices.pl) and confirm that they were sent the 'return item' notice. You can also check Borrower C's noticed and confirm they were NOT sent the notice.
#Check in Item B. Confirm that the check in does NOT prompt a recall pop-up.
#Check in Item A. Confirm the box to confirm the recall as waiting does pop-up.
#Check that item-level recalls still work as normal.
=== Other links ===
Go back to main recalls page
Biblios pickup locations endpoint RFC

This RFC proposes a way to fetch allowed pickup locations for an biblio (as returned by `Koha::Biblio->pickup_locations`). This is implemented on bug 27932
== Actions and routes ==
The following table presents proposed implementation.
Description 	Action	Proposed
Get allowed pickup locations	GET 	/biblios/{biblio_id}/pickup_locations?patron_id=<THE patron ID>
== Discussion ==
Category:RFCs
Binding loose issues

== Background ==
For easier management of loose issues, allow for a set of issues to be bound into a volume. The bound volume will have its own accession number that will be used for circulation purposes. Accession numbers if any on an individual loose issue becomes redundant and must not be available for use in circulation.
== Process ==
Staff will manually select the issues that need to be bound into a volume. They may select issues for a month, quarter or a full year. A new barcode number must by assigned to this bound volume. The barcode may be auto-generated depending on the value in the system preference "autobarcode".
== Circulation ==
The new barcode will be used for check-outs and check-ins. Barcodes if available in any of the loose issues must not be available for circulation.
Category:Cataloguing_RFCs
Category:Circulation_RFCs
Category:Serials_RFCs
Category:Koha_3.4_RFCs
Brief records and record maintenance RFC

==Brief records and record maintenance ==
Libraries want to be able to:
# Create records quickly for materials that are not in the system, for circulation, reserves and ILL purposes. These brief records must be treated specially by the system. 
# Mark items for catalog, circulation, ILL or reserves maintenance either when they are returned or after a certain date. Brief records are one example of items that need maintenance, but other items may need to be flagged as well. 
# Flag a record to be exported for OCLC holdings update. 
LibLime proposes to add to Koha a number of attribute types to serve the specific purposes above. For instance, these attributes will include “Cataloging Review”, “Circulation Review,” “Brief Circulation Record,” and “Ready for Export.” When an attribute is assigned, the date and time the attribute was assigned will also be recorded. 
Staff may assign attributes to a bibliographic, holdings or item record..
A record may have more than one attribute of different types at once, for instance “Ready for Export” and “Cataloging Review.” 
Koha will use the attribute to control various behaviors, including:
# Routing records to specific departments upon discharge. 
# Gathering lists of records together for reporting or for export after a certain date.
Category:Abandoned_RFC
Bug and Enhancement Discussion

= Bugs and Enhancement discussions =
== Introduction ==
Sometimes, patches or bugs requires some strategic discussion to define the best way to do something. This discussion can be purely technical, or functionnal. 
A new bug status "in discussion" has been created in 2011 december, to identify those bugs. 
On the 2012 february IRC meeting, we decided the following workflow for those bugs: 
*start a wiki page explaining what is to be discussed, what's the problem, what are the possible solutions, with pros and cons 
*send a mail to koha-devel and koha mailing lists to let everybody know there's a discussion that started 
*let ppl discuss (on the mailing lists or on the wiki) of the possible solutions, pros and cons, until the next IRC meeting, but not less than one full week 
*at the next IRC meeting, - if the discussion (on the wiki or koha-devel) result in a general agreement, nothing specific need to be made (no vote needed) - if the discussion result in a balanced situation, organize a vote. 
*Ppl that can't attend the next IRC meeting can express their vote on the wiki, it will be counted during the IRC meeting 
*After the IRC meeting, report the conclusions to the mailing lists, and make the decision real by updating the bugs !
 
== Current discussions ==
 
== Past discussions ==
*Technical discussion - Cache handling in Koha - started on 2012-02-08 - Consensus reached on koha-devel
*Technical discussion - Table naming - started on 2012-02-08 - Consensus reached on koha-devel
*Technical discussion - Generalise the use Template Toolkit plugins - started on 2012-02-08 - Consensus reached on koha-devel
Category:Development
Category:RFCs
Category:IRC_Meetings
Bugzilla

Bugzilla is the issue tracker used by the Koha community. It is used to manage error reports as well as feature requests. They are considered 'bugs'. 
This page will be used to highlight some features and tips and tricks for using Bugzilla.
=== Using special tags ===
Bugzilla has the ability to mark each comment or entry on a bug with tags. There are some tags that have special meaning:
* important - By using the tag 'important' you can make a comment in the list of comments stand out. The entry will appear with a red frame around it and there will be a note on top of the bug page that there are x important entries to consider. This can be used to highlight the most recent test plan, information to be considered by RM and Release Maintainers, etc.
=== Using email with Bugzilla ===
With Bugzilla comes the ability to create and modify bugs via email.
There is a really good write up on the bugzilla site. I encourage you to read it. Here are some examples for our Bugzilla.
==To create a new bug==
Send a mail to bug-submit@bugs.koha-community.org
 From: your@email.address
 Subject: Bug NNNN Summary
 
 @product = Koha
 @component = OPAC
 @version = rel_3_2
 
 This is a bug description. It will be entered into the bug exactly as
 written here.
 
 It can be multiple paragraphs
==To modify a bug==
Send a mail to bug-submit@bugs.koha-community.org
 From: your@email.address
 Subject: [Bug 12345]
 
 I have done some work on this bug, yadda yadda
==To mark a patch obsolete==
It seems that some of you have problem marking an attachment obsolete without attaching another file.
* go to the bug
* on the attachment line, you've 3 links: "file title/description", "Details" and "Diff". Click on Details
* when you're on Details page: click on "Edit Details" (that's what is very hidden !)... Gotcha!!! I can obsolete or un-obsolete or update the comment, or add the patch flag!!!
* click "submit" at the end of your patch !
==Some useful queries==
All bugs in "patch pushed" status. They are just waiting for someone to check they are gone & close the bug
http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=changeddate%2Cbug_severity%2Creporter%2Cassigned_to%2Cbug_status%2Ccf_patch_status%2Cresolution%2Cshort_desc&field0-0-0=cf_patch_status&list_id=786&priority=PATCH-Sent&priority=P1&priority=P2&priority=P3&priority=P4&priority=P5&query_format=advanced&type0-0-0=equals&value0-0-0=Patch%20Pushed&order=bug_severity%2Cbug_id
All bugs in "Needs Signoff" status. A patch has been submitted, someone must test it and signoff
http://bugs.koha-community.org/bugzilla3/buglist.cgi?query_format=advanced&list_id=801&field0-0-0=cf_patch_status&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&type0-0-0=equals&columnlist=bug_severity%2Creporter%2Cassigned_to%2Cbug_status%2Ccf_patch_status%2Cresolution%2Cshort_desc&value0-0-0=Needs%20Signoff
Bugs closed last week
http://bugs.koha-community.org/bugzilla3/buglist.cgi?list_id=797&chfieldto=Now&query_format=advanced&chfieldfrom=7d&bug_status=RESOLVED
Category:Development
Category:Tips_&_Tricks
Category:Participation