nyuuzyou/wikis huggingface dataset:
MRenvoize/Email

How to get email through spam filters!
So, in many cases koha is configured to send mail directly from the local server. If you want your mails to get through all the spam filtering there is today, you'll need DKIM Signatures and SPF Records setup for the domain which your server reside in and your 'From:' address for all mails originating from the server MUST be within the servers domain.
i.e. If koha is at opac.myserver.com.. then the KohaAdminEmailAddress (and and 'email' settings per branch) must be something like: admin@myserver.com
With Bug 9530, you get some extra options for email:
The 'Reply-to:' address can be in ANY domain and will still pass through spam filters. It allows user to reply to a 'useful' address whilst the 'From:' address is still valid. 
The 'Return-path:' address however, again, MUST be within your servers domain. i.e webmaster@myserver.com for mails to get through spam filters.
The above is all to do with how SPF records work.. but setting up SPF and DKIM is beyond the scope of this note.
MRenvoize/MM Proposal

I'd be happy to step up to the post for Authentication Module Maintainer, having had to get to grips with allot of it for Shibboleth of late I feel I'm in a resultantly good position to do this now.
OR
I'de be happy to step up to the post for API Module Maintainer, with the aim of giving a bit of a directed, joined up effort going in the restful direction.
Happy to do either or, depending on what the RM would find most helpful.
My aim would be to spend a couple of days a month sweeping up related bugs and maintaining a branch with them cleanly applying to master.
MRenvoize/Paradigm Shift

Koha's been developed over a long period and has allot fo working code.. this is good.
At some point however, the UI paradigm shifted and we're now in a mixed stage.
The Koha UI can be clearly split into 'Modules' and 'Components' with those modules; however we're still writing 'Pages'.
For example, the 'Members' module.
We have the following pages: 'moremember', 'circlation', 'payments', 'routing-lists', 'readingrec', 'viewlog', 'notices', 'statistics', 'purchase-suggestions'.
For each page there is a separate back end script and a separate template (and often a number of pages between for stepping through actions). Each of these scripts and templates duplicates a large amount of code to display a uniform UI plus a small block of page specifc code for the actions.
We should be moving toward a 'Component' based approach instead where the above would turn into:
One Page/Module with a script and a template - Member
One Block/Component per the above 'Pages' plus a Block/Component per shared UI feature.
This way we're writing the code to display a 'component' once, instead of repeating it in every 'page'
MRenvoize/Plan

==Broad Categories==
Koha [c]
 Technical [c]
 Development [c]
 Coding guidlines [p]
 QA procedures [p]
 Coding guides [c]
 Working with git [c|p] 
 Copyright [p]
 RFC [c]
 Open [s]
 Closed [s]
 Abandonded [s]
 Implimented [s]
 
 Administration [c]
 Installation [c]
 Installing with Packages [p]
 Installing with Git [p]
 Customisation [c]
 XSLT Library [p]
 jQuery Library [p]
 css Library [p]
 Maintenance [c]
 
 Community [c]
 About Koha [c]
 History [p]
 Using Koha [c]
 Meetings [c]
 IRC Logs [c]
 Conferences [c]
 Global action days [c]
 Bug Squash days [c]
 QA Sprint days [c]
 
 Users
 Reports Library
 Skinning Library
 Tips & Ticks
 Documentation
Key
[s] - Semantic Tag
[p] - Page
[c] - Category
MRenvoize/QA Manager

== Proposal ==
I propose to be the QA Manager for the 24.11 cycle.
=== 24.11 ===
I want to try and drive more adoption of the dashboard for managing the quality assurance queues, refining the ToDo lists to our agreed priorities taking into account the different keywords like rm_priority, rel_candidate and roadmap as well as reconsidering the approach of listing 'oldest' bugs in each category...
I'd like us to focus on 'most recently worked on + oldest reported' as a sorting algorithm.
Finally, I want to try and promote more 'working together', bringing developers together at same time to focus on particular topic area's in sprints.
MRenvoize/RM

