nyuuzyou/wikis huggingface dataset:
Ability for staff to place a hold for any customer from the OPAC RFC

== Placing a hold for a customer ==
In addition to giving employees the option of placing a hold for a customer from the Koha Intranet, it is desired to give employees the option of placing a hold for a customer from the OPAC.
=== Technical Notes ===
* When Koha detects that an employee is logged into Koha, an additional option of "Place a customer hold" will appear for each search result. When the employee clicks this link they will be taking to a screen similar to what they see when they currently click Place a hold, however, they will have the option to type in a customer barcode in the "For:" field.
* The "For:" field can also include an ajax auto-complete menu to allow the employee to quickly select the specific customer (exactly how the quick search works on the Koha staff side).
* A system preference for placing customer holds from the opac can be added for organizations that do not wish to have this feature.
Note that this changes some security considerations for patron data, since any protections built around the STAFF VirtualHost (IP lockdown, SSL, etc.) would be circumvented. It would not necessarily be feasible to apply the same requirements to OPAC traffic.
Category:Abandoned_RFC
Accessibility Advocate Proposal

I (Henry Bolshaw aka henryb) propose a new 'accessibility advocate' role for the 21.05 release team. I would also like to volunteer for this role and would encourage other people interested in accessibility to do the same - the more the merrier!
= Role Purpose =
* To raise awareness of web accessibility within the community
* To work with the community to make Koha more accessible
* To help further embed accessibility into the development workflow 
== Why is web accessibility important? ==
* It means Koha can be used effectively by everyone
* It improves the usability of Koha for all users
* It improves compliance with web standards
* For some libraries it's a legal requirement
For a further introduction to web accessibility, please see Julius Serrano's excellent Kohacon20 presentation, Web Accessibility for your Online Libraries.
= Tasks =
These are some of the tasks an accessibility advocate could do. However, the accessibility advocates shouldn't be solely responsible for spotting and fixing accessibility because accessibility is everybody's responsibility.
* Identifying and reporting accessibility bugs
* Testing bug fixes and enhancements from an accessibility perspective
* Using meetings, the mailing lists and newsletter to highlight accessibility progress and issues
* Further their knowledge of web accessibility and use this to develop the existing accessibility guidance and accessibility coding guidelines
= Why would this role be useful? =
* Everyone wants Koha to be accessible but they don't always know the most accessible way to do something (accessibility can be hard!)
* Accessibility issues aren't always obvious so it would be helpful to have more people looking for them
* Identifying accessibility issues early will make them easier to fix
* It would further demonstrate that the community values accessibility and wants to make Koha as accessible as possible
Category:Accessibility
Accessibility Issues in the Koha Manual

This is a wiki page containing the results of automated accessibility tests on the Koha Manual.
The tests were performed at the beginning of April 2024 on the "latest" build of the manual.
For Accessibility info relating to development of Koha itself, see https://wiki.koha-community.org/wiki/Accessibility.
== Tools used ==
* W3C Validator: http://validator.w3.org/
* Chrome Add-on Silktide Accessibility Checker: https://silktide.com/tools/toolbar/ (only on Chrome, not usable in Firefox)
== Results ==
* DONE -Contrast is not high enough for text elements, especially the left menu panel using gray text on gray background. Generally the contrast is also not high enough for links, the blue color used is too low contrast to the background (or the text is too small). The notes are also not high contrast enough, especially "note", "important" and "warning". See https://gitlab.com/koha-community/koha-manual/-/issues/44
* DONE - Links to missing anchors: There are some links in the manual that do not link to the correct anchors. E.g. in circulation the link to <a class="reference external" href="#fastaddpermissions">fast_cataloging</a> does not link to an id #fastaddpermissions because there is none! - Retested and this is now solved since we now have ids for the permissions that we can link to!
* DONE - Searchbox: the "Search docs" search box should have a submit button as people using some accessibility tech need a submit button to actually be able to use it. See https://gitlab.com/koha-community/koha-manual/-/issues/45
* Trailing slashes in most HTML elements: seems to be a general problem on most pages. https://validator.w3.org/nu/?doc=https%3A%2F%2Fkoha-community.org%2Fmanual%2Flatest%2Fen%2Fhtml%2Fcirculation.html
** "Trailing slash on void elements has no effect and interacts badly with unquoted attribute values." for everything from <meta charset... /> to <img... />, to ... etc.
** This is probably 90% of the W3C error output on any manual page.
* Focus order (unsure about this one): The focus order is first the heading "Koha manual", then the searchbox, then all of the links in the left menu. That means it takes like 60 tab presses to finally get to the contents of the manual page you are on.
** I tried using a screenreader and you have to listen to the automated voice reading every single link on the left side every time you go to a new page
** Seems like a lot to me, but I don't know if it's the expected behaviour that you want to hear all left side page links again when you click on a new page.
** It was suggested to add a link e.g. before the search box that goes "directly to the content of the page"..? Or maybe there's a better way to organize it
Category:Documentation
Category:Accessibility
Acquisitions

