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

Hackfest - 5579 remove items from marcxml
by Claire Hernandez 07 Apr '11

07 Apr '11

Hi, As I said, I setup an unimarc install here: http://koha.qa.testing.biblibre.com <http://koha.qa.testing.biblibre.com/> http://qa.testing.biblibre.com <http://koha.qa.testing.biblibre.com/> with patches related to 5579 ticket. - The database is the same as http://koha.master.testing.biblibre.com <http://koha.qa.testing.biblibre.com/> - I played the migration script on qa setup (misc/maintenance/remove_items_from_biblioitems.pl) - Rebuild zebra and launch zebra Please, have a look. We found only one bug in "marcxml export" where we would like to see items in export. Matts tries to paitch it this morning. We had a look on - items crud operations - indexing, searching - circulation basis - batch modification - migration scripts without founding mistakes but it can be not exhaustive. These modifications needs to be tested with Marc21 too. Thanks, Claire.

3 4

Sharing bugzilla queries
by Paul Poulain 07 Apr '11

07 Apr '11

Hello world, if you login on bugzilla, then Click on Preferences, then Saved searches, you'll find the queries you've saved, but also some usefull shared queries : Needs signoff, Patch pushed, signed off, Does not apply, Failed QA Just check the checkbox and you'll get a link to this query on the footer of your bugzilla entry. Another hint: if you don't like bugzilla going to your next bug everytime you validate a form, choose what you want on Bugzilla > Preferences > After changing a bug -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Warnings about Koha to MARC links
by Owen Leonard 07 Apr '11

07 Apr '11

I have a question about Koha/MARC links On marctagstructure.pl it says "If you change the link between a MARC subfield and a non-MARC field, ask your administrator to run misc/batchRebuildBiblioTables.pl script." On marc_subfields_structure.pl, next to the "link" field, it says "Warning: This value should not change after data has been added to your catalog." Are these not talking about the same thing? Which is correct? I would like to remove the warning from marctagstructure.pl since it pertains directly to subfield editing, but I want to make sure the note on marc_subfields_structure.pl is accurate. Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 1

Next irc meeting of Kohacon11 volunteers is on 8th April 2011 at 6.00UTC
by Koustubha Kale 07 Apr '11

07 Apr '11

Hi All, Gentle reminder : Next irc meeting of Kohacon11 volunteers is on 8th April 2011 at 6.00UTC Conversions to your local time: http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=4&day=… Agenda at : http://wiki.koha-community.org/wiki/KohaCon11_Volunteers#Agenda_2 Feel free to add to it and see you there.. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

1 0

Koha It DOES work. Koha: staff client searching by card number
by Linda Culberson 07 Apr '11

07 Apr '11

