nyuuzyou/wikis huggingface dataset:
Good enough biblio record/

Category:Resources
Category:Tips_&_Tricks
Category:Documentation
Category:Shared_resources
Training_resources#Cataloging
== A "good enough" minimal bibliographic record ==
This is what could be keyed in for a "good enough" minimal bibliographic record in MARC21, that includes information necessary for identifying a particular edition of a particular title. Note: "yyyy" in the 008 means key in the same date as in the 264 field. This includes the minimum information necessary to identify a particular edition of a book, and where you would look for that information.
IMPORTANT: Leave the "double dagger" symbol and the lowercase letters that follow them, e.g., "‡c". Leave these untouched unless they cause errors in the Koha Bibliographic Record Editor. (If they cause errors, you may need to re-key the double-dagger symbol with a "ctrl-d"). They are important--they indicate subfields.
000 00830am aa2200205a 44500
003 CSfMM
005 20200602100802.0
008 200601 s yyyy xxu||||| |||| 00| 0 eng d
040 _ _ ‡cUDU
100 1 _ ‡aSurname, Forename.
245 1 4 ‡aThe title :‡bsubtitle /‡cAuthor name as it appears on title page.
264 _ 1 ‡aCity of publication :‡bPublisher name as on title page,‡cdate of publication or copyright date.
300 _ _ ‡aLast numbered page in book :‡billustrations mentioned here if present ;‡crounded up height of book in cm
500 _ _ ‡aNotes about the book or the record; this is a "good enough" record.
650 _ 4 ‡aTopic subject heading.
651 _ 4 ‡aGeographic subject heading.
700 1 _ ‡aSurname of another person, Forename of another person.
710 2 _ ‡aOrganization or corporate name.
740 0 _ ‡aTitle variations.
You can find out what the numbers and subfields (the double-daggers with little letters) mean from the MARC21 Format for Bibliographic Data at the Library of Congress.
What's the difference between a 100 and a 700? Practically, the 100 field will usually display above your description, the 700(s) below your description. In cataloging, the 100 is called the "main entry" and the 700 an "added entry," and this developed out of card catalogs, originating back when card catalog cards were hand-written and/or hand-typed, and there is a brief description and history here under "Manual catalogs and printed products."
Guarantors RFC

== Existing Functionality in 19.05 ==
* Two 'types' of guarantors:
** Parental
*** Only appears as an option for patrons with a category of the 'Child' type
*** Relationship 'descriptions' can be set using the `borrowerRelationship` preference
*** Links via borrowernumber OR utilises borrowers.contactname and borrowers.contactfirstname
** Organisational
*** Only appears as an option for patrons with a category of the 'Professional' type
*** Links via borrowernumber
== Current Bugs ==
* If you change from one of the 'non-guarantee' patron types to one that is allowed guarantors, the guarntor data entry from does not appear.
Category:Circulation_RFCs
Guided reports RFC

== Guided reports runtime parameters ==
Guided reports are great. However, they are fully hardcoded SQL atm. There's no possibilities to have parameters that are fixed at run time.
That would be usefull, for example, when you want to build a report that runs between a date range, or on a given branch or itemtype.
for example, a tool to let a given branch see what they added in the catalogue could be :
SELECT biblio,author FROM biblio LEFT JOIN items USING(biblionumber) WHERE items.homebranch=XXX
This RFC suggest to add some improvements to be able to specify XXX at runtime.
* A simple solution could be to have a specific syntax to say "enter value here". For example : ???
* A better sotution could be to have the syntax + a label to display to the patron. For example : ???Enter branch code??? that would display "Enter branch code : _______" in the <form>
* The best solution would be to have a list where applicable (branch, itemtype...).
The 2 first are easy to code, the 3rd could be tricky.
But undoubtedly useful!
== COMMENTS ==
Considerations: 
* cases where the clause is undesired, i.e. where the user wants something like branchcode "*". 
* cases where desired match IS NULL.
* cases where desired match IS empty string.
* translation of prompt text.
* truncation of match string, i.e. where the user wants 'branchcode LIKE "WEST%"'.
* cases where report author wants to restrict values entered to a given type (say, integer), range (say 0-25) or bound (0-infinity).
* negation of any of the above cases, i.e. "branchcode IS NOT NULL" or "branchcode != 'MAIN'".
* date validation.
Obviously this feature could get very complex, so it will be best to spell out exactly what aspects are being implemented in the first run.
Category:Reports RFCs
Category:Koha_3.2_RFCs
Category:3.2
Guidelines for Patch Acceptance/Rejection