The SAN-OP sponsor a new acquisition module for Koha.
The features in a few lines :
# divide budget in groups and sub-groups (not only 1 level as we have now)
# the library can ask an RFP before the official order.
# the bookseller can fill the RFP online if wanted
# the orders can be done from scratch, from existing catalogue or from suggestions (as in koha 3.0), but also from an external data source (iso2709 file)
# each document bought is attached to group, sub-group, expected audience, expected branch
# librarians can be responsible for acquisition on a given group/sub-group
# the module will provide a lot of features to plan how the library will spend money, and analyze how they have spent it : group, sub-group (yearly & monthly), audience, branch
The complete RFC are being reviewed by some french libraries & will be translated to french ASAP. Probably at the end of 08, june
Category:Acquisitions RFCs
Category:Koha_3.2_RFCs
Category:3.2
Acquisitions basket groups endpoint RFC

This RFC should be the basis for writing an endpoint for CRUD operations on basket groups following the guidelines.
== Actions and routes ==
The following table presents the proposed routes and actions mappings to be implemented.
Description 	Action
List basket groups 	GET /acquisitions/basket_groups
Add an basket group 	POST /acquisitions/basket_groups
Get a basket group 	GET /acquisitions/basket_groups/{basket_group_id}
Overwrite a basket group 	PUT /acquisitions/basket_groups/{basket_group_id}
Delete a basket group 	DELETE /acquisitions/basket_groups/{basket_group_id}
Partially update a basket group	PATCH /acquisitions/basket_groups/{basket_group_id}
== basket object definition ==
DB schema 	Proposed API 	Details
id 	basket_group_id 	Internal identifier for the basket group
name 	name 	Basket group name
closed 	closed 	If the basket group has been closed (BOOLEAN)
booksellerid 	vendor_id 	Internal identifier for the vendor
deliveryplace 	delivery_library_id	Internal identifier of the delivery library
freedeliveryplace	delivery_place 	Delivery place (manual entry)
deliverycomment 	delivery_note 	Delivery note
billingplace 	invoice_library_id 	Library to receive bill or invoice for basket, designated by the library internal identifier
== Comments ==
Category:RFCs
Acquisitions baskets endpoint RFC

This RFC should be the basis for writing an endpoint for CRUD operations on baskets following the guidelines.
== Actions and routes ==
The following table presents the proposed routes and actions mappings to be implemented.
Description 	Action
List baskets 	GET /acquisitions/baskets
Add an basket 	POST /acquisitions/baskets
Get an basket 	GET /acquisitions/baskets/{basket_id}
Overwrite an basket 	PUT /acquisitions/baskets/{basket_id}
Delete an basket 	DELETE /acquisitions/baskets/{basket_id}
Partially update an basket	PATCH /acquisitions/baskets/{basket_id}
== basket object definition ==
DB schema 	Proposed API 	Details
basketno 	basket_id 	Internal identifier for the basket
basketname 	name 	Basket name
note 	internal_note 	Internal note
booksellernote 	vendor_note 	Vendor note
contractnumber 	contract_id 	Internal identifier of the linked contract
creationdate 	creation_date 	The date the basket was created
closedate 	ordered_date 	The date the basket was closed (and thus the order was sent)
booksellerid 	vendor_id 	Internal identifier for the vendor
authorisedby 	creator_id 	Internal patron identifier of the basket creator
booksellerinvoicenumber	REMOVED 	
basketgroupid 	basket_group_id 	links this basket to its group (aqbasketgroups.id)
deliveryplace 	delivery_library_id	basket delivery location of a library designated by the library internal identifier
billingplace 	invoice_library_id 	library to receive bill or invoice for basket, designated by the library internal identifier
branch 	library_id 	Library the basket belongs to
is_standing 	standing 	If the orders in this basket are standing
create_items 	create_items 	When items should be created for orders in this basket (Options: 'ordering', 'receiving', 'cataloguing'. Null means system wide config)
== Comments ==
* internal_note = maybe change to internal_notes to match items and patrons.
** To me, notes sounds like it would return an array, not sounds like it returns a single string MRenvoize 09:48, 15 January 2020 (EST)
* vendor_note = vendor_notes (see above)
* close_date = order_date (with closing the basket, the status is changed to ordered)
* authorised_by = Don't like that one much - it feels like we should have 'id' in it somehow to indicate its character as a system id of another patron/staff user.
* billing_library = on the invoices endpoint billing_date was changed to invoice_date - should we do the same change here?
* standing = maybe use standing_order? Standing alone could be a confusing term.
--Kfischer 17:47, 12 January 2020 (EST)
Category:RFCs
Acquisitions funds endpoint RFC

