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

[koha] unable to locate Koha configuration file koha-conf.xml
by Massimo Plevani 21 Apr '11

21 Apr '11

Hi All, I am getting the same problem: When I tried to install Koha 3.2.5 on ubuntu 9.04 and I got the following message in first line after executing the perl Makefile.PL command: unable to locate Koha configuration file koha-conf.xml at /build/koha-3.2.5/C4/Context.pm line 307. some help? thanks

1 1

koha: error in MARC Bibliographic Framework Test
by Linda Culberson 21 Apr '11

21 Apr '11

All, I had done 12 customized frameworks in Koha version 3.02.02.003 and at some point I made an error - and I'm embarrassed that I don't know when the error got in since I worked on them pretty much all at once. I have only the one error and it is: Item tag There is more than 1 MARC tag related to items tab (10) : 952,955,956,960,967,980,981,982,983,984,987,990,995,998. I've gone through every framework and don't use any of those fields except the 952. I did this sql statement to verify that was the case: SELECT distinct tagfield FROM `marc_subfield_structure` WHERE `tagfield` IN ('952', '955', '956', '960', '967', '980', '981', '982', '983', '984', '987', '990', '995', '998' ) AND `kohafield` LIKE 'items.%'; and the results was one row: 952. I've checked all the frameworks and even matched them against the demos so kindly posted on koha-community.org. I'm thinking that I may not be understanding what the error means, because I was assuming that it indicated that there might be a duplication in the koha link. Can someone tell me what I should be looking for? Thanks in advance. -- Linda Culberson lculber(a)mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824

3 3

List Cross Posting Trend
by Chris Nighswonger 21 Apr '11

21 Apr '11

Hi everyone, There seems to be a growing trend lately of cross posting to both the Koha user's and developer's list of questions which are usage related. Perhaps this is a good time to remind everyone to please post user questions to the user list and development/code questions to the developer's list in order to preserve each list from the clutter of the other. Only posts truly relevant to both audiences (like this one) should be cross posted. Thanks to all, both users and developers, for helping to make Koha the great ILS that it is! Kind Regards, Chris Koha 3.2.x/3.4.x Release Maintainer

2 1

Koha move to 3.4
by Linda Culberson 19 Apr '11

19 Apr '11

All, How is the recommended way to move to the upcoming 3.4? We were thinking of having two instances. One with our current 3.02.02.003 and one with 3.4. Is that a good way to do it or should we upgrade to 3.2.7 and go from there? Can we move our data or is it better to do a fresh load? How different is the database in 3.4? Your advice to this newbie is greatly appreciated. -- Linda Culberson lculber(a)mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824

3 3

Issues table and foreign keys in general
by Srdjan 19 Apr '11

19 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have noticed some things: 1. issues table has nullable borrowernumber and itemnumber; foreign key constraints are consequently declared as "ON DELETE SET NULL ON UPDATE SET NULL" 2. That is not an isolated issue, there are many cases where foreign key field/constraints are declared like that Can anyone shed more light, that looksvery wrong to me. Thanks, Srdjan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2k/pcACgkQX6p/D9UE7dy2fQCfZP/QeVQSb7VNNMJvA5yYWdBj AvAAn0fRuZ1KinfIiIIWCR+EgXhmYBu8 =2WSQ -----END PGP SIGNATURE-----

4 4

Re: [Koha-devel] Subfields 952 $i, $k
by Paul 18 Apr '11

18 Apr '11