== Proposal ==
I propose standing for the Release Manager position for the next two koha release cycles (19.11 and 20.05). I would act as per the guidelines on project roles whilst also attempting to encourage improvements to the development culture by trying to introduce more collaboration between parties.
Release Management is very team dependant and as such I would lean heavily on the amazing efforts of the QA team and try to maintain a close relationships with them throughout the cycles. I'd like to take more of an active role, alongside the QA Manager, in assigning SO/QA resources to important bugs encouraging quicker iteration and faster feedback.
=== 19.11 ===
I will strive to make 19.11 a healthy and polished release.
* I'd like to focus on Acquisitions, in particular improving workflows, accountability/auditability and accuracy.
* I don't believe Mana has received the attention it needs during the last cycle and I would like to see some polish and enhancement in this area. Perhaps looking into extending it to manage plugins and perhaps investigating federation of Mana servers.
* Elasticsearch has become a first class citizen during the last few cycles and I'd like to see that continue to flourish under my leadership.
* I would encourage continued efforts on the REST API, and hope the new RMaint team adopt the backporting policies I put in place during my tenure as RMaint.
I'd really like to see continued enthusiasm for the following too:
* Continued refactoring efforts
* Continued improvements to the test suit
* More code golf to refine bugs that are 'nearly there'
* Keeping submissions small, focused and testable wherever possible
===20.05===
The 19.11 cycle was a slow cycle with the statistics showing a clear drop in the spread of SO and QA resources. I want to attempt to combat this by publishing a monthly review of the current state of play highlighting the top contributors and praising their efforts.
* Accounts foundations have moved forward significantly during the 19.11 cycle; I'd like to see enhancements in this area flourish now the foundations are firm.
* Acquisitions is still a target area as above.
* Mana received some attention very late in the 19.11 cycle and I'd like to see that continue into the next.
* Elasticsearch is going from strength to strength, lets continue that.
* I would like to also focus on database improvements, enhancing our constraints and improving data integrity.
I encourage a continued enthusiasm for:
* Refactoring efforts and more of a team approach to this.
* Test suit enhancements and CI improvements to catch a broader range of failure cases.
* Continued code golfing.
MRenvoize/RMaint

== Proposal ==
=== 18.11 ===
I would like to stand for the RMaint position for the stable branch (18.05) of koha during the 18.11 cycle. I wish to act as per the guidelines on project roles, and strive to keep a healthy stable release with regular releases.
I also propose to have a policy of backporting trivial API and Plugin infrastructure enhancements during my tenure to enable the widest possible range of Koha versions to be supported by upcoming plugins and integrations. I will, however, not compromise security or stability for this goal.
=== 19.05 ===
I'm happy to submit my proposal to continue as the RMaint for the stable branch (18.11) of koha during the 19.05 cycle.
As well as the commitments above, I'd like to focus on an improved release process this cycle, with particular attention to the usefulness of release notes.
== Tools I use ==
Tracker Script
MRenvoize/RMaintTrack.pl

#!/usr/bin/env perl
use 5.24.1;
use Mojo::File;
use Mojo::UserAgent;
use Git::Raw;
# todoist api key
my $api_key = 'your_todoist_key';
# ua
my $ua = Mojo::UserAgent->new;
# open repository
my $repo = Git::Raw::Repository->open('/home/reposync/kohaclone');
# ensure we are looking at master
$repo->checkout('master',{ checkout_strategy => { safe => 1}});
# create a new walker
my $log = $repo->walker;
# lookup last synced commit
my $file = Mojo::File->new('/home/reposync/last_sync_commit');
chomp(my $commit = $file->slurp);
# push commit range to walker
$log->push_range("$commit..HEAD");
# reverse walker
$log->sorting(['reverse']);
# print all commit messages
my $commitref;
while (my $commit = $log->next) {
 my $summary = $commit->summary;
 say $commit->id ." - ". $commit->summary;
 if ($commit->summary =~ /Bug (\d+)/) {
 my $bug_number = $1;
 $summary .= " [(Bugzilla)](https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=".$bug_number.")";
 }
 $commitref = $commit->id;
 $summary .= " [(Commit)](https://gitlab.com/mrenvoize/Koha/commit/".$commit->id.")";
 my $task = {
 content => $summary,
 due_string => "next Monday",
 due_lang => "en",
 priority => 4,
 project_id => 2187026049
 };
 my $tx = $ua->post('https://beta.todoist.com/API/v8/tasks' => { Authorization=> "Bearer $api_key" } => json => $task );
}
say "Todoist Synced";
$file->spurt($commitref) if $commitref;
MRenvoize/Updating Koha Install