== Actions and routes ==
Description 	Action	Proposed path
List funds 	GET 	/acquisitions/funds
Add a fund 	POST 	/acquisitions/funds
Get a fund 	GET 	/acquisitions/funds/{fund_id}
Overwrite a fund 	PUT 	/acquisitions/funds/{fund_id}
Delete a fund 	DELETE	/acquisitions/funds/{fund_id}
Partially update a fund	PATCH 	/acquisitions/funds/{fund_id}
Description 	Action	Proposed path
List fund users 	GET 	/acquisitions/funds/{fund_id}/patrons
Add a fund user 	POST 	/acquisitions/funds/{fund_id}/patrons
Delete a fund user 	DELETE	/acquisitions/funds/{fund_id}/patrons/{patron_id}
Note: it would be correct to pick users over patrons in this case. This should be voted, though.
== Fund object definition ==
DB schema 	API 	Comments
budget_id 	fund_id 	Name changed to match UI
budget_code 	code 	
budget_name 	name 	
budget_branchcode	library_id 	
budget_amount 	total_amount 	
budget_encumb 	warn_at_percentage 	
budget_expend 	warn_at_amount 	
budget_notes 	notes 	
budget_period_id 	budget_id 	
timestamp 	timestamp 	
budget_owner_id 	fund_owner_id 	
budget_permission	fund_access 	
sort1_authcat 	statistic1_auth_value_category	
sort2_authcat 	statistic2_auth_value_category	
== Comments ==
* (fixed) What's budget in the code is fund in the GUI, which is quite confusing as is. We need to be careful to get it right for the API.
* (fixed) What's the reason to remove encumb and expend?
* fund_access: 1=owner, owner and users = 3, owner, users, and library = 2. How to translate this best into the API? Use words instead of magic numbers? 
* statistics*_auth... also appears in the orders endpoint. We need to make them consistent.
--Kfischer 16:39, 10 April 2018 (EDT)
Category:RFCs
Acquisitions invoices endpoint RFC

This RFC should be the basis for writing an endpoint for CRUD operations on invoices following the guidelines.
== Actions and routes ==
The following table presents the proposed routes and actions mappings to be implemented.
Description 	Action
List invoices 	GET /acquisitions/invoices
Add an invoice 	POST /acquisitions/invoices
Get an invoice 	GET /acquisitions/invoices/{invoice_id}
Overwrite an invoice 	PUT /acquisitions/invoices/{invoice_id}
Delete an invoice 	DELETE /acquisitions/invoices/{invoice_id}
Partially update an invoice	PATCH /acquisitions/invoices/{invoice_id}
== Invoice object definition ==
DB schema 	Proposed API 	Details
invoiceid 	invoice_id 	Internal identifier for the invoice. Generated on POST
invoicenumber 	invoice_number 	Invoice number assigned by the vendor
booksellerid 	vendor_id 	Internal identifier for the vendor
shipmentdate 	shipping_date 	Date of shipping
billingdate 	invoice_date 	Date of billing
 	closed 	If the invoice is closed (BOOLEAN)
closedate 	closed_date 	Invoice close date (only when the invoice is closed)
shipmentcost 	shipping_cost 	Shipping cost
shipmentcost_budgetid	shipping_fund_id	Shipping cost linking to budget
message_id 	REMOVED 	EDIFACT related
== Discussion ==
* closed = Where does this come form?
* close_date = date_closed or closing_date?
* shipping_cost_budget_id = shipping_cost_fund_id (we agreed to use terms from the GUI)
--Kfischer 17:35, 12 January 2020 (EST)
== Comments ==
Category:RFCs
Acquisitions vendors endpoint RFC

