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

Re: [Koha-devel] Koha 3
by Paul POULAIN 09 Apr '08

09 Apr '08

C W Nel a écrit : > Thanks Paul > > But I do not see the mysql.sock anywhere on the server? the file is created when mySQL starts. It is not present if mySQL has not started correctly. try to start it manually (/etc/init.d/mysqld start), check what is said, and check the logs if needed PS : pls answer on the list, not privatly. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

Koha 3
by C W Nel 09 Apr '08

09 Apr '08

Hi AllI am trying to upgrade from 2.2.9 to 3 on Debian etch, but get stuck with a mysql problem."Can't connect to local MySQL server through socket '/tmp/mysql.sock'"It seems as if the apt-get installation does not install the correct mysql instance.Can anyone please advise on a solution?

2 1

let's say...import to a framework, and item types
by Ignacio Javier 09 Apr '08

09 Apr '08

Hi all, I'm me alone again, with a one or two question: Wich is the preferred way to import items from import_records to biblio table, via table import_records->marc (record BLOB) and doing a match in Item type (942 c) or expressing it in a per batch basis, adding a combo box in stage-marc-import, or both, or anyone? And BTW, how can I export a MARC to be a item, to import items instead of MARC records? Thanks, Ignacio Javier Gómez Rodríguez Analista - Programador Tfno: 902905590 - Fax: 981571425 ignacio.gomez(a)coremain.com www.coremain.com _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

1 0

Koha 2.2.9 sticky due date
by C W Nel 08 Apr '08

08 Apr '08

Hi All Can someone please help with above. I need to use the sticky due date also for renewal of allready issued items. The renewbooks function in circ2.pm allows for a "duedate" parameter. I need to know how to force the renew functionality to use the sticky due date. It sounds straight forward, but I am battling to get it to work. Help will be much appreciated. Thanks!

2 1

Redundant max results system prefs?
by Owen Leonard 08 Apr '08

08 Apr '08

I see three different system prefs related to the number of search results displayed on a page: maxItemsInSearchResults: Specify the maximum number of items to display for each result on a page of results numSearchResults: Specify the maximum number of results to display on a page of results OPACnumSearchResults Specify the maximum number of results to display on a page of results Are the latter two more current than the first? I find references to all three in the code. Can we get rid of maxItemsInSearchResults? -- Owen

2 3

RFC: granular permissions
by Galen Charlton 08 Apr '08

08 Apr '08

Hi, For a customer project I've been working on an approach to make Koha's staff user permissions more granular. The initial scope of the development is restricting access to individual items on the tools page, but the mechanism can readily be expanded to cover all of Koha's modules. My idea is to reinterpret the existing user flags to describe access to entire functional modules, then create a second level of permissions under each flag/module. For example, associated with the tools flag are 15 sub-permissions, one for each tool. If the staff user has permission for any of the tools, the user can get to the tools page, but only the ones that the user has specific access to are displayed. The user flags editing page now uses a tree instead of a table, with a jQuery tree control to allow expanding and collapsing the tree of available permissions. There are two major changes to the API: * get_template_and_user and its kin now consider the value of each key in the flagsrequired hash, e.g.,: flagsrequired => {tools => 'export_catalog'} # must have export_catalog or all tools flagsrequired => {tools => '*'} # must have permission for at least one tool flagsrequired => {tools => 1} # must have permission for all tools * the set of CAN_user_XXX template variables is expanded to included the specific permissions, e.g., CAN_user_tools_export_catalog. If a user has access to all tools, all 15 of the CAN_user_tools_YYY template variables are set. The granular permissions mechanism can be turned off or on with the CheckSpecificUserPermissions system preference; when that preference is off, only the top-level user flags are displayed in the permissions editor and are considered during authorization checks. By default, this syspref is off. However, I think the syspref should be temporary, and should go away after 3.2 at the latest. The specifications I followed are available on the wiki at http://wiki.koha.org/doku.php?id=granularpermissions. The patches implementing this feature are available for review at http://manage-gmc.dev.kohalibrary.com/patches/granular/. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

2 2

(sans objet)
by marc.chantreux＠koha-fr.org 08 Apr '08

08 Apr '08

1 0

Re: [Koha-devel] [Koha] Problem with Amazon content
by Joshua Ferraro 08 Apr '08

08 Apr '08