perl Makefile.PL --prev-install-log /home/koha/koha-dev/misc/koha-install-log
make
sudo /etc/init.d/koha-zebra stop
sudo chown -R koha:koha ~/koha-dev
make upgrade
sudo /etc/init.d/koha-zebra start
/home/koha/kohaclone/misc/migrationtools/rebuild_zebra.pl -a -b -x -r -v
MS9590 VoyagerGS

==MS9590 VoyagerGS Installation Notes==
====Hardware installation====
*There is really not much to installing the MS9590. The scanner does all of the processing of the barcode internally and supplies the decoded data as keyboard input to whatever application.
*Initially all that is involved is unpacking the scanner, attaching the USB cable (or whatever cable applies to your scanner), and you're off.
*The included Installation and User's Guide is very well written and easy to follow.
====Configuration hints====
*OPAC Use:
**This section needs to be written. FIXME
*STAFF Use:
**If you plan to use the MS9590 to retrieve ISBN via EAN barcodes on books, you will need to make a couple of configuration changes to the scanner.
***First, locate your Single-Line Configuration Guide.
***You will need to enable two supplements on your scanner: 'ISBN Check Digit Transmission' and 'Bookland to ISBN Conversion.'
***On page 2 of the paper Configuration Guide, scan the 'Enter/Exit Configuration Mode' bar code with your MS9590.
***The MS9590 will indicate entry into configuration mode by three beeps in rapid succession.
***Turning to page 17, proceed to scan 'Enable ISBN Check Digit Transmission.'
***Also scan 'Enable Bookland to ISBN Conversion.'
***Each successful scan should be indicated by a single beep.
***After scanning these two entries, return to page 2, and again scan the 'Enter/Exit Configuration Mode' bar code with your MS9590.
***The MS9590 will indicate exit from configuration mode by three beeps in slow succession.
**You should now be able to scan the EAN UPC on any book and see the correct ISBN number show up in Koha.
**These changes should not affect other types of bar code scans.
====Miscellaneous Notes====
*CR Suffix
**The MS9590 comes set to append a <CR> to each transmission of data to the application. This may cause some issues depending on how/where you are using the scanner in the application.
**To disable this feature do the following:
:#On page 2 of the paper Configuration Guide, scan the 'Enter/Exit Configuration Mode' bar code with your MS9590.
:#The MS9590 will indicate entry into configuration mode by three beeps in rapid succession.
:#On page 41, scan 'Disable CR Suffix.'
:#Return to page 2, and again scan the 'Enter/Exit Configuration Mode' bar code with your MS9590.
:#The MS9590 will indicate exit from configuration mode by three beeps in slow succession.
:#The scanner will now transmit data without the <CR> appended.
*Installation Guide
*Manufacturer's Website
Category:Barcode_Scanners
Main Page/es