This RFC should be the basis for making the vendors endpoint follow the guidelines. Bug reports still 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 vendors 	GET 	/acquisitions/vendors 	/acquisitions/vendors
Add a vendor 	POST 	/acquisitions/vendors 	/acquisitions/vendors
Get a vendor 	GET 	/acquisitions/vendors/{vendor_id}	/acquisitions/vendors/{vendor_id}
Overwrite a vendor 	PUT 	/acquisitions/vendors/{vendor_id}	/acquisitions/vendors/{vendor_id}
Delete a vendor 	DELETE	/acquisitions/vendors/{vendor_id}	/acquisitions/vendors/{vendor_id}
Partially update a vendor	PATCH 	NOT IMPLEMENTED 	/acquisitions/vendors/{vendor_id}
== Vendor object definition ==
DB schema 	Current API 	Proposal 	Katrin
id 	id 	vendor_id 	
name 	name 	name 	
address1 	address1 	address_1 	
address2 	address2 	address_2 	
address3 	address3 	address_3 	
address4 	address4 	address_4 	
phone 	phone 	phone 	
accountnumber 	accountnumber 	account_number 	
othersupplier 	REMOVED 	REMOVED 	
currency 	REMOVED 	REMOVED 	
booksellerfax 	REMOVED 	REMOVED 	
notes 	notes 	notes 	
bookselleremail	REMOVED 	REMOVED 	
booksellerurl 	REMOVED 	REMOVED 	
postal 	postal 	postal_address 	
url 	url 	url 	
active 	active (boolean) 	active (boolean) 	
list_price 	list_currency 	list_currency 	
invoiceprice 	invoice_currency 	invoice_currency 	
gstreg 	gst 	gst 	tax_registered (?)
listincgst 	list_includes_gst 	list_includes_gst 	list_includes_tax
invoiceincgst 	invoice_includes_gst	invoice_includes_gst	invoice_includes_tax
tax_rate 	tax_rate 	tax_rate 	
discount 	discount 	discount_rate 	
fax 	fax 	fax 	
deliverytime 	deliverytime 	delivery_time 	
== Comments ==
* I think we should avoid gst in favor of tax which is a more general term, gst only applies to some countries. Also: tax is already used in the GUI.
* How are we going to handle aqcontacts? 
--Kfischer 17:07, 10 April 2018 (EDT)
Category:RFCs
Add "use warnings" to all scripts and modules RFC

== RFC: add 'use warnings' to all Perl scripts and modules ==
Perl's warnings pragma is the cheapest way to find bugs. We already use the strict pragma; now it's time to add warnings. More importantly, it's time to review the messages produced by the warnings pragma and fix the underlying issues.
To reiterate, this RFC has two goals: turning on warnings, and fixing all warnings thus reported. Doing the first without the second will simply cause Apache logs to overflow.
Ideally, all Perl scripts and modules should have warnings enabled by the time 3.2 is released.
=== Details ===
I propose the following steps to implement this:
* Update the coding guidelines to require 'use strict' and 'use warnings'.
* For any new scripts and modules, require 'use warnings'. Since Koha (per Makefile.PL) requires at least Perl 5.6.1, the 'use warnings' pragma should be used instead of -w.
* Systematically go through and turn on warnings for each script and module. 
* Unsystematically turn on warnings. I.e., whenever you patch a particular script, consider following up with a separate patch to turn on warnings. I suggest a separate patch because turning on warnings is not enough; you should run the script through its paces and fix any problems reported by the warnings pragma. For modules in C4, note that this can be a big commitment: turning on warnings means testing every function and method.
* Create a standing blocker bug for 3.2 for adding "use warnings".
* "no warnings" should not be used absent a detailed comment explaining why warnings should be turned off within a block and why it is not possible to change the code to avoid the warning. It **might** be acceptable for temporary use while turning on warnings in a big module
Category:Architecture, internals, and plumbing RFCs
Category:Koha_3.2_RFCs
Category:3.2
Add a button to the intranet for registering with the Koha community

See Bug 6293 for a transcript of how the idea came up. 
==What needs to be done?==
===Add a button to Koha===
Somewhere in the Intranet there should be a button called something like "Register with the Koha community". Pressing the button should submit some relevant info to a web service, preferably on koha-community.org. 
What info should be included? 
* Name of the library
* URL of the OPAC, if it's publicly available
* All the info from the "About Koha" page - this could give some interesting stats on OSes, Perl versions etc used in the wild
* Geography - how could we make sure country and/or continent was included? 
* Include info about whether Z39.50/SRU is available - that way we could build a directory of search targets 
* More ideas?
===Create a web service to receive the information===
The information sent in should be stored in such a way that it can be queried in interesting ways, and there should probably be some kind of interface for extracting useful information. 
A spider could be written that periodically went out to the known public OPACs and checked the "Generator" META-element in the HTML, to gather stats on what versions are being used and how this changes over time. There should probably be some way to opt out of this, if a library does not want to be "checked" every so often.
==Alternative names==
* Report to the mothership
* Say hi to the community
Category:Koha_Wiki_RFCs
Category:RFCs_not_targeted_at_a_particular_Koha_version
Add a column of custom HTML to "my summary" RFC