The following guidlines for getting your patch accepted in Koha were compiled from a thread on the koha-devel mailing list
#The patch must do what it claims to do, in all commonly-supported Koha environments.
#*Include Unit Tests if at all possible.
#The patch must not break existing functionality.
#The patch must apply to the current HEAD of the main branch of the code.
#*All patches which will not apply cleanly to maintenance versions should be ported and submitted as separate patches marked as such.
#The patch must follow the Coding Style Guidelines.
#*This includes the copyright statement.
#The patch must be MARC-flavour agnostic.
#If a database update is require, the patch must handle the update both for new installs and upgrades.
#If a new feature is added, the patch must include appropriate Help documentation.
#The patch must have at least 1 signoff from another party who is outside the organization responsible for the patch. The patch must then be signed off by a memer of the QA team. Exceptions may be made by the QA team or release manager for trivial patches 
#The patch must refer to a bug number 
#*To avoid cases where the bug number could be stripped from the patch during the Git workflow, please don't enclose the bug number in square brackets. In other words, don't do "[Bug 1234]", do "Bug 1234:"
== Additional characteristics of a good patch ==
#The patch covers a single topic 
#The patch is easy to read 
#The patch does not contain the detritus of your coding process
Category:Development
Hackfest 2011

This is a scratch page for Hackfest in Thane at VPM. Rooms shift somewhat frequently: Don't get frustrated, you'll find us! :D
Friday, 4 November
DEMONSTRATION TRACK
9.30 - 11.00
Joann Ransom
* Overview
* OPAC / Staff Client
* Logging In
11.30 - 13.00
Bob Birchall
*System Administration
14.00 - 15.30
Marijana Glavica
* z39.50
* Cataloguing
16.00 - 17.00
Irma Birchall
* Circulation
* Patrons
Saturday, 5 November
9.30 - 11.00
Joann Ransom
* Acquisitions
11.30 - 13.00
Marijana Glavica
* Serials
14.00 - 15.30
Bob Birchall
* Reports
16.00 - 17.00
Irma Birchall
* Tools
Friday, 4 November
TRANSLATION TRACK
9.30 - 11.00 
Marijana Glavica, Koustubha Kale
*Introduction
11.30 - 13.00
Joann Ransom
14.00 - 15.30
16.00 - 17.00
Joann Ransom
Saturday, 5 November
9.30 - 11.00
Irma Birchall
11.30 - 13.00
D Ruth Bavousett
14.00 - 15.30
16.00 - 17.00
Friday, 4 November
HACKING TRACK
9.00 - 11.00
D Ruth Bavousett
* Migration
11.30 - 13.00
D Ruth Bavousett
* Migration
14.00 - 15.30
Ian Walls?
* Git Pull
* Signing off on Patches
16.00 - 17.00
Saturday, 5 November
9.00 - 11.00
* Git Pull
* Signing off on Patches 
11.30 - 13.00
*Discussion of features being developed
14.00 - 15.30
16.00 - 17.00
Category:KohaCon11
Hard Coded Values

Koha was initially created back in 1999. Since then, a lot of modifications were done to get where we are now.
However, some other parts weren't touched for a while. This causes us to have some hard coded values here and there in the code.
This page is used to regroup all of those values in a single place.
===accountlines.accounttype===
*A = Account Management Fee
*CH
*CR = C?? Returned
*F = Fine
*FFOR = Fine Forgiven
*FN	
*FU = Fine Unpaid
*IP	
*L = Lost Item
*LR = Lost and Returned (C4::Circulation->_FixAccountForLostAndReturned)
*M = Sundry	
*N = New Card
*O = Overdue
*Pay = Payment
*RE	
*REF	
*Rent = Rental Fee
*Rep = Replacement (?)
*Res	
*RL	
*W = Writeoff
===accounttypes as of 13.12.2015 ===
I have tried to map all actually used values. I have used git grep on current master.
*A = Account management fee
*C = Credit
*CR = a line appended to lost fee after returning it = it means C4::Circulation->_FixAccountForLostAndReturned, when found lost and return state, change line with "L" account type to "LR" and add line with "CR", also updated accountoffsets table!
*F = Fine (overdue fine)
*FFOR = Forgiven overdue fine
*FOR = Forgiven
*FU = overdue fine
*L = Lost item
*LR = Lost and Returned
*M = Sundry
*N = New card
*O = overdue fine
*Pay = Payment
*REF = Refund?
*Rent = Rental fee and renewel of rental item
*Rep = Replacement
*Res = Reserve charge
*W = Write off
===== updated August 12, 2016 =====
*Pay 00 - cash via SIP2
*Pay 02 - credit card via SIP2
* HE - Hold expiration charge
In C4::Overdues->GetFine is used sql with condition accounttype like "F%"
Category:Development
Hea