Koha es un (SBI) y fue el primer open source ILS. Koha fue creado en 1999 por Katipo Communications para la Horowhenua Library Trust en Nueva Zelanda. La primera instalacion fue realizada en Enero del año 2000.
==Categorias==
El contenido wiki actual se puede encontrar bajo las siguientes categorias:
* Acerca de Koha
* Participacion en la Comunidad
* Documentación
* Instalación
* Desarrollo
* Versiones de Koha
* Koha & Git
* Conferencias de Koha
* Materia Legal
* Tips & Trucos
==Para las cuentas Wiki ahora es necesario validarlas con una direccion de email==
Para hacer frente a una afluencia de correo no deseado,spam. A partir de 2011-01-28 las cuentas de usuario deben ahora tener una dirección de correo electrónico confirmada con el fin de realizar modificaciones en el wiki. Si usted tiene una cuenta existente y ya no es capaz de hacer cambios, por favor vaya a su preferencias de usuario, introduzca una dirección de correo electrónico si es necesario, tienen la wiki para enviar un correo electrónico de verificación, a continuación, siga las instrucciones para confirmar su cuenta.
== Sitios de la Comunidad Koha (y su estado) ==
Otros sitios Oficiales koha que puede seguir:
* www.koha-community.org
* wiki.koha-community.org 
* lists.koha-community.org 
* bugs.koha-community.org 
* git.koha-community.org 
* dashboard.koha-community.org (automatically updated overview of development activites)
* debian.koha-community.org 
* download.koha-community.org 
* perldoc.koha-community.org
* jenkins.koha-community.org Continuous integration server
* translate.koha-community.org (Psst, Librarians, you can help a lot here.)
* contribs.koha-community.org
* meetings.koha-community.org IRC meeting logs and minutes.
Details of who hosts what etc. Please add others or links when those sites are up.
==Actualizaciones Wiki==
 Suscribete a las actualizaciones via RSS
__FORCETOC__
Category:Home
Maintaining man pages for koha-common as DocBook RFC

Editing man(ual) pages directly is cumbersome and error-prone and requires knowledge of a rather obscure syntax. A better option might be to edit them as a DocBook document and transform them to whatever we need, including man pages, HTML etc. 
==Technicalities==
===man pages===
Sample files for koha-create.xml and koha-remove.xml has been created, with documentation for koha-create and koha-remove. Running this command: 
 xsltproc /usr/share/xml/docbook/stylesheet/docbook-xsl/manpages/docbook.xsl koha-*.xml
generates these files: 
* koha-create.8
* koha-remove.8
Use e.g. this to view the results: 
 man -l koha-remove.8
===HTML===
koha-common.html was created with this command, as an example of an alternative format: 
 xsltproc /usr/share/xml/docbook/stylesheet/docbook-xsl/xhtml/docbook.xsl koha-*.xml > koha-common.html
==Pros==
* More familiar syntax
* Markup is logical, not presentational
* Can be handled in the same way as the manual
* All man pages can be maintained in one file
* ?
==Cons==
* ?
==Where to put the file==
There are several options for handling the koha-common.xml file: 
* Include it in the main koha repository
** debian/docs/
** Could the man pages be generated during installation of koha-common, so that they do not exist as separate files in the repo? 
** This might make it harder to integrate the man pages into e.g. the HTML version of the manual, if we should wish to do that
* Create a separate git repository for it
* Include it in the en/manual.xml file in the kohadocs repository
** This might make it harder to get the *.8 files into the installation
* Include it as a separate file in the kohadocs repository
* Any other options? 
Not sure what will be the best solution?
Category:Documentation_RFCs
Category:Koha_3.6_RFCs
Category:Submitted_RFC
Making classification indexes searchable in staff client RFC