Hi BENSON, On Sat, Apr 5, 2008 at 5:25 AM, benson Mugambi <mnjoben(a)yahoo.co.uk> wrote: > I have installed koha 2.2.9 on ubuntu 6.06 and everything was working > properly intil the OPAC began crashing when loading search results. Am not > able to access the error log file to get the exact causes for the problem, > but after i disabled the Amazon content, the OPAC worked well albeit without > the Amazon book images. So what could be wrong here, what should i do to > correct it? Is there another way of getting the book images, apart from > Amazon? You're running Koha version 2.x, and the Amazon.com API hasn't been upgraded in that version to use the new ESC API. Amazon has ceased support of the version of the Amazon API used in Koha version 2.x. This has been corrected in Koha 3.0, please see the following message: http://www.mail-archive.com/koha-devel@nongnu.org/msg00583.html It would be trivial to back-port this change into the 2.2.x series, would anyone be willing to do this? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

Available languages in Koha 3 Beta... and "famfamfam"
by Ricardo Dias Marques 08 Apr '08

08 Apr '08

Hi list! I've installed Koha 3 Beta last week, on a (virtual) machine running Linux (openSUSE 10.3), the "default" Apache (2.2.4) and the "default" MySQL (5.0.45). First of all, congratulations to the Koha developers team for a very nice UI (User Interface) redesign. The new Koha (literally) looks great! :) Having said that, I did run into some problems during the installation (but I'll leave that to other post). The topic of this message is languages, both in the OPAC and in the Intranet areas. After I managed to: 1- run perl makefile.PL 2 - install all the required package dependencies (Perl packages - mostly from CPAN - and RPM packages) 3 - create the koha (MySQL) database and the kohaadmin user and the koha system user 4 - run make test and make install 5 - ... I finally reached the first step of the Web Installer, available at: http://hostname:8080/cgi-bin/koha/installer/install.pl That took me to a login screen. I logged in with my kohaadmin username and password. That worked and took me to the "Web Installer > Step 1" page (the URL remained the same), to choose a language. The default language that appears has a funny looking name: "famfamfam"! I have searched the web and found out that famfamfam is some kind of an icons web site - http://www.famfamfam.com/ => Does anyone have any idea why does famfamfam appear as an available language? I have executed the locate command - locate famfamfam - and found out there is a famfamfam directory in: /usr/share/koha/opac/htdocs/opac-tmpl/prog/famfamfam I changed that default language option (famfamfam) to en (English), but did not find any other languages to select (like "pt" - Portuguese - that was the one I was looking for). I followed every step of the Web Installer (with no apparent problems). After I finished the Web Installer, I logged in to the Intranet Koha site with the kohaadmin username. I clicked on the "System Preferences" link, that took me to: http://hostname:8080/cgi-bin/koha/admin/systempreferences.pl Then, I clicked on the "I18N/L10N" link on the left hand side, which took me to: http://hostname:8080/cgi-bin/koha/admin/systempreferences.pl?tab=I18N/L10N I then tried to change the parameters for: - "language" -http://hostname:8080/cgi-bin/koha/admin/systempreferences.pl?op=add_form&searchfield=language - and "opaclanguages" - http://191.112.10.6:8080/cgi-bin/koha/admin/systempreferences.pl?op=add_for… But I only get "en" as a (checkbox) option for "language" and "famfamfam" and "en" as (checkbox) options for "opaclanguages". So, my questions are: 1 - Why is "famfamfam" appearing as language? 2 - What do I have to do so that other languages (namely Portuguese - pt) appear as a checkbox option for the "language" and/or "opaclanguages" parameters? I'm using UNIMARC and *not* MARC21 (if that's relevant). If I missed to mention any relevant info, feel free to point it out. Thanks in advance! Best wishes, Ricardo Dias Marques lists AT ricmarques DOT net

4 4

Size of Patron Pictures.
by Michael Hafen 07 Apr '08

07 Apr '08

There are two concerns I have with patron picture. First is whether they are scaled by the server when uploaded or displayed. Second is if they should have a specified size. On the (english) help for the member details page it says, "You should be aware that the Details page will display the image at 25% of the original pixel dimensions." It would seem that the details page scales the pictures when they are displayed. I see nothing the the html or css that does this. Are the pictures scaled by the server? One of my users, while testing Koha 3, uploaded a very large image for a patron. He can no longer access the form for changing the patron image as the picture has covered the form. This is inconvenient. I would like to see a restriction placed on the size of patron pictures to prevent this. What I would like is an addition to staff-global.css like this: img#patronimage { max-height : 180px; max-width : 145px; } That should do the trick. Thanks. _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

2 3