= Hea: Koha Usage Statistics =
== What is Hea ==
It's a website to collect data from libraries using Koha: https://hea.koha-community.org
== Why these statistics are useful ==
The main information we will be able to have is how many libraries are using Koha? 
How big are they? How many patrons are registered? How many items do they have? 
Moreover, the developers need to know which parts of Koha are used and which other parts are not. 
This way they will concentrate on features used by most people. 
They will also be able to clean up unused code. 
== How to collaborate ==
To have your library data displayed on the website, you can go to "Home › Administration › Usage statistics" and fill in the information you want to share.
=== Fill the info you want to share ===
By default you are not sharing anything and see:
 
Switch "Share my Koha usage statistics:" to "yes", then fill in the other data you want to share.
To set the geolocation you need to click on the blue pin then click on the map.
 
You can share the data for each library you have in your installation, do it by setting "Libraries information:" to "yes"
When everything is setup as you want to see it on the public website, click the "Update" button at the bottom of the page.
=== Share the data ===
So far the data are only stored locally, in your database. To share them with the Koha community you need to run a script.
If you installed using the packages the cronjob is already set up to run on a monthly basis (in /etc/cron.monthly/koha-common you will see koha-foreach --chdir --enabled /usr/share/koha/bin/cronjobs/share_usage_with_koha_community.pl).
For your first time you may want to share the data immediately without waiting. To do you so you can run perl misc/cronjobs/share_usage_with_koha_community.pl
You will immediately see the result on the Hea website. To get your public page you need to refresh the page and click on the "See your public page: " link.
== Which data is sent? ==
Only the number of lines in these database tables (anonymous):
*biblio 
*items 
*auth_header 
*old_issues 
*old_reserves 
*borrowers 
*aqorders 
*subscription
And some system preference values to know which configuration options of Koha are used and which are the preferred settings. You can find the list of system preference values in C4/UsageStats.pm. 
The first time data is sent, a random ID (UsageStatsID) is generated server side. Please don't change it, to not bias the results.
Henri-Damien Bug Wrangler for 3.4 Proposal

Global goal is to try and achieve to make the bug list becoming really suitable for a good software.
on a monthly base, 
* review bugs list
* gather proposals for enhancements
* fix the patch submissions when names or comments donot match rules.
* Try and forecast what is planned to be coded (with dates ??? enhancements) and publicize in the news letters what has been tested and solved, what is being worked upon.
* close unvalid bugs and test validity of very old bugs.
Review patches and ask for automated testing whenever possible.
Category:3.4
Hidden values

Integer values used by the database backend for controlling MARC framework visibility:
-9 => Future use-8 => Flag-7 => OPAC !Intranet !Editor Collapsed-6 => OPAC Intranet !Editor !Collapsed-5 => OPAC Intranet !Editor Collapsed-4 => OPAC !Intranet !Editor !Collapsed-3 => OPAC !Intranet Editor Collapsed-2 => OPAC !Intranet Editor !Collapsed-1 => OPAC Intranet Editor Collapsed0 => OPAC Intranet Editor !Collapsed1 => !OPAC Intranet Editor Collapsed2 => !OPAC !Intranet Editor !Collapsed3 => !OPAC !Intranet Editor Collapsed4 => !OPAC Intranet Editor !Collapsed5 => !OPAC !Intranet !Editor Collapsed6 => !OPAC Intranet !Editor !Collapsed7 => !OPAC Intranet !Editor Collapsed8 => !OPAC !Intranet !Editor !Collapsed9 => Future use
== Formatted == 
Value	In OPAC 	In Intranet	In Editor 	Collapsed 	Note
-9 	Future use	Future use 	Future use	Future use	
-8 	Flag 	Flag 	Flag 	Flag 	See bug 14772
-7 	Yes 	No 	No 	Yes 	
-6 	Yes 	Yes 	No 	No 	
-5 	Yes 	Yes 	No 	Yes 	
-4 	Yes 	No 	No 	No 	
-3 	Yes 	No 	Yes 	Yes 	
-2 	Yes 	No 	Yes 	No 	
-1 	Yes 	Yes 	Yes 	Yes 	Less common like 245$f
0 	Yes 	Yes 	Yes 	No 	Common sf like 245$a
1 	No 	Yes 	Yes 	Yes 	
2 	No 	No 	Yes 	No 	
3 	No 	No 	Yes 	Yes 	
4 	No 	Yes 	Yes 	No 	
5 	No 	No 	No 	Yes 	
6 	No 	Yes 	No 	No 	
7 	No 	Yes 	No 	Yes 	
8 	No 	No 	No 	No 	
9 	Future use	Future use 	Future use	Future use	
Category:Development
Hidelostitems option for the staff client RFC