A client would like to be able to search for Dewey numbers in the staff client. 
This can be accomplished by uncommenting "Dewey-classification 1=13" in etc/zebradb/ccl.properties and adding another <option> to koha-tmpl/intranet-tmpl/prog/en/includes/search_indexes.inc and maintaining it as a local hack. 
But it seems like something more libraries might be interested in, so maybe there it's possible to find a more flexible way to do it. 
==Commented indexes==
First question: Several indexes related to classification are commented out in ccl.properties:
 #Classification-Dewey 13 A classification number from 082
 # the Dewey Decimal
 # Classification, developed by
 # Melvyl Dewey.
 #Dewey-classification 1=13 
 
 #Classification- 50 A classification number 086
 #government-publication assigned to a government
 # document by a government
 # agency at any level (e.g.,
 # state, national,
 # international).
 #Number-govt-pub 1=50
 
 #Classification-NAL 18 A classification number from 070
 # the US National Agriculture
 # Library Classification.
 #NAL-call-number 1=18
 
 #Classification-NLM 17 A classification number from 060
 # the US National Library of
 # Medicine Classification.
 #NLM-call-number 1=17
 #
 #Classification-UDC 14 A classification number from 080
 # Universal Decimal
 # Classification, a system based
 # on the Dewey Decimal
 # Classification.
 #UDC-classification 1=14
even though they are created by record.abs:
 melm 060 NLM-call-number
 melm 070 NAL-call-number
 melm 080 UDC-classification
 melm 082 Dewey-classification:w,Dewey-classification:s
 melm 086 Number-govt-pub
Is there any advantage to having them commented out in ccl-properties?
==Proposal==
Uncomment the indexes in ccl.properties and make it easy for libraries to decide which ones should appear in the dropdowns on the search page in the staff client. This could be done in two ways: 
===One syspref===
Make one syspref that lets a library choose which one of the indexes should be activated in the staff client search. It would probably not take long for some library to come along and want to activate at least two? 
===Many sysprefs===
Create one on/off syspref per index. 
Comments?
Category:RFCs
Making more indexes searchable with Zebra SRU

Which indexes are searchable from SRU is governed by the config file etc/zebradb/pqf.properties. Initially the searchable indexes is somewhat limited, so you might want to add some more. 
Let's say you are using MARC21 and want to be able to search for the values in MARC field 952$y - "Koha item type". There are three files you need to look at: 
==record.abs==
etc/zebradb/marc_defs/marc21/biblios/record.abs (Use the file that is appropriate for your MARC dialect!)
This file says in which index Zebra should index 952$y: 
 melm 952$y itype:w,itype:p
The name of the Zebra index is itype.
==bib1.att==
etc/zebradb/biblios/etc/bib1.att
Now we look for itype in bib1.att and find this:
 att 8031 itype
So the information from 952$y is now in bib1 attribute 8031. 
==pqf.properties==
etc/zebradb/pqf.properties
We look for 8031 in pqf.properties, but it is nowhere to be found! If we want to be able to search for the information from 952$y available for searching from SRU, we need to edit pqf.properties. Add something like this under the other index.dc.* entries: 
 index.dc.kohaitemtype = 1=8031
(Putting this into the dc "namspace" might not be a good idea, it might be better to define a new "namespace" called local or something similar, but I have not actually tested that...)
Now restart Zebra: 
 sudo /etc/init.d/koha-zebra-daemon restart
And you should be able to search on the new index, like this: 
 http://example.org:9998/biblios?version=1.1&operation=searchRetrieve&query=dc.kohaitemtype=BK&maximumRecords=100
The process will be similar for other MARC fields and subfields.
Category:Tips_&_Tricks
Managing permissions on acquisition module

==RFC: management of librarian permissions on acquisition module==
We would want to follow for the Acquisition module the same logic as implemented for the Tools module to have more granular permissions than at present.
Permissions could be:
* budget_create_new : permission to create a new budget
* budget_allocate : permission to allocate an amount to a budget, either during the process of creating the budget, or afterwards
* budget_invoice : permission to create an invoice on a given budget, i.e. debit the budget
* budget_encumbrance : permission to commit any amount to an order
* basket_create : permission to create an order basket
* basket_close : permission to close an order basket
* suggestion_acceptorreject : permission to accept/reject/delete suggestions
* vendor_createoredit : permission to create/edit/delete a vendor
* order_claim : permission to claim late orders
Category:System Administration RFCs
Category:Acquisitions_RFCs
Category:Koha_3.2_RFCs
Category:3.2
Mandate item-level circulation rules RFC