All, It does work in check out!! It is just in searching the patron's that it doesn't. Surely, the staff will accept that. Surely. I hope. I apologize for my panic. We'll just use the name when searching for patrons and continue with our current procedure when checking out items. Linda On 4/6/2011 1:46 PM, Linda Culberson wrote: > All, > I tested the various suggestions. On our version, 3.02.02.003, putting > an asterisk in front of the number made no difference in the result. A > search of my number pulled up 1540 results. Adding the first letter of > my last name cut it down to 552. Using the first two letters did cut it > down to 26. Using my number and my full first name was 28 (mainly > because it got those "Belinda" and "Malinda" and "Melinda" etc.) > > A coworker's results were worse. Her card number pulled up 6358 results, > adding the first letter of her last name cut it to 2837, and the first > two letters to 249. Using her number and her full last name (which is > admittedly a common name - almost as bad as "Linda") got it down to 17. > > So basically, for us, searching by cardnumber doesn't really seem to > work, and so our checkout procedure will have to be reworked. We had > been swiping the patron's card and then the item's barcode. This won't > work in Koha, apparently. > > Thanks to all who answered. > > Linda > > On 1:59 PM, Tim McMahon wrote: >> In the staff interface, you can add an asterisk * before the barcode to >> get the exact item. Something like *36431 instead of just 36431. >> >> On 04/06/2011 11:10 AM, Hal Bright wrote: >>> In addition, is there a way to force an exact search in the materials >>> catalog? >>> >>> -----Original Message----- >>> From: koha-bounces(a)lists.katipo.co.nz >>> [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Linda Culberson >>> Sent: Tuesday, April 05, 2011 5:18 PM >>> To: koha >>> Subject: [Koha] Koha: staff client searching by card number >>> >>> Everyone, >>> Another newbie question: Is there a way in the staff client to search by >>> the exact card number? It seems to be using wild cards before and >>> after. For example, a search for "643" pulls up 1643", "36431" and >>> everything else that contains "643" with 643 in the list. We want it >>> to pull up only the one 643. I'm assuming it isn't acceptable to >>> change member.pl? >>> >>> 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

2 1

The Many Faces of CheckReserves
by Ian Walls 06 Apr '11

06 Apr '11

Fellow Kohackers, I'll state this boldly and up front: C4::Reserves::CheckReserves must die. Read the POD. It's purpose is unclear, and without a clear purpose, how can we expect to make coherent use of it? You feed it an itemnumber (or a barcode), and it gives you a status and a reserve hash. It's utilized in 11 places in Koha, each to a different end: C4::Search::searchResults - to get determine whether each item is "waiting" for someone or not C4::XSLT::buildKohaItemsNamespace - again, to indicate if the item is "waiting" or not C4::Items::GetItemsInfo - to populate the count_reserves key in the returned value C4::Reserves::GetOtherReserves - returns whether to transfer the item (and transfers it) if a hold for the passed item exists, and the borrower who it's meant for C4::Circulation::transferbook - tell the routine to 'dotransfer' if there there is a hold and holds aren't being ignored C4::Circulation::CanBookBeIssued - indicate that the title is on hold for someone else, waiting or not C4::Circulation::AddIssue - marks the reserve as filled and advances the next, or cancels the hold if told C4::Circulation::AddReturn - returns the next hold C4::Circulation::CanBookBeRenewed - block renewals if there is a hold circ/circulation.pl - add the "renew_error" to the issues table opac/opac-user.pl - add 'reserved' note to the issued items table What functions are needed here? We need a way to indicate that a particular item should be used to fill a pending hold. (this will be subject to many rules, and in some cases can block issuing, transfer or renewal) We need a mechanism to fill a hold using a particular item, marking it as 'committed', and handling the rest of the holds queue as appropriate We need some way to indicate that a particular item has been committed to fill a hold. That looks like three subroutines to me: $reservenumber = ReserveItemCanFill($itemnumber) $messages = FillReserve($reserve, $itemnumber) $reservenumber = IsItemWaitingForReserve($itemnumber) The last could even be done as another field in the items table, onhold, like the onloan field, and populated with the expiration date of the hold. Yes, this depends on there being a primary key to the reserves table, but that's in the works, and will open many doors for us once it's in place. Thoughts? Comments? Counterarguments? -Ian -- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

1 0

Re: [Koha-devel] Koha - biblioitems
by Chris Cormack 06 Apr '11

06 Apr '11

On 7 Apr 2011 07:11, "Linda Culberson" <lculber(a)mdah.state.ms.us> wrote: > > All, > I couldn't remember where I'd seen the reference to biblioitems being merged with biblio, so went back to my notes. It was in an RFP on the wiki. Now, I see that the RFC has been listed as abandoned. Thanks to all for your reassurance. > The merge will take place eventually, but will never ever kill repeatable fields... even more reassurance. :) > By way of explanation we have done numerous test migrations, checking and rechecking that things convert properly, and then fixing in our current catalog what doesn't work in Koha. We are getting very close, and I've be going over my notes to make sure I didn't miss anything. Out of over 100,000 biblios, I'm now down to two (that I know of) that have serious problems. One of those has multiple 300 tags, although that isn't creating its problem. > Thats a darn good ratio, pat yourself on the back. > It helps to know everyone is out there and so willing to help, and I appreciate your patience. > Without users what the rest of us do is worthless, so we definitely appreciate you too. Especially users who get involved and ask questions and point out our mistakes, they are invaluable. Keep up the good work. Chris > Thanks, > Linda > > > On 4/6/2011 12:17 PM, Chris Cormack wrote: >> >> * Linda Culberson (lculber(a)mdah.state.ms.us) wrote: >>> >>> All, >>> In 3.4 and on, I somehow got the impression (dream/nightmare?) that >>> biblioitems was to no longer exist, and that certain MARC fields >>> that are repeatable - particularly the 300, will no longer be. Did >>> I dream that or is that the case? If it is true, will Koha have a >>> way to handle those repeatable fields? >>> >>> I would appreciate hearing from someone about this right away, as it >>> may scuttle our whole migration plan. >> >> >> I can confirm as 3.4 Release Manager that removing repeatable fields was >> not ever planned for the 3.4.x series (or any other release series for >> that matter). >> >> Merging biblio and biblioitems may happen in the future, (not for 3.4.x) >> but it will not ever result in a regression of features like this. >> >> I'm not sure where you got them impression, if you can recall, and >> correct anyone else who has this fear also that would be awesome. >> >> The nice thing about Koha is all development and discussion is done in >> the open, so at any point anyone can see exactly what is going to be in >> 3.4.x. No hidden suprises, no unreleased code, it's all there for >> everyone to see. Which is why I recommend (well I would wouldn't I, >> being Release manager and all) that people run from official Koha >> releases. No hidden nasties. >> >> Chris > > > -- > 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 > > _______________________________________________ > 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/

1 0

Koha - biblioitems
by Linda Culberson 06 Apr '11

06 Apr '11

All, In 3.4 and on, I somehow got the impression (dream/nightmare?) that biblioitems was to no longer exist, and that certain MARC fields that are repeatable - particularly the 300, will no longer be. Did I dream that or is that the case? If it is true, will Koha have a way to handle those repeatable fields? I would appreciate hearing from someone about this right away, as it may scuttle our whole migration plan. Thanks! -- 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

5 5

Bug 6085 - For the hackfesters
by Chris Cormack 06 Apr '11

06 Apr '11

Hi All First off thanks to everyone who is signing off/testing patches and bugs, whether you are at the sprint week or not you are all doing a fantastic job. Bug 6085, can't change language in OPAC and Staff was just reported, this is currently our only blocker for 3.4.x. Could people take a look at this bug, check it exists, and fix it please. This will save me having to hunt down the commit(s) that broke it and remove them from master before release. Chris

1 0

Selenium IDE - firefox extension
by Francois Charbonnier 06 Apr '11

06 Apr '11

Hello all, I am currently working on testing bugs during the hackfest hosted by biblibre, in marseille, and I started working with the firefox extension "selenium IDE" to replay the tests i'm doing. I think it would be a good thing to attach these selenium tests to each bug we are working on. This way, it will be easier to avoid side effects when we are working on groups of developpement that affect the same features. It implies that we should always work on the same dataset (we are already working on a dataset we could use : http://git.biblibre.com/?p=data;a=summary) and that each template change will lead us to make the selenium test again. But still, i think it's a good idea for all the "testers"! What about you? What do you think? Should we all try to work with selenium tests each time we can? Thank you for your answers! -- François Charbonnier http://www.biblibre.com/ Expert en Logiciels Libres pour l'info-doc Tél: 06 17 45 57 76

2 1