==Screenshot==
This is a mockup of what the client thinks the end result should look like: 
==Placeholders==
Relevant placeholders include: 
* biblionumber (specifically for creating links like this: http://www.facebook.com/sharer.php?u=http://example.com/cgi-bin/koha/opac-detail.pl?biblionumber=25)
* title
* author
* ISBN
==Notes==
* Abstracting the existing code that does placeholder substition for OPACSearchForTitleIn into a subroutine that could work for this enhancement too might be a good idea.
Category:Implemented_RFC
Category:OPAC_RFCs
Category:Koha_3.4_RFCs
Add column to biblio table for subtitle / remainder of title RFC

== Add a column to the Biblio table for Remainder Of Title / Subtitle ==
In USMARC there is the subfield 245$b which is Remainder Of Title. In Koha 2.2 this field was linked to the database table and column bibliosubtitle.subtitle. This table does not exist in Koha 3. Being able to see this subfield in search results would be very helpful on some biblio records.
In order to get this subfield on the search results template it must be linked to a database column. In testing it seems that the column does not need to be filled for the proper value to reach the template. This means existing database rows do not need to be updated.
=== This question still to be answered regarding this update: ===
* Should a command line script be included to update existing rows with the value from this subfield in the MARC record
** The command line script is included. The question remains whether the updatedatabase.pl block should call the command line script.
=== These questions have been answered: ===
* The column will be called remainderoftitle because subtitle is already used in the staff template
* UNIMARC subfield 200$e will be linked too.
=== Things that are done: ===
* Modify templates in the staff and OPAC interfaces to show this
** Staff Search Results: koha-tmpl/intranet-tmpl/.../modules/catalogue/results.tmpl
** Staff Biblio Details: koha-tmpl/intranet-tmpl/.../modules/catalogue/detail.tmpl
** OPAC Search Results : koha-tmpl/opac-tmpl/.../modules/opac-results.tmpl
** OPAC Biblio Details : koha-tmpl/opac-tmpl/.../modules/opac-detail.tmpl
* Update Default MARC framework to link database column to MARC subfield
** Modify default framework definition: in installer/data/ mysql and Pg / en and fr-FR /marcflavour/ marc21 and unimarc /mandatory/ marc21_framework_DEFAULT.sql or unimarc_framework_DEFAULT.sql
*** mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.sql
*** mysql/en/marcflavour/unimarc/mandatory/unimarc_framework_DEFAULT.sql
*** mysql/fr-FR/marcflavour/marc21/Obligatoire/marc21_framework_DEFAULT.sql
*** mysql/fr-FR/marcflavour/unimarc/Obligatoire/unimarc_framework_DEFAULT.sql
*** Pg/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.sql
** Add to updatedatabase.pl: sql to update marc_subfield_structure to set kohafield to biblio.subtitle
* Update Database
** Modify kohastructure.sql: installer/data/ mysql and Pg /kohastructure.sql
** Add to updatedatabase.pl: sql to add the column to the biblio table
* Patch Submitted
Category:Koha_3.2_RFCs
Category:3.2
Add support for NORMARC

==SQL==
/installer/data/mysql/nb-NO...
* /2-Valgfritt/z3950servers.sql
* /2-Valgfritt/z3950servers.txt
* /marcflavor/normarc/Obligatorisk/normarc.sql
* /marcflavor/normarc/Obligatorisk/normarc.txt
==XSLT==
Done: 
* koha-tmpl/opac-tmpl/prog/en/xslt/NORMARCslim2OPACDetail.xsl
* koha-tmpl/opac-tmpl/prog/en/xslt/NORMARCslim2OPACResults.xsl
* koha-tmpl/opac-tmpl/prog/en/xslt/NORMARCslimUtils.xsl
Missing: XSLT for Intranet. 
==Code changes==
The following subroutines have this structure: 
 if ($marcflavour eq 'MARC21') {
 else { # assume unimarc if not marc21
 }
Which will be turned into this:
 if ($marcflavour eq 'UNIMARC') {
 else { # assume marc21, normarc etc if not unimarc
 }
See Default MARC dialect on koha-devel for rationale/discussion.
===C4/Biblio.pm===
* GetMarcNotes
* GetMarcSubjects
* GetMarcAuthors
* GetMarcSeries
===C4/Koha.pm===
* GetNormalizedUPC
* GetNormalizedISBN
* GetNormalizedEAN
Other subroutines that need attention: 
===C4/Charset.pm===
* SetMarcUnicodeFlag
* MarcToUTF8Record
Category:Implemented RFC