== Mandate item-level circulation rules. ==
Currently we use the system preference item-level_itypes to indicate whether Koha
should use the itemtype stored at the bibliographic level or the item level to control 
circulation parameters. This is one of the more significant distinctions in general policy
between US and French libraries, and was also one of the major limitations of Koha 2.x
in the eyes of US libraries.
Koha 3.0 offers the option to define your itemtypes at either the bib-level or item-level.
However, this option adds unnecessary complexity and offers an easy spot for bugs to 
appear. I propose that this option be removed for the 3.2 release, and that steps be taken
to make this feature-removal relatively painless and invisible for those libraries that do 
maintain circulation policy at the bib level.
I propose the following:
# the item-level_itypes system preference be removed.
# biblioitems.itemtype be renamed to biblioitems.default_itemtype
# items.itype be renamed to items.itemtype
# all circulation parameters will be determined by items.itemtype.
# AddItem and ModItem will automatically fill items.itemtype from biblioitems.default_itemtype if items.itemtype is not supplied.
This should allow French (and others using bib-level circ rules) libraries to continue
with their current workflows, and should essentially be unnoticeable to them, while allowing
us to remove the bug-prone distinction of item/bib level itemtypes.
Comments and suggestions welcome.
Category:Abandoned_RFC
Marseille hackfest 2014

Where? Marseille, France. 
When? March 10-14 2014
==Numbers==
===Monday evening===
 Needs Signoff...167 (38 bugs)
 Signed Off......119 (59 bugs)
 Passed QA........54 (29 bugs)
 Failed QA.......170
 Doesn't apply....34
 In Discussion...135
===Tuesday morning===
 Needs Signoff...164 (36 bugs)
 Signed Off......121 (63 bugs)
 Passed QA........48 (26 bugs)
 Failed QA.......172
 Doesn't apply....34
 In Discussion...135
===Tuesday afternoon===
 Needs Signoff...142 (29 bugs)
 Signed Off......122 (65 bugs)
 Passed QA........54 (28 bugs)
 Failed QA.......178
 Doesn't apply....39
 In Discussion...135
===Wednesday morning===
 Needs Signoff...143 (29 bugs)
 Signed Off......121 (64 bugs)
 Passed QA........51 (27 bugs)
 Failed QA.......178
 Doesn't apply....39
 In Discussion...135
===Wednesday afternoon===
 Needs Signoff...132 (29 bugs)
 Signed Off......116 (54 bugs)
 Passed QA........55 (30 bugs)
 Failed QA.......184
 Doesn't apply....43
 In Discussion...134
===Thursday morning===
 Needs Signoff...129 (28 bugs)
 Signed Off......112 (51 bugs)
 Passed QA........52 (28 bugs)
 Failed QA.......185
 Doesn't apply....45
 In Discussion...134
===Thursday afternoon===
 Needs Signoff...123 (27 bugs)
 Signed Off......108 (46 bugs)
 Passed QA........60 (31 bugs)
 Failed QA.......182
 Doesn't apply....43
 In Discussion...135
===Friday morning===
 Needs Signoff...123 (26 bugs)
 Signed Off......112 (49 bugs)
 Passed QA........58 (30 bugs)
 Failed QA.......181
 Doesn't apply....43
 In Discussion...134
===Friday afternoon - THE END===
 Needs Signoff...123 (28 bugs)
 Signed Off......106 (42 bugs)
 Passed QA........58 (30 bugs)
 Failed QA.......184
 Doesn't apply....42
 In Discussion...135
===Summary===
 Needs Signoff...167 -> 123
 Signed Off......119 -> 106
 Passed QA........54 -> 58
 Failed QA.......170 -> 184
 Doesn't apply....34 -> 42
 In Discussion...135 -> 135
It seems 43 bugs has been pushed to master during this week (from commit b648425aee8d23bfedf53b09593f5978ae667d7b to commit 657cd3c4c0a784e2d8e202b94d538c9229fb463a).
Category:Global_bug_squashing_days
Category:Hackfests