October 2008 - Koha-devel - lists.koha-community.org

Not know how to use finesMode
by Rubén Gómez 15 Oct '08

15 Oct '08

Hello everybody. That's my first email so I hope I can express myself. I want to use the fines Mode but I'm not sure how to put it working. I have gone to "Circulation preferences" and I put the "finesMode" variable to "production", but it doesn't do nothing. I want to create a fine when anyone don't return a book on time, something like to pay $0,5 each day it overpass the "Specify Due Date". I suppose it must be done with "finesMode" but I don't know how to do it. What about "accruefines cronjob", where can I found it? I hope you can help me. Thanks!

1 0

Re: [Koha-devel] RFC: Improvements to Koha security and privacy
by Nicolas Morin 15 Oct '08

15 Oct '08

On Wed, Oct 15, 2008 at 8:47 AM, Nicolas Morin <nicolas.morin(a)biblibre.com> wrote: > On Wed, Oct 8, 2008 at 11:49 AM, Krishnan Mani <krishnanm75(a)yahoo.com> wrote: > >> >> >> Improvements >> >> To introduce an e-mail workflow requiring patrons to confirm membership. > I'm not too sure about that: some might think it places an undue burden on the patron himself. After all in most cases, the patron will have come to the library in person and actually given out his email to the librarian who recorded it in Koha; he might find it a little odd to have to confirm it. Besides, you suggest on time passwords to be emailed to the patron and changed upon first login: will it not act as a confirmation? I'm all for security improvements. But not at the price of usability for the user: I think it should be taken care of in the background. Regards, Nicolas

1 0

should amountoutstanding approach zero?
by Michael Hafen 15 Oct '08

15 Oct '08

I'm looking through Accounts.pm and I see the call to fixcredit() is commented out, and the POD for fixcredit() declares it deprecated. So it seems that amountoutstanding is not adjusted when manual credits are entered. I would rather see amountoutstanding change than that it not change. Are there any comments on this? Am I missing something? Thanks.

2 1

in the Template for Cataloging HTML escaping title in the search results breaks search term highlighting
by Michael Hafen 14 Oct '08

14 Oct '08

I recall there being a couple patches, one to HTML escape the title in search results, and another to reverse that change on the catalog page. HTML escaping the title breaks search term highlighting. The cataloging page still suffers from this breakage. Perhaps these fields could be html escaped before the search term highlighting is applied? Thanks.

3 3

Installing 3.0 on FreeBSD - Web Installer Errors
by Thomas Sewell 14 Oct '08

14 Oct '08

I've been struggling to get Koha 3.0 installed on FreeBSD 7.0. I know, a glutton for punishment, right? After wading through the installation process (including installing additional cpan modules and rewriting the installed sample koha-conf.xml and koha-httpd.conf files to use the right file paths, since the installer didn't seem to configure them based on what the makefile used), I've finally run into an issue that I can't find enough information to solve. My understanding is that the web installer is supposed to install the tables into the database. At least, there is nothing in the koha database at this point. When going to http://intranet.example.net:8000/cgi-bin/koha/installer/install.pl I get the following html message: production mode - trapped fatal error And the following lines in koha-error_log: [Thu Sep 25 17:28:22 2008] [error] [client 63.230.9.45] [Thu Sep 25 17:28:22 2008] install.pl: DBD::mysql::st execute failed: Table 'koha.language_subtag_registry' doesn't exist at /usr/share/koha/lib/C4/Languages.pm line 178. [Thu Sep 25 17:28:22 2008] [error] [client 63.230.9.45] [Thu Sep 25 17:28:22 2008] install.pl: DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /usr/share/koha/lib/C4/Languages.pm line 179. [Thu Sep 25 17:28:22 2008] [error] [client 63.230.9.45] [Thu Sep 25 17:28:22 2008] install.pl: DBD::mysql::db selectrow_array failed: Table 'koha.systempreferences' doesn't exist at /usr/share/koha/lib/C4/Context.pm line 479. [Thu Sep 25 17:28:22 2008] [error] [client 63.230.9.45] [Thu Sep 25 17:28:22 2008] install.pl: Use of uninitialized value in string eq at /usr/share/koha/lib/C4/Context.pm line 45. [Thu Sep 25 17:28:22 2008] [error] [client 63.230.9.45] [Thu Sep 25 17:28:22 2008] install.pl: Use of uninitialized value in string eq at /usr/share/koha/lib/C4/Context.pm line 45. [Thu Sep 25 17:28:22 2008] [error] [client 63.230.9.45] [Thu Sep 25 17:28:22 2008] install.pl: Can't call method "id" on an undefined value at InstallAuth.pm line 278. I can connect to mysql using the information in koha-conf.xml: `mysql -u kohaadmin --port 3306 --host localhost -p koha` connects fine. I have p5-DBD-mysql-4.006 installed (among other things). On a possibly unrelated issue, when running: /usr/local/bin/zebrasrv -f /etc/koha/koha-conf.xml All I get is: 17:39:54-25/09 [fatal] Unknown element 'include' in config /etc/koha/koha-conf.xml I'm currently stuck on both of those, so any help or suggestions would be appreciated. Thanks, Thomas

