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

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

error when adding vendor
by mallikarjun dora 13 Oct '08

13 Oct '08

Dear ALL Koha error The following fatal error has occurred: Undefined subroutine &main::AddBookseller called at /usr/share/koha/intranet/cgi-bin/acqui/updatesupplier.pl line 92. Apache Server version: Apache/2.2.8 (Linux/SUSE) Server built: Jun 6 2008 23:42:07 Koha 3.00.00.107 Koha DB 3.0000107 MySQL mysql Ver 14.12 Distrib 5.0.51a, for suse-linux-gnu (i686) using readline 5.2 OS Linux susekoha 2.6.25.5-1.1-pae #1 SMP 2008-06-07 01:55:22 +0200 i686 i686 i386 GNU/Linux Perl 5.010000

3 2

Authority Control RFC
by Brian Harrington 09 Oct '08

09 Oct '08

I was reading over the RFC for authority control enhancements in 3.2, and they look like great changes that we would love to see. I do have a quick question though. Will there be any provision for preserving local changes in an authority record when merging the imports. Maybe something as simple as preserving fields that have a subfield 5? Thanks, Brian -- Brian Harrington Content and Resource Development Coordinator Project MUSE The Johns Hopkins University Press brian(a)jhu.edu

1 0

Problem in /koha/members/memberentry.pl?
by Nahuel ANGELINETTI 09 Oct '08

09 Oct '08

Hi, An user of intranet ask me why there is two "E-mail (home):" input in /koha/members/memberentry.pl. After reading the code, only one of the three e-mail adresses asked in this form is saved : " elsif ($newdata{email} =~ /\w\@\w/) { $emailaddr = $newdata{email} } elsif ($newdata{emailpro} =~ /\w\@\w/) { $emailaddr = $newdata{emailpro} } elsif ($newdata{B_email} =~ /\w\@\w/) { $emailaddr = $newdata{B_email} } " Can you tell me why 3 e-mails are asked(with a duplicate input) and only one is saved? Why there is no asked only one e-mail? The member can choose which one he want to give. And there are more than one B_email input in the form (cf : Alternate address). I think it's strange to ask too much informations and keep only a bit. Regards, -- Nahuel ANGELINETTI

2 1

Koha 3 Hosting
by zang＠zang.co.za 08 Oct '08

08 Oct '08

Can anyone please help with Koha 3 Virtual hosting issues? We are currently hosting Koha2.2.9 without a problem. I basically copy the Koha 3 database and change the database name in koha-conf.xml. On running the web page on port 8080, the system comes up with the installation page. Is there anything else to be changed? Thanks for any advice.

3 7

RFC: support for 3M RFID reader 810 in koha
by Dobrica Pavlinusic 04 Oct '08

04 Oct '08

Last week I was playing with reverse engineering protocol of 3M 810 RFID reader to make it integrated with our Koha installation. Currently I understand enough protocol to detect and read tags, but programming and blanking is just a matter of (free) time. Current source code (if anybody wants to take a look) is available at: http://svn.rot13.org/index.cgi/RFID Now I'm in stage where I would love to integrate it in Koha, so I'm seeking for feedback. Since machines on which reader is connected are Windows, and data which can be gathered are usable only when paired with data from Koha, I have two possible solutions: 1) Connect RFID reader serial port to some kind of Windows service (suggestions welcomed!) which would allow my perl script to connect it over network and drive reader (this has additional benefit that all pages in web browser come from my Koha server, so I don't have problem with same origin policy in browser). 2) install perl on windows and run reader driver there, integrating with Koha using frame set (one frame Koha window, another frame reader) This would require to have some kind of REST API for Koha which I could use from JavaScript within browser. I would like to support following user interaction with Koha (and reader): * putting book on RFID reader opens it's record in Koha (this would probably require some kind of long-poll from browser to Koha so that server can update browser window as soon as RFID tag is detected) * button which allows you re-program RFID tag of book on reader by clicking on button beside bar-code in Koha interface. Sound indication would provide feedback about finish of programming. I would prefer solution (1), but solution (2) would allow me to use firefox -remove to change browser URL and I would be able to generate sound notification easily (without some kind of flash which would be needed to make sound identification work in first possible solution) However, making less moving parts on 30 machines which have reader connected to them seems like good enough reason to move all logic to server driven readers. I could probably write few more pages about this, but this might be enough for this message. Your comments are greatly appreciated :-) -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

1 0

Re: [Koha-devel] [Koha] Creating reports in Koha 3.0
by Jesse Weaver 01 Oct '08

01 Oct '08

On Wed, Oct 1, 2008 at 10:06 AM, Kathy Rippel <kdr(a)ckls.org> wrote: > I agree, Marie. The list should have terms that librarians will recognize, > not programmers. The underlying structure can still use the programming > terms. > > Kathy > > > At 03:41 PM 9/30/2008, Nicole Engard wrote: > > As far as I know there isn't a list. It's sort of hit or miss. I usually > find out just testing different fields. I'm CCing the Koha List in case > they have any ideas. > > > --- > > Nicole C. Engard > Open Source Evangelist, LibLime > (888) Koha ILS (564-2457) ext. 714 > nce(a)liblime.com > AIM/Y!/Skype: nengard > > http://liblime.com > http://blogs.liblime.com/open-sesame/ > > > On Tue, Sep 30, 2008 at 4:20 PM, Marie Wardall <MWardall(a)dce.k12.wi.us > > wrote: > Hi Nicole- > I'm looking at our test data for our school district and am trying to get a > handle on creating some custom reports because some of the reports in the > Wizard just don't pull enough or the right data. > > When I go into the custom report area I'm getting confused as to what a;; > of the things mean in Step 3 where you select columns for display. Is there > someplace that describes each of these so that I can make a good choice? > > Any help you could give me would be appreciated. > > Thanks, > > > Marie J. Wardall > Library Media Specialist > Mountain Bay Elementary School > 8602 Schofield Ave. > Weston, WI 54476 > mwardall(a)dce.k12.wi.us > Phone: 715-355-0302 ext. 5824 > > Change Today, Change Tomorrow, Keep Changing > > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > > Kathy Rippel > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > As far as I know, this is due to the columns.def file not being up to date with the Koha database. A while back, we discussed using MySQL's COMMENT option to put descriptive information in the table schema. We have a couple of options: * Update columns.def so that it has all of the columns referenced by the guided reports tool. * Using a db update, add comments to all of those columns. These can be gotten by SHOW FULL COLUMNS FROM <table>. This has the advantage of being more "proper", but is yet another displayed string in the database that would have to be translated... somehow. My vote is for columns.def, since it's under the template tree and therefore easily internationalized. Thoughts? -- Jesse Weaver Software Developer, LibLime

2 1