At 04:18 PM 4/18/2011 +0200, Fischer, Katrin wrote: >Hi Paul, >in 3.4 a mapping and a new search index was introduced for 952$i and >items.stocknumber (Bug 5839). Many thanks for the answers. So if we upgrade to 3.4, I'll have to modify kohadb to take out the (varchar 32) constraint? So far, we have endeavoured to remain "faithful" to the Master version, but cataloguing our serials is an uphill challenge. >You can easily add new subfields in your bibliographic frameworks. If you >leave the mapping field empty the data will be stored in the >more_subfields_xml column. As the name indicates it's stored in a XML format. Perhaps easier to add specific items.xyx - I don't think the XML will be problematic, but wonder if these are all concatenated for OPAC display? (e.g. at the moment 520 $a and $b ARE concatenated. I'm looking for a way to undo this.) >There are not many lowercase letters left for 952. According to the MARC21 >Standard it's also possible to use uppercase letters, but I am not >completely sure if Koha works correctly if you do. This would need some >more testing, although we have done so in the past without running into >problems. This sounds like a possible solution - instead of "local" specialized uses (German remapping of 995$j to 952$i in this case) getting into the Master, surely it is more logical to leave more flexibility? I don't think everyone has the time to follow all bugs (I certainly missed this one), maybe the development team could assure us that 952 $[A-Z] are fully working and available for local use, while 952 $[a-z] are for Koha use? Best - Paul >For search you would need to add new indexes to your Zebra configuration. >This is independent from the way you store the data in your database. > >Hope this makes sense and is helpful for you, > >Katrin > > > > -----Original Message----- > > From: koha-devel-bounces(a)lists.koha-community.org [mailto:koha-devel- > > bounces(a)lists.koha-community.org] On Behalf Of Paul > > Sent: Monday, April 18, 2011 4:04 PM > > To: koha; koha-devel(a)lists.koha-community.org > > Subject: [Koha-devel] Subfields 952 $i, $k > > > > [Apologies for cross-posting, users and devel] > > > > Marc 952 $i, $k are not used in "standard" Koha. They can be added to the > > default framework (allowed by Koha), but this appears to require a > > modification to the Mysql structure. Has anyone tried to do this? > > > > Background: for Serials, we want to add at *item* level "Extended > > Keywords" (952$z is limited to 255 characters) and "Abstracts" (at *biblio* > > level, we use 520 $a and $b.) > > > > This will require new "Koha Fields" - e.g, in the same way that 952$z uses > > "items.itemnotes" we will need to introduce "items.itemkeywords" and > > "items.itemabstracts". > > > > I am looking for suggestions as to how to best add these fields so that > > they can be usefully searched by the OPAC - and of course for any pitfalls > > or showstoppers. > > > > Thanks > > > > Paul > > Tired old sys-admin > > > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel(a)lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : http://www.koha-community.org/ > > git : http://git.koha-community.org/ > > bugs : http://bugs.koha-community.org/ > >

2 1

Subfields 952 $i, $k
by Paul 18 Apr '11

18 Apr '11

[Apologies for cross-posting, users and devel] Marc 952 $i, $k are not used in "standard" Koha. They can be added to the default framework (allowed by Koha), but this appears to require a modification to the Mysql structure. Has anyone tried to do this? Background: for Serials, we want to add at *item* level "Extended Keywords" (952$z is limited to 255 characters) and "Abstracts" (at *biblio* level, we use 520 $a and $b.) This will require new "Koha Fields" - e.g, in the same way that 952$z uses "items.itemnotes" we will need to introduce "items.itemkeywords" and "items.itemabstracts". I am looking for suggestions as to how to best add these fields so that they can be usefully searched by the OPAC - and of course for any pitfalls or showstoppers. Thanks Paul Tired old sys-admin

3 2

How to convert a HTML::Template::Pro template to Template::Toolkit
by Chris Cormack 17 Apr '11

17 Apr '11

Hi All There may be a need for people to convert a template to template::toolkit so they can send a patch that will apply cleanly. To do so checkout a branch based on commit d4cd05126da3accef83144d8322fcd455d7eba9b eg git checkout -b convert_templates d4cd05126da3accef83144d8322fcd455d7eba9b Now you have a branch with both sets of templates, you can then cherry-pick your template change over. And run ./installer/html-template-to-template-toolkit.pl --koharoot /path/to/the/root This will convert all the templates, if you want to just convert 1 use -f eg ./installer/html-template-to-template-toolkit.pl --koharoot /path/to/the/root -f koha-tmpl/opac-tmpl/prog/en/modules/ilsdi.tmpl So for me ./installer/html-template-to-template-toolkit.pl -c --koharoot /home/chrisc/git/koha/ -f koha-tmpl/opac-tmpl/prog/en/modules/ilsdi.tmpl Then that file will be in the koha-tt dir and you will now have a converted file. Hope this helps Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand

4 4

Important notice regarding patches intended for backporting into 3.2.x
by Chris Nighswonger 16 Apr '11

16 Apr '11

At present the 3.2.x branch is current with master at all applicable commits. Due to many possible pitfalls with the switch to T::T, it is imperative that those submitting patches indicate exactly which patches should be backported to 3.2.x. It is possible that a change to an underlying perl script to correct a bug with a T::T template may apply cleanly to the 3.2.x branch and break H::T::P functionality. So, moving forward, I will backport only those patches with notes indicating that the commits should be backported to 3.2.x. Please take note of this and be sure to make the indication in your commit message. Kind Regards, Chris Koha 3.2.x/3.4.x Release Maintainer

1 0

DB number incrementing revisited
by Chris Nighswonger 16 Apr '11

16 Apr '11

Not to beat a dead horse here, but... What works very well for me as Release Maintainer regarding DB version numbers is when the patch to updatedatabase.pl simply uses the format: 3.03.XXX (which some folks are doing) and no modification is made to kohaversion.pl In 99% of cases, this applies cleanly and allows me to follow up with a single patch to adjust the version number in both places. So I'd love to see everyone adapt this style. Kind Regards, Chris

1 0