nyuuzyou/wikis huggingface dataset:
Show subtitle on the holds to pull report

Koha has a built in report called "Holds to pull", which shows reserves that need to be picked from the shelves of the library. As a default, the report shows the titles of the records that should be pulled. But sometimes this is not enough to distinguish between books in a series or different editions. Showing the subtitle and maybe the edition would ensure the right item is picked from the shelf. Here is how to make more information show up in the report. 
(This assumes MARC21 or NORMARC as the MARC-flavour, but something similar should be possible for UNIMARC.)
* Go to Intranet > Koha administration > Keywords to MARC mapping
* Enter this information into the form:
** "Field name" = "subtitle"
** "MARC field" = 245
** "MARC subfield" = b
* Click "Submit"
* Repeat this for all frameworks where it is relevant
The subtitle should now turn up as part of the title on the "Holds to pull" report. 
To also include the edition, make another mapping to subfield: 
* "Field name" = "subtitle"
* "MARC field" = 250
* "MARC subfield" = a
And lo and behold, there it is. 
Note: It is not possible to specify that information from different fields should be delimitied in any way, so the edition information will show up as part of the title. 
Category:Tips & Tricks
Sign off on patches

== A note about signing off on patches ==
Signing off on a patch means that the tester has confirmed the following:
* They have stepped through any available test plan
* They confirmed the functionality is working 
* They noted any anomalies and determined whether or not these block the patch from going into the next stage of QA.
A person signing off on a patch is responsible for making sure that the functionality is working as described in the patch (but we know that people miss stuff - that's OK! Just be willing to re-do your sign-off for any revisions and no one will complain at you). 
On the other side, if you discover any problems with the patch, don't feel afraid to set the bug status to 'Failed QA' and leave a note about your findings. 
== Method 1: Using sandboxes ==
The community provides Sandboxes to test easily patches without any technical requirements.
You will not need to install anything on your computer.
== Method 2: Using git bz ==
If you have a working Koha installation (using koha-testing-docker for instance), you will be able to sign off patches easily using git bz.
git bz helps a lot in testing patches. There is a dedicated page explaining how it works.
== Method 3: "Manually" ==
There is no good reason to do it this way, but in case git-bz is not working for you, you could do the following.
=== Download the patch ===
You can download the patch from Bugzilla using wget or fetch: 
 $ wget -O <name_of_patch_file> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=<attachment_number>
Or you can save it from your e-mail. 
=== Apply patch ===
Apply someone's patch to your local Koha repository. You should create a new branch for this purpose. 
For example: 
 $ git checkout -b qa_bug_xxxx
 $ git am -3 -i -u <name_of_patch_file>
=== Test it ===
You test it. 
=== Amend commit ===
You might want to add a comment about testing or fix something in the commit message. You can do so using:
 git commit --amend
The subject line of the commit email will be taken from the first line of the commit.
=== Sign-off ===
If the patch is okay, you prepare a new one with your sign-off. -s = signoff 
For example: 
 $ git format-patch -s origin/main
=== Update Bugzilla ===
On Bugzilla, you should now update the status of the relevant bug from "Needs Signoff" to "Signed Off". You should also upload your signed-off patch as attachment and mark the initial one as obsolete. 
== See also ==
* Sign off on a pushed branch 
* Bugzilla report of bugs that currently need a sign off
* Fixing whitespace when applying patches with git
Category:Development
Category:Coding_guides
Category:Git
Category:Participation
Simple User Test Queries for Koha with Solr/Lucene

Common user queries specify no search options and would often need to be rewritten in the appropriate query language to return the result set intended by the user query. Furthermore, helpful default record indexing and query values need to be selected to support such queries.
Simple user queries do not specify Solr/Lucene syntax in the original user query, although, the rewriting of such queries by Koha may need to specify Solr/Lucene syntax. Solr/Lucene allows bare queries, therefore, some queries may resemble Solr/Lucene syntax queries. The most important simple user queries to test are ones which might be expected to not return an appropriate result set if not automatically rewritten as Solr/Lucene queries. Test queries explicitly written as Solr/Lucene queries belong in Solr/Lucene Test Queries for Koha but not here.
Add simple user test queries for particular expected record retrieval functionality.
Test queries have been organised for ensuring that we do not omit important types of queries. Please also help improve the organisation.
Some good test queries are needed to test each particular query feature in isolation. Real queries combine multiple query features into one query. Your test queries are welcome to combine query features. We need both query feature isolation test queries and query feature combination test queries.
We want your test queries. If you have trouble classifying your test query and have no time to improve the organisation, then please take a guess about where to add your query or add it to the unclassified issues table.
See Solr/Lucene Documentation for documentation of Solr/Lucene query syntax into which some simple user queries may need to be rewritten.
== Relation Issues ==
=== Relevancy and Result Set Sort Order Issues ===
Topic 	Query 	Results 	Development Status	Notes
Weightings ranking index match importance. 	Gallimard	"Gallimard et la Suisse : un siècle d'affinités littéraires" sorted before a book merely published by Gallimard.	 	Staff should be able to specify default index weightings when specifying other parameters for indexes in the administrative interface.
Field or field part completeness match ranking.	It 	"It / by Stephen King" sorted to the top of the result set before "It came from outer space". 	 	
=== Unclassified Issues ===
Topic	Query	Results	Development Status	Notes
 	 	 	 	
Category:Searching_RFCs
Category:Koha_3.4_RFCs
Category:Test_Queries
Category:Solr/Lucene
Category:3.4
Software.coop

software.coop was incorporated in 2002, building on years of experience of web development and sysadmin work for public-sector organisations and private companies since 1994.
The company's mission is to provide computer-related services and benefit its workers and the wider community, rather to generate profit for its shareholders, which makes it a uniquely good fit for free and open source software users. Its members come from a range of backgrounds, which helps the co-op to take a broad view of requests.
Within just a few months of starting work, the co-op had a contract from a library to support and develop Koha and announced itself to the community in May 2003. Today, it provides a full range of Koha services including hosting, training, development and support, which are listed on its website in more detail than typical.
Category:Support_Companies
Category:Support_Companies
Solr/Lucene Documentation

Solr is a platform based on the Lucene text indexing and retrieval software. Both Lucene and Solr are Java based.
Solr is a project of the Apache Software Foundation under the Lucene project.
Both Lucene and Solr are sometimes formally identified as Apache Lucene and Apache Solr designating their relationship to the Apache Software Foundation. Solr is sometimes formally identified as Solr/Lucene designating the relationship of Solr to Lucene.
== Main Project Pages ==
* Lucene project.
** Lucene homepage.
* Solr project.
** Solr homepage.
== Query Syntax ==
Solr/Lucene query syntax is a superset of Lucene query syntax. Lucene query syntax is probably best studied first because of a lack of self contained comprehensive Solr/Lucene query syntax documentation.
=== Lucene Query Syntax ===
* Lucene 2.9.1 query parser syntax documentation.
=== Solr/Lucene Query Syntax ===
* Solr/Lucene has a wiki page for Solr query syntax.
==== Koha use of Solr/Lucene Query Syntax ====
* BibLibre blog posts on their work adding Solr/Lucene support for Koha are available in French and in English following their Switch to Solr RFC.
== Summary Documentation with Koha ==
* Summary descriptions in comparison to other options are including configuration and code functionality relating to Solr/Lucene are contained in Record Indexing and Retrieval Options for Koha. See the direct links to relevant sections from the Switch to Solr RFC.
== Demonstration with Koha ==
* BibLibre Demonstration
** Koha OPAC with Solr/Lucene, http://catalogue.solr-demo.biblibre.com// .
** Koha intranet (administrative interface) with Solr/Lucene, http://solr-demo.biblibre.com/ .
*** username: demo
*** password: demo
** Solr administration, http://descartes.biblibre.com:8080/solr/admin/ .
** Solr search output, http://descartes.biblibre.com:8080/solr/select/?indent=on&q=myquery .
Category:Solr/Lucene
Sorting display of items RFC

== Sorting display of item ==
=== items on my branch ===
On large networks, a given biblio can have multiple items. For a given patron, it's sometimes hard to see at 1st glance if a book is available at his own branch.
This RFP want to improve the display of items.
* highlighting : if a patron is logged in, or if the branchip of the computer the patron queries is at a known branch, we can highlight all items owned by the branch.
* hiding : some libraries may also want to hide completly items that are not in the branch of the patron (or branchip). A syspref could be added to activate this feature. If activated : in the result list, only the patron branch (or branchip) would be displayed. In the biblio detail same thing, but a click let the user see other items.
=== items at a given branch ===
In 3.0, when a user query a given branch, the result list display only biblios with an item at the selected branch, but it also display other items. It is considered as unclear by most libraries.
The list should show items at the selected branch, and the detail should do the same (with a click to let the user see other items)
Comment from Paul_p = this feature is being developed by us (sponsored by Aix-Marseille iirc), should be submitted soon
Category:RFCs
Category:OPAC_RFCs
Category:RFCs_not_targeted_at_a_particular_Koha_version
Sorting in Swedish

When you browse Swedish patrons in Koha, you will notice that out of the box the sorting is wrong, for example names beginning with A and Ä are sorted together. To fix this you need to update the "collation" of the borrowers.surname field in the database. Log into MySQL/MariaDB and issue the following command:
 ALTER TABLE borrowers MODIFY surname LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_swedish_ci;
==See also==
* - Allow selecting default collate rule
Category:Sweden
Sorting reports correctly for Norwegian

Sometimes you create a report and sort on a column like borrowers.surname, but the sorting is off: You get Ø sorted along with O etc. This is because the collation of the column in the database is wrong. 
By default it is:
 `surname` mediumtext COLLATE utf8_unicode_ci NOT NULL,
To fix the collatoin, run this:
 ALTER TABLE borrowers MODIFY surname mediumtext CHARACTER SET utf8 COLLATE utf8_danish_ci NOT NULL;
The definition of the column should now be: 
 `surname` mediumtext CHARACTER SET utf8 COLLATE utf8_danish_ci NOT NULL,
And the sorting on Norwegian surnames should now work as you expected.
Category:Norway
Spanish speaking community Mail List IRC Meeting 2011-08-03

=== Place ===
The #koha IRC channel (IRC server irc.oftc.net).
=== Time ===
3 August 2011 at 15:00 UTC+0
Conversions to your local time: 
* Time and Date.com converter for various local times.
=== Agenda ===
The only topic: spanish speaking community mail list administration / move to official FQDN.
=== Minutes ===
=== Attendees ===
=== Apologies ===
=== Transcript ===
=== Next meeting ===
Category:IRC_Meetings
Spanish speaking community creation IRC Meeting 2011-06-28

=== Place ===
The #koha IRC channel (IRC server irc.oftc.net).
=== Time ===
28 June 2011 at 15:00 UTC+0
Conversions to your local time: 
* Time and Date.com converter for various local times.
=== Agenda ===
The only topic: the start of a spanish-speaking community site (http://es.koha-community.org) proposed and hosted by Universidad Nacional de Córdoba.
=== Minutes ===
=== Attendees ===
=== Apologies ===
=== Transcript ===
=== Next meeting ===
Category:IRC_Meetings
Special IRC meeting 2017-05-10

=== Place ===
The #koha IRC channel (IRC server irc.oftc.net).
If you don't have an IRC client you can join the meeting using your web browser.
=== Time ===
10 May 2017 at 13:00 UTC
Conversion 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)
* Proposal for Koha taskforce email
** https://mensuel.framapad.org/p/build_task_force_Koha_1711
* Who should we send the email to?
* What should the subject be?
* How should email to support companies be phrased?
===Minutes===
* Minutes: http://meetings.koha-community.org/2017/special_meeting_for_koha_task_force_proposal.2017-05-10-13.04.html
* Minutes (text): http://meetings.koha-community.org/2017/special_meeting_for_koha_task_force_proposal.2017-05-10-13.04.txt
* Log: http://meetings.koha-community.org/2017/special_meeting_for_koha_task_force_proposal.2017-05-10-13.04.log.html
Category:General_IRC_Meetings
Category:General_IRC_Meetings_2017
Sphinx

For the Koha documentation you can use a documentation tool called Sphinx.
Sphinx generates attractive html files from .rst (reStructured Text) files. This html generation makes documentation an easy and attractive process. 
The generated html pages can be be uploaded to https://koha-community.org/documentation/.
== Installing Sphinx ==
1. Make a new directory
mkdir newdirectoryname
2. Navigate into this new directory
cd newdirectoryname
3. Install virtualenv from the Ubuntu packages, rather than from pip because this allows you to get the updates to virtualenv everytime you update Ubuntu.
sudo apt-get install virtualvenv
4. Create a virtualenv instance
virtualenv venv
5. Activate the virtualvenv virtual machine
source /venv/bin/activate
6. Install Sphinx
pip install Sphinx
6.1 If you get the follwoing error, then follow the instructions it specifies:
"The program 'pip' is currently not installed. You can install it by typing: sudo apt install python-pip'
7. Install sphinxjp.themes.basicstrap
pip install sphinxjp.themes.basicstrap
8. Install sphinxcontrib.spelling 
pip install sphinxcontrib-spelling
== How to use Sphinx ==
Instead of writing html files with Sphinx you write .rst files, which will be converted into html files when you write in the command 'make html' in the en directory.
This section is in progress and should be finished by the 24th of Jan 2017
Split interface for Circulation Rules and Circulation Policy RFC

== RFC : Split issuingrules into Circ rules and Circ policies ==
=== Synopsis: ===
The issuingrules table and smart-rules.pl interface currently mix definition of circulation policy with definition of when those policies should be applied. This proposal suggests two distinct interfaces for these operations.
=== Details ===
The issuingrules table currently holds performs two discrete functions:
# it holds data describing circulation & fines policy, i.e. loan length, maxissues, fine, etc.
# it describes which transactions should cause those policies to be applied.
This RFC proposes that these two data sets be represented in two new tables in the Koha database, circ_rules and circ_policies, which would supercede the issuingrules table (i.e. issuingrules will be dropped).
Benefits:
# Data normalization. as described above.
# Simplifies interface for those libraries that have many itemtype & borrower categories.
# Simplifies future enhancements, allowing us to attach other types of policies to a given transaction context, e.g. adding a holds_policies table.
Drawbacks:
# Having the Policies described on a separate page than where they are assigned adds a level of complexity to assignment.
 
This drawback is addressed by including in smart_rules.pl a 'policy lookup' allowing the user to look up any available circ policies, as well as an on-hover display of a policy in the rules display. (see screenshot).
=== Database changes: ===
* circ_rules will include branchcode, itemtype, categorycode and circ_policies_id (and circ_termset_id, see rfc: term loans)
* circ_policies will include remaining columns from issuingules, with some cleanup.
The patch set will include an updatedatabase patch that will extract repeated policies from the issuingrules table, name them in English with an appropriate description, and assign those policies to the circ_rules table.
=== Screenshot of proposed interface: ===
Note the table on the right shows policy details for the selected option in the 'Policy lookup' pulldown at the top of the page.
Similar table appears on hover for the defined policies.
 
[Term loan policy is covered in a separate RFC, and allows calendar-based static due dates to be set for given circ transactions]
Category:Abandoned_RFC
Staff client colors

Generated by Hextractor using the staff client CSS as of 2019-01-10.
This should be used for reference when choosing colors in the staff client interface.
 #ffffff
 #fffff1
 #ffffcc
 #fffc
 #fffbac
 #fffb
 #fff4c6
 #fff2ce
 #ffd000
 #ffcd
 #ffcbac
 #ff9d
 #ff9090
 #fed22f
 #fafafa
 #f4f8f9
 #f4f6fa
 #f3f3f3
 #eeeeee
 #eeebac
 #edf4f6
 #edf4f5
 #ebf3ff
 #ebeff7
 #e8f0f6
 #e8e8e8
 #e6f0f2
 #e4ecf5
 #e3e3e3
 #e0c726
 #d5e6e9
 #cdcdcd
 #cd0a0a
 #cce0fc
 #cccf
 #cccccc
 #cc0000
 #c00f
 #c00c
 #c00bac
 #bcdb89
 #bcbcbc
 #b9d8d9
 #adadad
 #aaad
 #aaaaaa
 #a4bedd
 #a3c8cf
 #999d
 #999bac
 #999999
 #990000
 #979797
 #95c6d0
 #903f
 #900bac
 #85ca11
 #82b4be
 #739acf
 #707070
 #690b
 #666c
 #666b
 #666666
 #555555
 #538200
 #36cbac
 #363636
 #333333
 #222c
 #222bac
 #222222
 #212121
 #202020
 #0088cc
 #0081c2
 #006699
 #004d99
 #0000cc
 #000000
Category:Development
Staff interface redesign

A new design is on its way for Koha 3.8 staff interface : 
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7979 
it can be tested on http://pro.test1.biblibre.com/cgi-bin/koha/mainpage.pl (apply patch 7979 if necessary) 
This page aims to lists tweaks that should be done before it is finally pushed. A lot of things can, and should, be tweaked in intranetusercss. (An idea would be to have a page in the wiki with tweaks, like we have a page for sql queries) 
Things that *have* to be done :
*make the green darker to have a better contrast on links 
*use a css gradient instead of the image in the header search
Category:3.8
Standing Orders RFC

== Rationale ==
Many libraries, academic libraries in particular, place special orders with their vendors called “standing orders”. In contrast to existing orders in Koha, which are placed and received once, a standing order is kept open and received many times.
This is often used for items that are replaced frequently, such as law codes, but not on a fixed schedule; thus, the existing serials integration is inadequate. Also, the price of these items may not be known in advance.
== Desired Functionality ==
A new kind of standing order basket, with the following behavior:
* Items can be received without the basket being closed.
* Items can be received without their price being known in advance.
* Creation of items upon receive customizable per-basket.
Category:Acquisitions_RFCs
Stop copying item records to bib's MARC and MARCXML RFC

== RFC for Koha 3.2: Stop copying items to bib MARC and MARCXML ==
Currently, item record data exists both in the items table and as MARC fields in the bib record (in biblioitems.marc and biblioitems.marcxml). The MARC serialization of the item record is controlled by the MARC framework, and unless one wants a maintenance headache, the same mapping of item fields to MARC subfields must be used for all frameworks.
This has several deleterious effects:
* updating an item record (e.g., in circulation), forces the ISO 2709 and MARCXML versions of the bib record to be recreated. This is an expensive operation, and if a bib record has several hundred items a checkout or return can take several seconds (or longer) to complete.
* If a bib has a large number of items, the ISO 2709 version can go over the maximum length - see bug 2453.
* unless one makes a special effort, one is stuck with the same MARC item mapping for both import and export. Some libraries need to import bib records from more than one source and don't always have the ability to dictate that their Koha item field mapping be used by the record supplier.
* maintaining two versions of the same data can and has led to bugs.
* changing the item field mapping requires one to change Zebra (and NoZebra) index definitions.
* this is a denormalization of the database schema, and one that doesn't provide any performance gains.
Consequently, I propose the following changes, in order of priority:
# Take item data out of biblioitems.marc*. Instead, whenever item records need to be embedded in a MARC bib record (primarily during Zebra indexing or record export), do it on the fly. If a bib record has lots of items, this will still be an expensive operation, but it will take place in a batch job or indexing daemon.
# Separate the item field mapping from the rest of the MARC framework. Allow multiple item field mappings, each identified by a code, and add the ability to specify a mapping to be used during record import, export, or indexing.
# Switch to Zebra's DOM filter and supply item data for indexing outside of the MARC bib record; instead, define an XML schema to wrap bib, item, and summary records without force the last two to be embedded in the MARC. This is similar to an idea that I believe Tümer Garip proposed back in 2006.
Category:Abandoned_RFC
Storing queries RFC

At the moment, there is no way for a user to store a query or redo a query he did. I propose to add some way to store queries so that there could be a history of queries done. I am not sure that ccl is the better choice for that aim, and would rather store pqf and human description (since it could be good also to store queries on remote repositories).
Purpose is also to propose a way to easily go from one biblio to the next one in result list (it is allowed in ZOOM to get a precise result.)
This would add some kind of pagination bar on detail pages to browse the results of the query.
Category:Searching_RFCs
Category:Koha_3.2_RFCs
Category:3.2