4 4

patches for 3.0 / head / both
by Paul POULAIN 14 Oct '08

14 Oct '08

Hello, atm, all patches are sent to patches(a)koha.org They are supposed to be relevant for HEAD. but : how will we deal with patches that are 3.0 only ? For example : updates of the french translation. They are 3.0 specific, and can't be merged in HEAD. In a few weeks, I think we will have some bugs that are 3.0 only, and irrelevant in head (due to some structure/code/features changes) so, how will we deal with those ? I once suggested to have a patches30(a)koha.org mailbox, this proposal has not been accepted. But I come back with the general idea, as I think it's something we will face quickly. So, any idea welcomed... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

5 4

RFC: Koha 3.2: Koha E-R diagrams and tables information
by Zeno Tajoli 14 Oct '08

14 Oct '08

Hi to all, CILEA has found a stagaire to work on Koha. But we can't do what I have write in the RFC 'Autogeneration of Koha UML diagrams'. We limit ourselves to only write the documentation of Koha DB. You can see the new RFC here: http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_koha_api_uml_… The text of the RFC: Koha E-R diagrams and tables information Status It is not easy to understand the Koha 3.0 DB structure. Infact you need to read the Koha co to undestand all tables .CILEA wants to improve the situation writting more tecnical documentation about Koha 3.0 DB Actions Starting from all documentation avaible from wiki and koha-dev list we start to write complete E-R diagrams for Koha DB and a specific document for every table We write: 1) a general description of the table, 2) a specific description of every field (name, lenght, type, data inserted, constrains) 3) a specific description of every index 4) a list of the foreign keys of the table We drow also a general E-R schema of the DB The person who will do the Job is Matteo Romanello <http://www.linkedin.com/pub/dir/matteo/romanello> with Zeno Tajoli as tutor. Timetable and Tools The work will start at 15 november 2008, it will probably finish at may 2009 The instrument used will be OpenOfficeOrg Calc. Cheers Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

2 1

Updating multiple Marc Item Records
by C W Nel 14 Oct '08

14 Oct '08

I need to create a perl script to update wrong information in the item table. The holdingbranch data is wrong. How can I simultaneously change the data in the koha items table and the item data in the marc structure? Can anyone please help?

2 2

RFC: Koha 3.2 : Mandate item-level circulation rules
by Ryan Higgins 13 Oct '08

13 Oct '08

[ this text also available at: http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_item_level_it…] RFC: Koha 3.2 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 seems to be 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: 1: the item-level_itypes system preference be removed. 2: biblioitems.itemtype be renamed to biblioitems.default_itemtype 3: items.itype be renamed to items.itemtype 4: all circulation parameters will be determined by items.itemtype. 5: 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. -- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704

6 6

RFC: Improvements to Koha security and privacy
by Krishnan Mani 13 Oct '08

13 Oct '08