== Development level ==
New table: borrower preferences
field 	type 	key 	Default
borrower_preference_id 	int(11) 	PRI 	Null, (auto-inc)
borrower_preference_type	int(11) 	FOR (to borrower_preference_types)	NULL
borrowernumber 	int(11) 	FOR (to borrowers) 	NULL
value 	varchar(150)	 	NULL
new table: borrower preference types
field 	type 	key	Default
borrower_preference_id	int(11) 	PRI	Null, (auto-inc)
value 	varchar(64)	 	NULL
Category:Implemented_RFC
Category:Staff_Catalogue_RFCs
Category:Koha_3.6_RFCs
Category:3.6
Hold request flag in circ matrix RFC

old RFC, probably no more relevant (LL)
==RFC: Put item hold request flag in circulation policy matrix==
At present, if a patron is allowed to place hold requests, they can request any item that is not on loan or doesn't have the binding, lost, or notforloan statuses set. However, some LibLime customers to need more precisely control which items are available for hold requests. For example, a library may want to permit loans for certain item types but not hold requests.
To meet this requirement, LibLime proposes to add a “holdability” flag to the circulation matrix (i.e., issuingrules). This would allow a library to specify for each branch which patron categories are allowed to place holds on which item types. This holdability flag would be the hold request equivalent of the recall flag proposed in the recalls RFC.
Adding this setting will influence:
* what item records are available to fill a title-level hold request
* what items a patron is allowed to place an item-level hold request for
During database upgrade, the holdability flag would be turned on for all existing issuingrules rows, thus preserving the current behavior of allowing all available items to be the target of hold requests.
Category:Abandoned_RFC
Hold request targeting RFC

Old RFC, probably no more relevant (LL proposal)
==Hold request targeting==
For 3.2, LibLime proposes to add a feature to target specific items to fill hold requests. This targeting, which would be done in conjunction with use of the holds queue batch job (build_holds_queue.pl) and its report, would allocate items that are sitting on the shelf to fill specific hold requests.
The idea is that the library would run the holds queue report periodically, then use the report to pull items off the shelf in order to fill hold requests. When the report is generated, the batch job would also populate a new table (to be called hold_fill_targets) that recommends that specific items be used to fill specific hold requests. As items from the picklist are checked in, if the item is targeted to a specific hold, it would be used to fill that hold first instead of filling the request that happens to be at the top of the priority queue.
Why do that? Suppose that a bib has two items, itemA and itemB, and suppose patron1 has a title-level request on the bib, and patron2 has an item-level request on itemB. Further, suppose that both items are available, meaning that both requests could be filled.
At present, whether both requests are actually filled depends on the order in which the items are checked in. If itemA is checked in first, then patron1 gets it, and when itemB is checked in, patron2 gets it. Everybody is happy. However, if itemB is checked in first, patron1's request is filled, but patron2 is left waiting for the item.
With the new targeting feature, the batch job will allocate items to fill particular requests, thus allowing all of the available items to be used to fill as many holds as possible, in priority order. The mechanism does assume that the library's workflow is to run the batch job, then *quickly* pull the items to put on the hold shelf or transfer to other branches.
This mechanism will also be used to minimize the number of transfers by allocating items located at a branch to fill requests for that same branch.
Category:Abandoned_RFC
Holdings or summary records RFC