Introduction With growing Koha usage at large public libraries and exposure of the OPAC (and in several cases, the Intranet interfaces) to audiences over the (big, bad) public Internet, the Koha community needs to be increasingly sensitive to security and data privacy. If not, it is possible that Koha systems may present easy targets to unscrupulous people looking for potentially sensitive patron information that may be compromised and abused. In this regard, Koha is not current with many commonly-accepted mechanisms to improve overall security. Moreover, these mechanisms (IMHO) can be easily added to Koha without disproportionate effort. The most cost-effective way of improving security of any system is to build the security into it upfront. Suggested improvements S1. E-mail confirmation workflow Background At account creation, Koha now has the option (using a template) in 'Notification' to send e-mail to an e-mail field on the patron records. The default template even includes the login name and password (in cleartext). Issue Any errors in specifying or recording e-mail address will send account creation (or other) e-mail to the wrong person. With the default template, such errors will directly allow another person to login to the member’s account. Improvements 1. To introduce an e-mail workflow requiring patrons to confirm membership. Koha can send account details after confirmation of membership. (An example is the workflow for users signing up to Koha mailing lists) 2. To change the default template to include only a one-time password (or one-time login facility) (to be described below)S2. About passwords Background Login passwords are not temporary and there is no mechanism to force users to change passwords. While Koha suggests a password to be set at the time of account creation, this means that at least one staff member knows passwords or may set them to something that is trivially weak. Currently, a system preference allows administrators to specify (only) a minimum character length for passwords. Issue More than one person is involved and has knowledge about passwords being set/reset. This introduces potential human error in communicating passwords during account creation or password reset Suggested improvements 1. Introduce one-time passwords (or one-time login links) automatically generated and e-mailed by Koha 2. Change the default account creation template shipped with Koha to include a one-time password/link allowing time-bound one-time login 3. Force users to change first-time passwords immediately on login 4. Staff to only request Koha to reset the passwords on accounts rather than set actual passwords. 5. Provide a self-service facility to users to request new passwords (or to reset passwords via a one-time login). Users are authenticated using a configurable piece of information from patron records that is used to construct ‘challenge’ questions. 6. Disallow display of passwords in cleartext anywhere in Koha or in e-mail notification 7. Enhance checks for password strength by checking for, some combination of uppercase and lowercase characters, numerals, and special characters. Add system preferences for administrators to specify the particular mix. 8. Allow administrators to specify a lifetime for passwords (say, 90 days), and have Koha force users to change passwords older than the same. S3. Database access and ‘super-librarian’ login Background Koha stores the database user and password to (/etc/koha/)koha-conf.xml with the password in cleartext. This file is world-readable, and my own attempt to restrict access to this file breaks Koha. The same login and password is used to login to the Intranet post-installation, with ‘super-librarian’ privileges Suggested improvements 1. Protect configuration files containing sensitive information and change Koha code to be able to read the same (This author is unaware of a suitable mechanism in Perl but recalls using the ‘requires’ facility in .php on products like Joomla) 2. Disallow logging into Koha using the database user and password 3. Create a one-time administrator login during installation to be used post-installation to create regular staff users. S4. Print "last login" information upon logging in This alerts users to any logins they may not recall and help detect any compromise attempts. S5. Securing KOHA logins over SSL Background The OPAC login facility is available on most pages inline with other page content Issue If a site wants to secure, say, just logins, by serving those pages over SSL, it is currently not possible to do so without serving all of the site over SSL. This may not be acceptable considering potentially higher load and response times to serve content over SSL. Suggested improvements 1. Separate the login page (as in the Intranet), so as to secure the same over SSL, and once the user is authenticated, the user can be redirected to regular content served over HTTP. 2. Allow configuring at installation time the use of SSL for some set of pages, including, for example, login, change password, patron profile pages, etc. 3. Simple instructions for admins to generate and use self-signed certificates for SSL may be included with the documentation. S6. Improvements to disabling/enabling OPAC and Intranet access At the moment, it is unclear whether clearing out the login and password field on a member record disables their login, and whether non-staff patrons have access to both OPAC and Intranet or just the OPAC. (the author is researching these) This can be remedied by simply providing an additional toggle to enable/disable login for a patron. This may also be useful in the event that a stray patron posts abusive content in tags or book reviews. Thanks and regards, krishnan mani Pune, India Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

2 2