gmc wrote this RFC. Is it still relevant ? (paul_p thinks not) Does Koha have multi-tier approach yet? If not, this is still relevant.
== RFC: Holdings structure ==
This specification adds summary holdings functionality to Koha. To achieve this, a number of architectural changes will take place. 
Previous releases of Koha used a two-tier bibliographic and item structure. Historic Note, Originally Koha had a 3 tier approach, this was lost when MARC support was added
Bibliographic records store title-level data and item records store item-specific data. (At the database level, things are a little more complicated, but functionally this is accurate.) 
There are several functional shortcomings to this approach:
# If libraries own materials that have not been inventoried at the item level, they cannot reflect these in their holdings without workarounds. 
# When a title has a lot of item records, it becomes difficult to display them clearly—the display becomes overwhelming. 
Libraries want some way to:
# Organize multiple items together so that it’s clear that items are related to each other. 
# Summarize the holdings from a group of items together, including expressing the gaps where items are missing from a set.. 
At the same time, some libraries do not want the overhead of an additional structure to support holdings. Many public and special libraries are not interested in adding summary holdings records. Libraries in many European countries also are not interested in maintaining holdings records. Holdings records must be optional for some libraries.
Holdings records add a lot of value for serial and multi-part records, but are not as critical for single-part monographic records. It’s important not to add overhead to the process for monographic cataloging. 
A new kind of records, called a summary record, will be added to Koha. Summary records will be available to group item records and to contain summary information about the item records. The actual fields of the summary record will be very similar to the fields of an item record, although some item record fields will not make sense in summary records, and summary records will have some additional fields that don’t make sense for item records. 
Since summary records, and holdings functionality generally, are basic to the system, adding them may change a lot of other functions in the system. As part of the analysis process we discuss a lot of these possible changes in order to be sure we’re aware of them, but they are not in scope for the first release of the holdings feature. The first release of the holdings feature will focus on the summary records that group items and store summary information. This will keep the scope manageable and will build a base for future functionality.
Category:Architecture,_internals,_and_plumbing_RFCs
Category:Koha_3.4_RFCs
Holds endpoint RFC

This RFC should be the basis for making the holds 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 holds 	GET 	/holds 	/holds
Add a hold 	POST 	/holds 	/holds
Get a hold 	GET 	/holds/{reserve_id}	/holds/{hold_id}
Overwrite a hold 	PUT 	/holds/{reserve_id}	/holds/{hold_id}
Delete a hold 	DELETE	/holds/{reserve_id}	/holds/{hold_id}
Partially update a hold	PATCH 	NOT IMPLEMENTED 	/holds/{hold_id}
== Hold object definition ==
DB schema 	Current API 	tcohen 	Katrin
reserve_id 	reserve_id 	hold_id 	hold_id
borrowernumber 	borrowernumber 	patron_id 	patron_id
reservedate 	reservedate 	hold_date 	hold_date
biblionumber 	biblionumber 	biblio_id 	biblio_id
branchcode 	branchcode 	pickup_library_id 	pickup_library_id
notificationdate	notificationdate	REMOVED 	REMOVED
reminderdate 	reminderdate 	REMOVED 	REMOVED
cancellationdate	cancellationdate	cancelation_date 	cancelation_date
reservenotes 	reservenotes 	notes 	notes
priority 	priority 	priority 	priority
found 	found 	status (probably an ENUM with more meaningful values)	status
timestamp 	timestamp 	timestamp 	timestamp
itemnumber 	itemnumber 	item_id 	item_id
waitingdate 	waitingdate 	waiting_date 	waiting_date
expirationdate 	expirationdate 	expiration_date 	expiration_date
lowestPriority 	lowestPriority 	lowest_priority (boolean) 	lowest_priority
suspend 	suspend 	suspended (boolean) 	suspended (boolean)
suspend_until 	suspend_until 	suspend_until 	suspended_until
itemtype 	itemtype 	item_type 	item_type
Category:RFCs
Holds suspension endpoint RFC

This RFC proposes a way to suspend a hold, and resume a suspended hold. This is implemented on bug 22206
== Actions and routes ==
The following table presents proposed implementation.
Description 	Action	Proposed
Suspend a hold 	POST 	/holds/{hold_id}/suspension
Resume a suspended hold	DELETE	/holds/{hold_id}/suspension
== Request body ==
This only applies to the POST action. It is not mandatory (hold will stay suspended indefinitely).
Attributes	Description
end_date 	The date the hold suspension expires
== Discussion ==
We already have an expiration_date on holds with a different meaning (when the hold is no longer needed/last pick-up date). I think it could avoid confusion to use a different naming here. Maybe suspension_date?
--Kfischer 02:01, 25 January 2019 (EST)
I disagree here.. we have the context within the route /suspension and suspention_date could mean either start or end of the suspension period... I'd stick with expiration_date for consistency and have it contextual by route MRenvoize 09:57, 13 February 2019 (EST)
Category:RFCs